¿Por qué cambian las respuestas DNS64 en cuanto se conecta la VPN?

Las respuestas DNS64 describen una disposición de red, no una propiedad del servidor. El resolutor sintetiza una dirección IPv6 a partir de una IPv4, y el resultado solo funciona donde hay un traductor al final de ese prefijo. Meta una VPN en la ruta y esa disposición puede mantenerse, cambiar o dejar de ser cierta según tres condiciones.

Esas condiciones son el resolutor que respondió, la ruta que su dispositivo tiene hacia el prefijo sintetizado y si algo en esa ruta realiza la traducción. Cada una es observable, y eso es lo que hace diagnosticable el fallo.

A qué apunta realmente un registro AAAA sintetizado

Un resolutor DNS64 responde a una consulta AAAA de un nombre solo IPv4 incrustando la dirección IPv4 dentro de un prefijo que tiene configurado para usar, y el prefijo bien conocido para esa tarea es 64:ff9b::/96 tal como se describe en RFC 6147. El registro parece cualquier otro registro AAAA para la aplicación, y esa es la idea: un cliente solo IPv6 puede intentar una conexión sin saber que el destino nunca tuvo IPv6. Esa conexión depende entonces de una función NAT64 que traduce entre las dos familias en algún punto de la ruta. Sin ese traductor, la dirección sintetizada es un destino de aspecto plausible que no lleva a ninguna parte.

El registro, por tanto, codifica dos cosas a la vez: la dirección IPv4 original y la suposición de que hay un traductor accesible. Solo la primera es visible en la propia respuesta.

Tres condiciones deciden si sigue funcionando

La primera condición es qué resolutor produjo el registro, ya que uno sin DNS64 configurado no devuelve nada para ese nombre y la aplicación falla de otra manera. La segunda es si su dispositivo tiene una ruta hacia el prefijo sintetizado, porque una respuesta puede ser válida mientras falta el camino hacia ella. La tercera es si el traductor dueño de ese prefijo está en la ruta que usted usaría, porque un túnel que lleva 64:ff9b::/96 a otro sitio alcanza otra función o nada. Las tres pueden cumplirse antes del túnel y fallar después, y por eso el síntoma parece una regresión repentina.

Compruébelas en ese orden. Una respuesta ausente y una ruta ausente se ven igual en un navegador y por completo distintas en un registro del resolutor.

Cuando cambia el resolutor, cambia la respuesta

Un cliente VPN suele imponer su propio resolutor o asumir toda la ruta de la consulta, y ese resolutor puede no sintetizar nada. Las consultas de nombres solo IPv4 entonces no devuelven ningún registro AAAA, lo que un cliente solo IPv6 vive como un nombre al que no puede llegar. También ocurre lo contrario: un resolutor que sí sintetiza puede darle un prefijo que su ruta tunelizada no transporta.

La caché hace que esto sea más difícil de ver. Un registro sintetizado obtenido en la red de la oficina puede sobrevivir al contexto que lo produjo, así que el cliente sigue conectando a una dirección cuyo traductor ya no es accesible. Mire el resolutor que responde ahora y no el que respondió cuando se guardó la entrada. Vaciar la caché sin registrar la respuesta antigua y la nueva destruye la prueba que necesita.

Pruebe la consulta y la ruta por separado

Consulte el nombre directamente antes de involucrar a la aplicación, y anote qué servidor respondió. Los comandos de abajo muestran el registro AAAA, el resolutor en uso y si existe una ruta hacia el prefijo sintetizado. Ejecútelos con el túnel bajado y luego otra vez con él subido.

dig AAAA ipv4only.example.com +short
dig AAAA ipv4only.example.com | grep -E '^;; SERVER'
ip -6 route get 64:ff9b::c000:0216
curl -6 -sS -o /dev/null -w '%{http_code} %{time_connect}\n' --max-time 8 http://ipv4only.example.com/

Lea los resultados como una cadena. Un registro AAAA ausente significa que el resolutor que tiene delante no sintetiza, así que una ruta solo IPv6 no funcionará para ese nombre haga lo que haga el cliente. Un registro presente sin ruta significa que el prefijo no lo transporta la ruta actual, y eso es una decisión de enrutamiento y no un fallo del resolutor. Una ruta presente mientras la petición sigue fallando apunta al propio traductor, y eso pertenece a otro dueño.

Anote el resolutor, el contexto de red y la familia de direcciones junto a cada resultado. Esa nota es la que permite a la siguiente comparación separar un cambio de resolutor de un cambio de enrutamiento.