Hoy les traigo una pequeña pero interesante prueba de concepto para los amantes del networking y las redes TCP/IP. Cómo montar un tunel IPv6 6in4 para poder enviar tráfico IPv6 sobre una red IPv4.
Como todos sabemos, IPv6 es el futuro de las comunicaciones en Internet, IPv4, el estandar IP que utilizamos todo el tiempo en la actualidad tiene sus días contados, y en breve los ISP’s comenzarán a implementar mecanismos de migración a ipv6.
Los sistemas operativos de la actualidad soportan, en general, dual-stack, lo que significa que poseen tanto soporte para IPv4 como IPv6. Nuestro querido Linux, por supuesto, soporta dual stack por defecto.
Suponiendo que tenemos equipos en nuestra red, o en Internet, que están conectados vía IPv4, como seguramente ocurrirá, es una limitación si queremos conectarnos y probar herramientas diseñadas para IPv6, o que tengan soporte.
Para ello, en esta pequeña prueba de concepto vamos a montar un túnel 6in4 entre dos equipos Linux que, en mi caso particular, son máquinas virtuales, pero que tranquilamente puede funcionar entre dos direcciones IPv4 públicas en la red.
Prueba de concepto: tunel ipv6 6in4
El siguiente esquema ilustra el caso:
Disponemos de un host con dirección 10.0.0.30/24 en un extremo, y otro con dirección 10.0.0.60/24 en el otro, comunicados por ipv4 naturalmente.
Como se apreciará, también cada host dispone de su dirección de link global ipv6 que, al no tener una red ipv6 configurada con routers intermedios que encaminen el tráfico, no podrán conectarse entre si.
Lo que haremos es montar un túnel SIT entre los dos hosts, y enrutaremos el tráfico ipv6 que viaje entre ellos por medio de la interfaz del túnel.
Manos a la obra
Analicemos los siguientes comandos ejecutados en el host 10.0.0.30:
ip tunnel add net6tun mode sit remote 10.0.0.60 local 10.0.0.30
ip link set net6tun up
ip addr add 2a01:d0:ffff:451e::30/64 dev net6tun
ip route add ::/0 dev net6tun
En la línea 1 creamos el túnel, llamado net6tun a elección, de tipo sit, con direccionamiento público ipv4, es decir, indicamos cuál es la dirección del host local y la del host remoto.
En la línea 2 levantamos la interfaz net6tun recién salida del horno.
En la línea 3 asociamos la dirección IPv6 de nuestro host a la interfaz del túnel.
Y finalmente en la línea 4 enrutamos todo el tráfico ipv6 con salida a la red por medio de la interfaz del túnel.
Por supuesto, es una prueba de concepto, algunos parámetros pueden cambiar en la realidad según las necesidades que tengamos.
Si nos fijamos ahora en la salida del comando «ip a» veremos algo similar a esto:
root@debian3:~# ip a
[...]
7: net6tun: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1480 qdisc noqueue state UNKNOWN
link/sit 10.0.0.30 peer 10.0.0.60
inet6 2a01:d0:ffff:451e::30/64 scope global
valid_lft forever preferred_lft forever
inet6 fe80::a00:1e/128 scope link
valid_lft forever preferred_lft forever
root@debian3:~# ip -6 r
2a01:d0:ffff:451e::/64 via :: dev net6tun proto kernel metric 256 mtu 1480 advmss 1420 hoplimit 0
fe80::/64 dev eth2 proto kernel metric 256 mtu 1500 advmss 1440 hoplimit 0
fe80::/64 via :: dev net6tun proto kernel metric 256 mtu 1480 advmss 1420 hoplimit 0
default dev net6tun metric 1024 mtu 1480 advmss 1420 hoplimit
Vemos que tenemos configuración de red con la interfaz net6tun con los direccionamientos de túnel, y el direccionamiento ipv6 seteado, mientras que en la tabla de enrutamiento vemos que tódo el tráfico ipv6 por defecto (default) se enruta en la interfaz net6tun.
Hecho esto, repitamos los pasos en el host 10.0.0.60 cambiando, por supuesto, las direcciones ip de lugar. Aquí los comandos:
ip tunnel add net6tun mode sit remote 10.0.0.30 local 10.0.0.60
ip link set net6tun up
ip addr add 2a01:d0:ffff:451e::60/64 dev net6tun
ip route add ::/0 dev net6tun
Y veamos la configuración final, tanto de direccionamiento como de enrutamiento:
root@curso:~# ip a
[...]
5: net6tun: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1480 qdisc noqueue state UNKNOWN
link/sit 10.0.0.60 peer 10.0.0.30
inet6 2a01:d0:ffff:451e::60/64 scope global
valid_lft forever preferred_lft forever
inet6 fe80::a00:3c/128 scope link
valid_lft forever preferred_lft forever
root@curso:~# ip -6 r
2008:db9:fe:19::/68 dev eth1 proto kernel metric 256
2a01:d0:ffff:451e::/64 via :: dev net6tun proto kernel metric 256
fe80::/64 dev eth0 proto kernel metric 256
fe80::/64 dev eth1 proto kernel metric 256
fe80::/64 via :: dev net6tun proto kernel metric 256
default via 2008:db9:fe:19:: dev eth1 metric 1024
default dev net6tun metric 1024
Probando el túnel
Ahora la prueba de fuego, el ping6.
ping es la herramienta de testeo universal (siempre que el tráfico ICMP no esté filtrado xD).
Ping6 es el comando que nos va a permitir enviar tráfico por dentro del tunel.
Lo que haremos, en el host 10.0.0.30, ejecutaremos un comando ping que envíe mensajes echo-request en ICMPv6, es decir, icmp encapsulado en IPv6, que a su vez, irá encapsulado en IPv4, no es emocionante? :’)
root@debian3:~# ping6 -I 2a01:d0:ffff:451e::30 2a01:d0:ffff:451e::60
PING 2a01:d0:ffff:451e::60(2a01:d0:ffff:451e::60) from 2a01:d0:ffff:451e::30 : 56 data bytes
64 bytes from 2a01:d0:ffff:451e::60: icmp_seq=1 ttl=64 time=0.251 ms
64 bytes from 2a01:d0:ffff:451e::60: icmp_seq=2 ttl=64 time=0.265 ms
[...]
Al parecer el ping funciona!
Vayamos ahora al host 10.0.0.60 y veamos qué pasa por el cable. Veamos qué trafico podemos capturar en la interfaz del tunel:
Efectivamente, viaja tráfico direccionado en IPv6, que dentro lleva mensajes ICMPv6 de echo-request y sus respuestas, echo-reply. Nótese las direcciones ipv6 de origen y destino y compárelas con las de las configuraciones.
Y finalmente, lo más interesante, capturemos tráfico en la interfaz eth0, la interfaz física que conecta nuestro equipo 10.0.0.60 a la red, o a Internet:
root@curso:~# tcpdump -nni eth0 not port 22 and host 10.0.0.30 -vv
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
20:10:45.948421 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto IPv6 (41), length 124)
10.0.0.30 > 10.0.0.60: IP6 (hlim 64, next-header ICMPv6 (58) payload length: 64) 2a01:d0:ffff:451e::30 > 2a01:d0:ffff:451e::60: [icmp6 sum ok] ICMP6, echo request, seq 1
20:10:45.948463 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto IPv6 (41), length 124)
10.0.0.60 > 10.0.0.30: IP6 (hlim 64, next-header ICMPv6 (58) payload length: 64) 2a01:d0:ffff:451e::60 > 2a01:d0:ffff:451e::30: [icmp6 sum ok] ICMP6, echo reply, seq 1
20:10:46.947208 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto IPv6 (41), length 124)
10.0.0.30 > 10.0.0.60: IP6 (hlim 64, next-header ICMPv6 (58) payload length: 64) 2a01:d0:ffff:451e::30 > 2a01:d0:ffff:451e::60: [icmp6 sum ok] ICMP6, echo request, seq 2
20:10:46.947256 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto IPv6 (41), length 124)
10.0.0.60 > 10.0.0.30: IP6 (hlim 64, next-header ICMPv6 (58) payload length: 64) 2a01:d0:ffff:451e::60 > 2a01:d0:ffff:451e::30: [icmp6 sum ok] ICMP6, echo reply, seq 2
[...]
He filtrado algunas salidas de puerto 22 y otras yerbas para que no me ensucie de basura lo que realmente me interesa, lo que se ve en pantalla. Como se aprecia, tenemos tráfico IPv4 direccionado entre los hosts 10.0.0.30 y 10.0.0.60, que adentro lleva paquetes de protocolo número 41, es decir, IPv6. De esta forma se aprecia que tenemos en el stack tcp/ip paquetes de IPv4 que encapsulan paquetes de IPv6.
Los paquetes IPv6 son los mismos que vimos antes, pero ahora «metidos» dentro de paquetes IPv4. El paquete IPv6 a su vez encapsula los mensajes ICMPv6.
Gráficamente, podríamos dibujarlo así:
Espero que les sirva! Compartan si les pareció interesante!!
Me duele la cabeza de solo leerlo!!! pero lo «peor» es que me encanta, aunque por ahora entienda la mitad 🙂
Bueno ya veremos mas de todo esto en alguna clase seguro!!
Diego Córdoba
· 30 marzo, 2016 a las 21:55
jajaja tranquilo que con el tiempo se aprende todo, esto es simple, cuando veamos tunneling en el curso de vpn haceme acordar que le petemos una mirada 🙂
Hoy veremos de qué puede servirnos un sniffer de tráfico de red como wireshark/tshark o tcpdump para analizar algunos segmentos TCP particulares: los inicios de conexión TCP SYN. Analizar los mensajes SYN y SYN-ACK en Leer más…
HTTP es uno de los protocolos TCP/IP de capa de aplicación más utilizado en Internet: Sitios web y API’s REST hacen uso de este protocolo, por lo que es importante entender cómo funciona. Cuando visitamos Leer más…
Respondiendo una consulta que me hizo un alumno del curso de iptables, hoy aprenderemos el concepto de NAT (Network Address Translation), y las diferencias entre SNAT y DNAT Este contenido complementa nuestro curso de IPTables. Leer más…
2 comentarios
Javier · 30 marzo, 2016 a las 19:36
Me duele la cabeza de solo leerlo!!! pero lo «peor» es que me encanta, aunque por ahora entienda la mitad 🙂
Bueno ya veremos mas de todo esto en alguna clase seguro!!
Diego Córdoba · 30 marzo, 2016 a las 21:55
jajaja tranquilo que con el tiempo se aprende todo, esto es simple, cuando veamos tunneling en el curso de vpn haceme acordar que le petemos una mirada 🙂
Otro concepto que vamos a ver es este, pa que te vayas ambientando 😛
https://juncotic.com/por-que-tunelizar-tcp-sobre-tcp-no-es-bueno/
Los comentarios están cerrados.