Hace un par de meses que no escribo nada por aquí, así que con la excusa del IPv6-day me he animado a escribir un post que hace tiempo tenía pensado escribir.
Vamos a ver cómo conectar no solo un ordenador, sino toda la casa al mundo IPv6. Para ello vamos a suponer que no tenemos IPv6 de manera nativa, pero que disponemos de un servidor en algún datacenter (también sin IPv6 de manera nativa) y un router con GNU/Linux. También vamos a suponer que algo sabemos de OpenVPN y Quagga.
Para llevar a cabo esta frikada he contado con la inestimable ayuda de Mikel «Mike» Jiménez, un yonki de las redes que vive por y para el TCP/IP y el único al que dejaría una shell de root en mi router sin preocuparme. 🙂
Dado que no disponemos de conectividad real IPv6 necesitaremos los servicios de un broker que nos provea de un túnel. Para este montaje utilizaremos el servicio proporcionado por Hurricane. Para poder crear el túnel necesitamos que nuestro extremo disponga de una IP fija, pero como vamos a configurarlo en el host que tenemos en un datacenter esto no debería suponer un problema.
Al finalizar la solicitud través de la web obtendremos un rango /64 para nosotros. Suficiente, ¿no? Pues no. Hemos dicho que queremos tener IPv6 en toda la casa, e IPv6 nos ofrece un mecanismo para asignar una dirección IP a cada dispositivo sin la necesidad de utilizar DHCP: Router Advertisement. Básicamente nuestro router tendrá una IP en este rango y se anunciará mediante paquetes RA y los dispositivos generarán una IP única en ese rango utilizando su MAC. Esto significa que necesitamos un rango más grande si queremos crear varias subredes /64 para poder interconectar a varios colegas con IPv6 mediante un único túnel. Hurricane nos da la posibilidad de obtener un rango /48, así que no hay problema 🙂
A continuación podéis ver una captura de pantalla de los datos de la red IPv6 /64 que Hurricane nos ha dado y la /48 que nos enruta a través de ella:
Ya que hemos dicho que teníamos un servidor en un datacenter, lo utilizaremos para crear múltiples subredes IPv6 que saldrán al mundo real por un único túnel a través de Hurricane. Veamos una imagen con la estructura que queremos montar:
Como se aprecia en la imagen, todos los nodos (los routers de nuestras casas) están conectados mediante una VPN sobre IPv4 al servidor. Utilizaremos una subred que actuará como red de tránsito entre nuestro server y cada una de las subredes de los clientes que conectemos. Los clientes se conectarán mediante una VPN sobre IPv4. En éste túnel, implementaremos tanto IPv4 como IPv6, teniendo así soporte dual stack en la VPN. Para publicar la red que nos ha sido asignada como cliente, usaremos OSPFv3. ¡Vamos al lio!
Primero configuramos el tunel con Hurricane tal y como se nos indica en la web:
ip tunnel add he-ipv6 mode sit remote 216.66.84.42 local 91.121.117.27 ttl 255 ip link set he-ipv6 up ip addr add 2001:470:1f12:286::2/64 dev he-ipv6 ip route add ::/0 dev he-ipv6 ip -f inet6 addr
Es una buena idea poner esto en un script y ejecutarlo en el post-up de la interfaz a través de la cual tiraremos el túnel, para no tener que lanzarlo manualmente al reiniciar.
Una vez tenemos el túnel levantado ya deberíamos poder hacer ping6 a ipv6.google.com y molar. Ahora elegiremos una subred (de la /48 que nos enrutan) que usaremos como red de tránsito. En nuestro caso, nos enrutan la siguiente subred:
2001:470:c846::/48
Y elegiremos la siguiente subred de transito:
2001:470:c846:1::/64
En el extremo de la VPN del servidor, nos pondremos la primera IP de la subred de transito, y cada cliente podrá elegir cualquier IP en su extremo. Con 2^64 posibilidades creo que no habrá muchas colisiones 😉
2001:470:c846:1::1/64
Veamos la configuración de Quagga para el servidor:
interface tap0 ipv6 address 2001:470:c846:1::1/64 ipv6 nd suppress-ra ipv6 ospf6 cost 1 ipv6 ospf6 dead-interval 40 ipv6 ospf6 hello-interval 10 ipv6 ospf6 instance-id 0 ipv6 ospf6 priority 255 ipv6 ospf6 retransmit-interval 5 ipv6 ospf6 transmit-delay 1 link-detect ! router ospf6 router-id 2.2.2.2 redistribute kernel redistribute static interface tap0 area 0.0.0.0
Lo importante de todas opciones arriba listadas son:
- IPv6 address: indica la IP del interfaz tap0
- Router-id, nos podemos inventar
- Area, necesiaremos que sea el mismo en el servidor y los clientes
- Redistribute kernel: hará que se publique la IP del servidor por OSPF para que los clientes la usen como ruta por defecto para el tráfico IPv6
Ahora veamos la configuración en un cliente:
interface eth1 ipv6 address 2001:470:c846:2::1/64 ipv6 nd prefix 2001:470:c846:2::/64 ipv6 nd ra-interval 30 ipv6 nd ra-lifetime 600 link-detect no ipv6 nd suppress-ra ! interface tap0 ipv6 address 2001:470:c846:1::666/64 ipv6 nd suppress-ra ipv6 ospf6 cost 1 ipv6 ospf6 dead-interval 40 ipv6 ospf6 hello-interval 10 ipv6 ospf6 instance-id 0 ipv6 ospf6 priority 1 ipv6 ospf6 retransmit-interval 5 ipv6 ospf6 transmit-delay 1 link-detect ! router ospf6 router-id 1.1.1.1 redistribute connected interface tap0 area 0.0.0.0
Aquí tenemos varias cosas. Por un lado, tenemos que elegir una subred (al azar, la posibilidad de colisión es casi nula) que será la que usemos en ese cliente (nuestara casa):
- IPv6 address (eth1): indica la IP que tendrá este router en la subred que hemos seleccionado para este cliente
- IPv6 nd prefix (eth1): indica el prefijo por el cual se hará el neighbour discovery
- «no ipv6 nd suppress-ra»: indica que se utilizará Router Advertisement para que los dispositivos que tengamos por casa de autoprovisionen. Podríamos haber utilizado radvd, pero ya que se usa Quagga para el OSPF…
- IPv6 address (tap0): indica la IP del extremo del túnel del lado del cliente. Ha de pertenecer a la red de tránsito que hemos definido arriba.
- Redistribute connected: indica que se publicarán rutas para llegar hasta ésta subred por OSPF. De esta manera el servidor sabrá cómo enrutar los paquetes que tengan como destino la subred que hemos elegido y habremos habilitado el enrutamiento entre clientes/casas de frikis y también desde/hacia Internet.
Los que entendáis algo del asunto estaréis pensando que hemos matado moscas a cañonazos. Y tenéis razón. ¿Entonces porqué hacerlo? Porque podemos.
Happy routing!
Saludos!
Muy buen articulo! desde hace tiempo eso es lo que hago para llevar conectividad desde un servidor dedicado en USA ya que el cuenta con una dirección IP fija y muy buena conectividad.
Me gustaría ver la configuración que usaron para OpenVPN en el server y clientes. Actualmente uso tun, Debian y Quagga como router BGP. En otros nodos uso pfSense con OpenBGPD.
Hablo sobre la configuración de OpenVPN porque me gustaría comparar entre tun y tap.
Saludos desde .DO
Aupa Ariel:
El crack del networking es Mike (http://mikeljimenez.net) pero te comento un poco: la configuración que usamos de OpenVPN es muy básica, usamos tap y creamos los clientes con los scripts de easyRSA.
No recuerdo bien, pero creo que algún problema hay con OpenVPN y OSPF por el uso de multicast…
Grande compañeros un gusto saber eso jojo