Hvorfor ændrer DNS64-svar sig, når VPN'et kobler på?

DNS64-svar beskriver et netværksarrangement frem for en egenskab ved serveren. Resolveren syntetiserer en IPv6-adresse ud fra en IPv4-adresse, og resultatet virker kun, hvor der sidder en oversætter i enden af det præfiks. Bring en VPN ind i vejen, og det arrangement kan holde, ændre sig eller holde op med at være sandt afhængigt af tre betingelser.

De betingelser er den resolver, der svarede, den rute din enhed har til det syntetiserede præfiks, og om noget på den rute udfører oversættelsen. Hver af dem kan observeres, og det er netop, hvad der gør fejlen diagnosticerbar.

Hvad et syntetiseret AAAA-record egentlig peger på

En DNS64-resolver besvarer en AAAA-forespørgsel for et navn, der kun har IPv4, ved at indlejre IPv4-adressen i et præfiks, den er konfigureret til at bruge, og det velkendte præfiks til det arbejde er 64:ff9b::/96 som beskrevet i RFC 6147. Recorden ser for applikationen ud som enhver anden AAAA-record, og det er pointen: en klient, der kun har IPv6, kan forsøge en forbindelse uden at vide, at destinationen aldrig havde IPv6. Den forbindelse afhænger så af en NAT64-funktion, der et sted på vejen oversætter mellem de to familier. Uden den oversætter er den syntetiserede adresse en troværdigt udseende destination, der fører ingen steder hen.

Recorden koder altså to ting på én gang: den oprindelige IPv4-adresse og antagelsen om, at en oversætter kan nås. Kun det første er synligt i selve svaret.

Tre betingelser afgør, om det stadig virker

Den første betingelse er, hvilken resolver der producerede recorden, for en uden konfigureret DNS64 returnerer intet for det navn, og applikationen fejler på en anden måde. Den anden er, om din enhed har en rute til det syntetiserede præfiks, fordi et svar kan være gyldigt, mens vejen til det mangler. Den tredje er, om den oversætter, der ejer præfikset, er på den vej, du ville bruge, fordi en tunnel, der bærer 64:ff9b::/96 andre steder hen, når en anden funktion eller slet intet. Alle tre kan holde før tunnelen og fejle efter den, og derfor ligner symptomet en pludselig regression.

Kontroller dem i den rækkefølge. Et manglende svar og en manglende rute ser ens ud i en browser og helt forskellige ud i en resolverlog.

Når resolveren skifter, skifter svaret

En VPN-klient skubber ofte sin egen resolver ind eller overtager hele forespørgselsvejen, og den resolver syntetiserer måske ingenting. Forespørgsler efter navne med kun IPv4 giver så ingen AAAA-record, hvilket en klient med kun IPv6 oplever som et navn, den ikke kan nå. Det omvendte sker også: en resolver, der faktisk syntetiserer, kan give dig et præfiks, som din tunnellerede vej ikke bærer.

Caching gør det sværere at se. En syntetiseret record hentet på kontornetværket kan overleve den kontekst, der frembragte den, så klienten bliver ved med at forbinde til en adresse, hvis oversætter ikke længere kan nås. Se på den resolver, der svarer nu, i stedet for den, der svarede, da posten blev gemt. Tømning af cachen uden at notere det gamle og det nye svar ødelægger det bevis, du har brug for.

Test opslaget og vejen hver for sig

Forespørg på navnet direkte, før du inddrager applikationen, og noter, hvilken server der svarede. Kommandoerne nedenfor viser AAAA-record'en, den resolver der bruges, og om der findes en rute til det syntetiserede præfiks. Kør dem med tunnelen nede og igen med den oppe.

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/

Læs resultaterne som en kæde. En manglende AAAA-record betyder, at resolveren foran dig ikke syntetiserer, så en vej med kun IPv6 vil ikke virke for det navn, uanset hvad klienten gør. En record til stede uden rute betyder, at præfikset ikke bæres af den aktuelle vej, og det er en routingbeslutning frem for en resolverfejl. En rute til stede, mens anmodningen stadig fejler, peger på selve oversætteren, og det tilhører en helt anden ejer.

Noter resolveren, netværkskonteksten og adressefamilien ved siden af hvert resultat. Den note er det, der lader den næste sammenligning skelne et resolverskift fra et routingskift.