IPv6 a través de un túnel OpenVPN: recorrido por el router de casa

El portátil tiene una dirección IPv6, el túnel está levantado sobre IPv4 y, aun así, todas las pruebas IPv6 fallan. O peor: la prueba sale bien y el tráfico salió por la ruta del proveedor sin entrar nunca en el túnel. Ambos resultados remiten a una decisión que falta: nadie dio al router un prefijo que pudiera enrutar hacia los clientes. Recorrer el camino desde el cliente hacia fuera descubre qué pieza falta.

Empieza donde está el cliente

Mira al cliente antes de tocar el servidor. ip -6 addr debería mostrar una dirección de túnel del pool, y ip -6 route debería mostrar el prefijo empujado que apunta al dispositivo de túnel. Cuando la dirección está pero la ruta no, falta el push o el cliente lo ignoró. Cuando no está ninguna de las dos, el servidor no asignó absolutamente nada.

Después comprueba qué cree el cliente sobre el mundo exterior. Una ruta por defecto por el túnel reclama todo el tráfico IPv6, mientras que una ruta para 2000::/3 solo reclama unicast global. Ambas pueden ser correctas y responden preguntas distintas sobre las fugas.

Un cliente sin ninguna ruta por defecto IPv6 falla todas las pruebas públicas mientras el túnel está perfectamente sano. Eso es un hueco de política, no un túnel roto.

Comprueba el pool que el servidor puede enrutar de verdad

Un servidor solo puede asignar de un prefijo que controla de verdad. Si el proveedor delega un /56, reserva un /64 para el túnel y deja el resto para la LAN. Cuando el proveedor entrega un solo /64 en la WAN y no enruta nada más, deja el prefijo de la LAN tranquilo y da al túnel un rango local único, aceptando que los clientes no tendrán salida global.

El pool y el push van juntos. server-ipv6 2001:db8:80:10::/64 asigna direcciones y push "route-ipv6 2000::/3" dice a los clientes qué enviar al túnel. Empujar 2000::/3 cubre el unicast global y deja los rangos link-local y multicast fuera del túnel.

Escribe el prefijo elegido en el registro de despliegue. Quien cambie la entrega del proveedor la próxima vez necesita saber qué /64 ocupa ya el túnel.

Activa el reenvío para la segunda familia

El reenvío IPv4 no implica el reenvío IPv6. Define net.ipv6.conf.all.forwarding=1 y replica todo lo que la política FORWARD de IPv4 ya permite. En un router cuya cadena FORWARD descarta por defecto, un conjunto de reglas ausente se ve exactamente como un túnel muerto.

El apretón de manos tiene éxito, el cliente recibe una dirección y no vuelve nada. Añade reglas para ambas direcciones y para el tramo WAN, porque un túnel que llega a la LAN pero no a internet falla la tercera prueba. Revisa los contadores de la cadena tras un intento fallido, porque una regla que nunca coincidió es un problema distinto de una que coincidió y descartó.

ip6tables -A FORWARD -i br0 -o tun0 -j ACCEPT
ip6tables -A FORWARD -i tun0 -o br0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
ip6tables -A FORWARD -i tun0 -o wan0 -j ACCEPT

Un efecto secundario atrapa a quienes acaban culpando al túnel. Al activar el reenvío, el núcleo se salta la configuración de dirección por Router Advertisement si no se le dice lo contrario, y una ruta por defecto aprendida así desaparece con ella. O fija una ruta por defecto explícita en la interfaz WAN, o pon accept_ra a 2 allí a propósito. Tras cualquiera de los dos cambios, confirma que el router sigue teniendo un camino IPv6 válido hacia fuera antes de volver a probar los clientes.

Responde al descubrimiento de vecinos cuando el extremo superior no enruta

El equipo del extremo superior a veces trata el /64 delegado como propio de su enlace y se niega a enrutar cualquier subprefijo hacia la caja VPN. Cuando eso pasa, algo tiene que responder las solicitudes de vecinos de cada dirección de cliente por separado.

OpenVPN expone la dirección asignada a un hook client-connect, así las entradas pueden seguir el pool real en lugar de una lista mantenida a mano. El hook añade ip -6 neigh add proxy $ifconfig_pool_remote_ip6 dev eth0, y un hook client-disconnect correspondiente lo retira. Sin esa retirada, la tabla de proxy se queda obsoleta y un cliente posterior puede heredar una entrada de una dirección que nunca recibió. Confirma el estado con ip -6 neigh show proxy.

Trata el proxying como un parche. Una ruta estática para el /64 del túnel apuntada al router sobrevive a los cambios de clientes y no necesita ningún hook de shell con privilegios.

Sigue el camino hacia fuera, salto a salto

Prueba hacia fuera en tres pasos: primero la dirección de túnel del router, luego un host de la LAN y tercero un destino público con traceroute6. El pool lo demuestra el primer paso, el reenvío y el cortafuegos de la LAN el segundo, y el camino de vuelta por el extremo superior el tercero. Cada fallo estrecha la búsqueda a un solo dispositivo en lugar de reabrir todo el diseño.

Vigila la MTU del túnel, porque los routers IPv6 del camino no fragmentarán por ti. Una MTU demasiado grande se manifiesta como un error packet-too-big y un TLS atascado en lugar de un fallo limpio. Fíjala explícitamente y prueba con una carga cerca del límite.