Una red solo IPv6 rompe la VPN antes de que arranque el túnel

El portátil se conecta a un Wi-Fi de congreso que solo reparte IPv6, el cliente VPN gira y falla, y el mismo perfil había funcionado en un hotel una hora antes. Nada ha cambiado en las credenciales. Lo que ha cambiado es que ahora el cliente debe llegar a un destino IPv4 a través de una red que solo transporta IPv6, y no todos los clientes saben cómo hacerlo.

Recorra los mismos cinco pasos que recorren los paquetes.

Paso 1: observe la consulta de nombre

Si el perfil usa un nombre de host, la primera pregunta es qué devuelve el resolutor. dig AAAA vpn.example.com en la red solo IPv6 devuelve un registro AAAA real, uno sintetizado por DNS64 o nada en absoluto. Una respuesta sintetizada codifica el destino IPv4 dentro de un prefijo de traducción, y solo entonces un cliente sin destino IPv6 puede alcanzarlo. Un perfil con una dirección IPv4 fijada nunca llega hasta aquí, porque no hay ningún nombre que sintetizar.

Esa única diferencia explica la mayoría de los informes «allí funciona, aquí falla», y hace falta un solo comando para verlo.

Paso 2: mire qué familia ha marcado el cliente

Mire el socket en lugar de la barra de progreso. Un cliente que abre un socket IPv4 hacia una dirección IPv4 en un enlace solo IPv6 no tiene dónde enviarlo, y el fallo aparece como un tiempo de espera en vez de un error de nombre. ss -tanp mientras el cliente se conecta muestra la dirección remota y la familia que ha intentado. Compárelo con ip -6 route para confirmar que la ruta por defecto es un salto IPv6 real.

La familia de direcciones de la tabla de sockets es el hecho. La barra de progreso es un resumen que escribió otra persona.

Paso 3: separe la traducción del túnel

NAT64 y DNS64 son cómo la red de acceso llega a destinos IPv4, y no hacen nada por el túnel una vez levantado. Un túnel establecido sobre una ruta traducida sigue negociando su propio direccionamiento interior, y la cobertura interior IPv4 o IPv6 es una cuestión de política aparte. Si el cliente se conecta y luego no llega a nada, ya ha pasado la traducción y está en el enrutamiento, que es otra investigación con otras pruebas.

El fallo de la traducción parece no conectar nunca. El fallo de la cobertura interior parece conectar y no llegar a nada.

Paso 4: pruebe el mismo perfil en otra red

Lleve el mismo perfil, versión de cliente y credenciales a una red de doble pila y repita. Si allí funciona y falla en la ruta solo IPv6, la variable es la red de acceso y no el perfil. Anote la versión del cliente y el estado de la red en el ticket, porque la solución final es una actualización del cliente u otro destino.

Un informe que dice que la VPN está rota no es accionable. Un informe que dice que falla solo en acceso solo IPv6 es un informe de error.

Paso 5: arregle la ruta, no la configuración de seguridad

Todas las reparaciones tentadoras empeoran las cosas. Desactivar IPv6 elimina la única ruta que ofrece la red. Apuntar el cliente a un resolutor público rompe la síntesis DNS64, porque esa síntesis tiene que venir del resolutor que hay detrás del traductor. Desactivar la verificación de certificados le da una conexión con algo que no puede identificar. Ninguna de ellas es una reparación, y dos son regresiones de seguridad que sobrevivirán al incidente.

Las opciones reales son un cliente que admita el modelo de traducción de red o un destino con una dirección IPv6 accesible. Pida una de las dos.