IPv6 a través de un servidor VPN IPv4 sigue necesitando una salida IPv6

El túnel se levanta, el cliente recibe una dirección IPv6 del pool y, aun así, todos los destinos IPv6 agotan el tiempo. Dentro del túnel no hay nada roto: IPv6 viaja perfectamente dentro del transporte IPv4, y eso nunca fue la parte difícil. La dirección que entregaste es una promesa que el servidor no puede cumplir, porque la salida no tiene ningún upstream IPv6 al que enviarla. La reparación corresponde a la salida, no al perfil del cliente.

El síntoma: una dirección y ningún camino

Una comprobación en el lado del cliente muestra una dirección IPv6 de aspecto global en el dispositivo de túnel y una ruta que apunta hacia ella, y por eso esto se malinterpreta como un fallo del cliente. El tráfico entra en el túnel, el servidor lo desencapsula y luego el paquete aterriza en un host cuya tabla de enrutamiento no tiene ninguna ruta por defecto IPv6 hacia ningún lugar real. Según la pila, obtienes un inalcanzable inmediato o un descarte silencioso, y en ambos casos el cliente ve un tiempo de espera que parece idéntico a un cortafuegos.

Lee la propia tabla de enrutamiento del servidor antes de tocar el cliente, porque ahí es donde vive la mitad que falta del camino. Un servidor con una sola ruta por defecto IPv4 ya te ha dado la respuesta.

Sigue el paquete después de la desencapsulación

Dentro del túnel el paquete es IPv6 corriente y su origen es la dirección del cliente. El servidor retira la encapsulación de transporte y entonces sostiene un paquete IPv6 nativo que debe reenviarse a un siguiente salto IPv6. Una ruta por defecto IPv4 no puede llevarlo, y traducirlo a IPv4 es otra función que nadie desplegó. Ese es todo el fallo, y no tiene nada que ver con si el oyente de VPN respondió por IPv4.

La mecánica de encapsulación de IPv6 sobre IPv4 se describe en el RFC 4213, y el detalle importante allí es que los extremos siguen necesitando conectividad IPv6 real al otro lado del túnel. Envolver una cabecera no hace aparecer un upstream.

Dos capas de túnel, dos comprobaciones independientes

Verifica cada capa por separado, porque un túnel exterior que funciona oculta uno interior roto. Comprueba el camino exterior con un ping IPv4 del cliente al servidor y confirma el puerto que usas. Luego comprueba el camino interior en el servidor, donde ip -6 route debe mostrar una ruta por defecto o una ruta concreta aprendida de un upstream real, y ip -6 addr debe mostrar un prefijo de origen que el upstream acepte. Cualquier cosa menos que eso es decoración en la interfaz.

Una dirección única-local, o un prefijo de aspecto global al que nada enruta de vuelta, aparecerá tan contento en una interfaz y no irá a ninguna parte. La alcanzabilidad pública la concede el upstream, no la forma de la dirección.

Lo mismo se aplica en el cliente: ip -6 route get 2001:4860:4860::8888 debería nombrar el dispositivo de túnel, y si nombra el físico, el cliente no está usando la VPN para IPv6 en absoluto.

Prefijo de origen, tamaño e ICMPv6

Pregunta al upstream qué prefijos de origen aceptará para reenviar, y usa uno de ellos para el pool de clientes. Un proveedor que te da un /64 para la interfaz propia del servidor no necesariamente te enruta un segundo /64 ni un bloque mayor, y la diferencia es una tarde de depuración que un ticket de soporte resuelve con una pregunta. Pregúntalo por escrito y guarda la respuesta junto a la configuración.

Presupuesta la encapsulación extra que tu pila realmente usa, y mantén ICMPv6 funcionando, incluido Packet Too Big. Una segunda cabecera reduce la carga útil, así que un camino que responde a pings pequeños puede fallar igualmente en una transferencia de archivos, y un cortafuegos que descarta todo ICMPv6 convierte un problema de tamaño recuperable en un agujero negro. Prueba una transferencia grande antes de anunciar el servicio.

Qué es un problema completamente distinto

Llegar a una aplicación solo IPv4 desde un cliente solo IPv6 es traducción, no tunelización, y necesita algo como un despliegue deliberado de NAT64. El destino no entenderá una cabecera de túnel extra solo porque hayas añadido una. Los servicios de transición históricos merecen el mismo cuidado: el RFC 7526 retiró el modelo de retransmisión anycast 6to4, así que un tutorial escrito en torno a él describe algo que ya no tiene un retransmisor público mantenido.

Si el servidor no tiene ningún upstream IPv6 utilizable, las opciones son un upstream soportado, una salida distinta o una decisión documentada de que IPv6 se quede fuera del túnel. Lo que no es aceptable es decir a los clientes que existe un servicio IPv6 mientras su conexión IPv6 corriente esquiva la VPN en silencio.