Per què canvien les respostes DNS64 quan es connecta la VPN?

Les respostes DNS64 descriuen una disposició de xarxa, no una propietat del servidor. El resolutor sintetitza una adreça IPv6 a partir d'una IPv4, i el resultat només funciona on hi ha un traductor al final d'aquell prefix. Introduïu una VPN al camí i aquesta disposició pot mantenir-se, canviar o deixar de ser certa segons tres condicions.

Aquestes condicions són el resolutor que ha respost, la ruta que el vostre dispositiu té cap al prefix sintetitzat i si alguna cosa en aquesta ruta fa la traducció. Cadascuna és observable, i això és el que fa diagnosticable la fallada.

A què apunta realment un registre AAAA sintetitzat

Un resolutor DNS64 respon una consulta AAAA per a un nom només IPv4 incrustant l'adreça IPv4 dins d'un prefix que té configurat per utilitzar, i el prefix ben conegut per a aquesta feina és 64:ff9b::/96 tal com es descriu a RFC 6147. El registre sembla qualsevol altre registre AAAA per a l'aplicació, i aquesta és la idea: un client només IPv6 pot provar una connexió sense saber que la destinació mai no ha tingut IPv6. Aquesta connexió depèn llavors d'una funció NAT64 que tradueix entre les dues famílies en algun punt del camí. Sense aquest traductor, l'adreça sintetitzada és una destinació versemblant que no va enlloc.

El registre, doncs, codifica dues coses alhora: l'adreça IPv4 original i la suposició que un traductor és abastable. Només la primera és visible en la resposta mateixa.

Tres condicions decideixen si encara funciona

La primera condició és quin resolutor ha produït el registre, perquè un sense DNS64 configurat no retorna res per a aquell nom i l'aplicació falla d'una manera diferent. La segona és si el vostre dispositiu té una ruta cap al prefix sintetitzat, perquè una resposta pot ser vàlida mentre el camí cap a ella falta. La tercera és si el traductor que posseeix aquell prefix és al camí que faríeu servir, perquè un túnel que porta 64:ff9b::/96 a un altre lloc arriba a una funció diferent o a res. Les tres poden complir-se abans del túnel i fallar després, i per això el símptoma sembla una regressió sobtada.

Comproveu-les en aquest ordre. Una resposta absent i una ruta absent es veuen igual en un navegador i completament diferents en un registre del resolutor.

Quan el resolutor canvia, la resposta canvia

Un client VPN sovint imposa el seu propi resolutor o pren el control de tot el camí de la consulta, i aquell resolutor pot no sintetitzar res. Les consultes de noms només IPv4 aleshores no retornen cap registre AAAA, cosa que un client només IPv6 viu com un nom que no pot abastar. També passa el contrari: un resolutor que sí que sintetitza us pot donar un prefix que el vostre camí tunelitzat no porta.

La memòria cau fa que això sigui més difícil de veure. Un registre sintetitzat obtingut a la xarxa de l'oficina pot sobreviure al context que el va produir, de manera que el client continua connectant-se a una adreça el traductor de la qual ja no és abastable. Mireu el resolutor que respon ara i no el que va respondre quan es va desar l'entrada. Buidar la memòria cau sense enregistrar les respostes vella i nova destrueix la prova que necessiteu.

Proveu la consulta i el camí per separat

Consulteu el nom directament abans d'involucrar l'aplicació, i anoteu quin servidor ha respost. Les ordres següents mostren el registre AAAA, el resolutor en ús i si existeix una ruta cap al prefix sintetitzat. Executeu-les amb el túnel baixat i després tornau-les a executar amb el túnel pujat.

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/

Llegiu els resultats com una cadena. Un registre AAAA absent vol dir que el resolutor que teniu davant no sintetitza, així que un camí només IPv6 no funcionarà per a aquell nom faci el que faci el client. Un registre present sense ruta vol dir que el prefix no el porta el camí actual, i això és una decisió d'encaminament, no una fallada del resolutor. Una ruta present mentre la petició encara falla apunta al traductor mateix, i això pertany a un altre propietari.

Enregistreu el resolutor, el context de xarxa i la família d'adreces al costat de cada resultat. Aquesta nota és el que permet a la comparació següent separar un canvi de resolutor d'un canvi d'encaminament.