VPN de doble pila: el cliente elige la familia de direcciones, no usted

El túnel está levantado, los sitios IPv4 cargan y un nombre de host agota el tiempo. La conclusión inmediata es que la VPN está rota o que las credenciales son incorrectas, y normalmente ninguna de las dos cosas es cierta. El nombre devolvió una dirección IPv4 y una IPv6, la aplicación eligió una, y solo uno de esos candidatos tenía una ruta funcional. El cliente tomó una decisión de selección; el túnel simplemente no cubría lo que había seleccionado.

Elegir no es prometer cobertura

La selección de dirección predeterminada, descrita en el RFC 6724, decide qué par de origen y destino prefiere un host cuando hay varios disponibles. Happy Eyeballs añade una estrategia de conexión por encima: inicia intentos en ambas familias y se queda con la que responde primero, para que el usuario no espere a que una familia rota agote el tiempo.

Ninguno de los dos mecanismos crea una ruta. Si su túnel solo transporta IPv4, un candidato AAAA sigue siendo un destino legítimo que el cliente puede probar, y el fallo se manifiesta como una carga lenta y no como un error, porque el navegador retrocedió. El usuario informa de un sitio lento, no roto, y el ticket de soporte hereda esa vaguedad. Reproduzca el caso con una familia fija y el informe se vuelve concreto.

Ese retroceso es la razón de que el síntoma sea inconsistente entre aplicaciones. Un navegador oculta el retardo; un cliente de línea de comandos con una familia fija le muestra el fallo real de inmediato.

Averigüe qué familia usó realmente la petición

Empiece por el nombre, no por el túnel. Consulte ambos tipos de registro y anote qué volvió:

dig +short A example.com
dig +short AAAA example.com
curl -4 -sS -o /dev/null -w '%{http_code}\n' https://example.com
curl -6 -sS -o /dev/null -w '%{http_code}\n' https://example.com

Si la petición v4 tiene éxito y la v6 falla, ha reproducido el problema en una forma que puede depurar. Si ambas funcionan desde el intérprete y el navegador sigue fallando, revise el resolutor propio de la aplicación o una respuesta en caché antes de tocar el túnel.

Guarde la familia y el destino en sus notas. Un ticket que dice que el sitio no carga por la VPN no lo puede comprobar nadie, mientras que uno que dice que AAAA falla y A funciona apunta a una ruta concreta.

Compruebe la ruta de esa familia

Para la familia que falla, pregunte al núcleo qué camino usaría y compárelo con las direcciones configuradas del túnel. En Linux, ip -6 route get para el destino muestra la interfaz y el origen que se seleccionarían.

Después compruebe el propio túnel. Los pares de WireGuard llevan una lista de IP permitidas, y una entrada para 0.0.0.0/0 no dice nada sobre IPv6. Si la lista del par no tiene ningún prefijo IPv6, el cliente no tiene motivo para enviar tráfico AAAA al túnel, y el paquete sale por lo que el host haría de otro modo.

Las reglas de cortafuegos y la política NAT merecen la misma comprobación por familia. Una regla escrita para IPv4 no cubre IPv6 en ninguna plataforma, y es la razón más habitual de que una familia funcione y la otra no.

No desactive IPv6 para simplificar la captura de pantalla

Desactivar IPv6 en todo el sistema hará desaparecer el síntoma y le dejará sin diagnóstico. También rompe cualquier destino que sea solo IPv6, y esconde el mismo fallo para la siguiente aplicación. Si una máquina realmente no debería usar IPv6, eso es una política deliberada con un propietario y una prueba. Desactivarlo durante un incidente no es ni una cosa ni la otra.

Decida qué debe hacer el cliente con la familia y configúrelo explícitamente: llévela por el túnel, o bloquéela de forma admitida para que la selección nunca ofrezca un candidato inalcanzable. Ambos son diseños legítimos. Una desactivación global no es ninguno de los dos, porque no es un diseño en absoluto.

Qué poner en el ticket

Anote cuatro cosas: el nombre de host, la familia que falló, la ruta que eligió el núcleo y el resultado de una petición específica de la familia. Ese conjunto basta para que otra persona reproduzca el fallo sin adivinar cuál de los dos caminos quería decir.

Las reglas de selección de direcciones del RFC 6724 explican por qué el cliente prefirió el candidato que prefirió, y el RFC 8305 explica el comportamiento de carrera que ocultó el retardo. Ninguna de las dos encaminará un paquete por usted, y esa es la parte que el túnel tiene que hacer.