Por que cambian as respostas DNS64 en canto se conecta a VPN?
Unha resposta DNS64 codifica unha suposición de tradución. Comprobe que resolución respondeu, se o prefixo está encamiñado e se hai un tradutor na súa ruta.
As respostas DNS64 describen unha disposición de rede, non unha propiedade do servidor. O resolutor sintetiza un enderezo IPv6 a partir dun IPv4, e o resultado só funciona onde hai un tradutor ao final dese prefixo. Introduza unha VPN na ruta e esa disposición pode manterse, cambiar ou deixar de ser certa segundo tres condicións.
Esas condicións son o resolutor que respondeu, a ruta que o seu dispositivo ten cara ao prefixo sintetizado e se algo nesa ruta realiza a tradución. Cada unha é observable, e iso é o que fai diagnosticable o fallo.
A que apunta realmente un rexistro AAAA sintetizado
Un resolutor DNS64 responde a unha consulta AAAA dun nome só IPv4 incrustando o enderezo IPv4 dentro dun prefixo que ten configurado para usar, e o prefixo ben coñecido para esa tarefa é 64:ff9b::/96 tal como se describe en RFC 6147. O rexistro parece calquera outro rexistro AAAA para a aplicación, e esa é a idea: un cliente só IPv6 pode tentar unha conexión sen saber que o destino nunca tivo IPv6. Esa conexión depende entón dunha función NAT64 que traduce entre as dúas familias nalgún punto da ruta. Sen ese tradutor, o enderezo sintetizado é un destino de aspecto plausible que non leva a ningures.
O rexistro, xa que logo, codifica dúas cousas á vez: o enderezo IPv4 orixinal e a suposición de que hai un tradutor accesible. Só a primeira é visible na propia resposta.
Tres condicións deciden se segue funcionando
A primeira condición é que resolutor produciu o rexistro, xa que un sen DNS64 configurado non devolve nada para ese nome e a aplicación falla doutro xeito. A segunda é se o seu dispositivo ten unha ruta cara ao prefixo sintetizado, porque unha resposta pode ser válida mentres falta o camiño cara a ela. A terceira é se o tradutor dono dese prefixo está na ruta que vostede usaría, porque un túnel que leva 64:ff9b::/96 a outro sitio alcanza outra función ou nada. As tres poden cumprirse antes do túnel e fallar despois, e por iso o síntoma parece unha regresión repentina.
Compruébeas nesa orde. Unha resposta ausente e unha ruta ausente vense igual nun navegador e por completo distintas nun rexistro do resolutor.
Cando cambia o resolutor, cambia a resposta
Un cliente VPN adoita impor o seu propio resolutor ou asumir toda a ruta da consulta, e ese resolutor pode non sintetizar nada. As consultas de nomes só IPv4 entón non devolven ningún rexistro AAAA, o que un cliente só IPv6 vive como un nome ao que non pode chegar. Tamén ocorre o contrario: un resolutor que si sintetiza pode darlle un prefixo que a súa ruta tunelizada non transporta.
A caché fai que isto sexa máis difícil de ver. Un rexistro sintetizado obtido na rede da oficina pode sobrevivir ao contexto que o produciu, así que o cliente segue conectando a un enderezo cuxo tradutor xa non é accesible. Mire o resolutor que responde agora e non o que respondeu cando se gardou a entrada. Baleirar a caché sen rexistrar a resposta antiga e a nova destrúe a proba que necesita.
Probe a consulta e a ruta por separado
Consulte o nome directamente antes de involucrar a aplicación, e anote que servidor respondeu. Os comandos de abaixo mostran o rexistro AAAA, o resolutor en uso e se existe unha ruta cara ao prefixo sintetizado. Execúteos co túnel baixado e logo outra vez con el 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 os resultados como unha cadea. Un rexistro AAAA ausente significa que o resolutor que ten diante non sintetiza, así que unha ruta só IPv6 non funcionará para ese nome faga o que faga o cliente. Un rexistro presente sen ruta significa que o prefixo non o transporta a ruta actual, e iso é unha decisión de encamiñamento e non un fallo do resolutor. Unha ruta presente mentres a petición segue fallando apunta ao propio tradutor, e iso pertence a outro dono.
Anote o resolutor, o contexto de rede e a familia de enderezos xunto a cada resultado. Esa nota é a que permite á seguinte comparación separar un cambio de resolutor dun cambio de encamiñamento.