Hvorfor endrer DNS64-svar seg så snart VPN-et kobler til?

DNS64-svar beskriver et nettverksoppsett framfor en egenskap ved serveren. Resolveren syntetiserer en IPv6-adresse fra en IPv4-adresse, og resultatet virker bare der en oversetter sitter i enden av prefikset. Ta et VPN inn i veien, og det oppsettet kan holde, endre seg eller slutte å være sant avhengig av tre betingelser.

Disse betingelsene er resolveren som svarte, ruten enheten din har til det syntetiserte prefikset, og om noe på den ruten gjør oversettelsen. Hver av dem kan observeres, og det er nettopp det som gjør feilen diagnostiserbar.

Hva en syntetisert AAAA-post egentlig peker på

En DNS64-resolver besvarer en AAAA-forespørsel for et navn som bare har IPv4 ved å bygge IPv4-adressen inn i et prefiks den er konfigurert til å bruke, og det velkjente prefikset for den jobben er 64:ff9b::/96 slik det er beskrevet i RFC 6147. Posten ser for applikasjonen ut som enhver annen AAAA-post, og det er poenget: en klient som bare har IPv6, kan forsøke en forbindelse uten å vite at målet aldri hadde IPv6. Den forbindelsen avhenger så av en NAT64-funksjon som et sted på veien oversetter mellom de to familiene. Uten den oversetteren er den syntetiserte adressen et troverdig utseende mål som ikke fører noe sted.

Posten koder altså to ting på én gang: den opprinnelige IPv4-adressen og antakelsen om at en oversetter er nåbar. Bare det første er synlig i selve svaret.

Tre betingelser avgjør om det fortsatt virker

Den første betingelsen er hvilken resolver som produserte posten, siden en uten konfigurert DNS64 ikke returnerer noe for det navnet, og applikasjonen feiler på en annen måte. Den andre er om enheten din har en rute til det syntetiserte prefikset, fordi et svar kan være gyldig mens veien dit mangler. Den tredje er om oversetteren som eier prefikset, er på veien du ville brukt, fordi en tunnel som bærer 64:ff9b::/96 et annet sted, når en annen funksjon eller ingenting. Alle tre kan holde før tunnelen og feile etter den, og derfor ser symptomet ut som en plutselig regresjon.

Sjekk dem i den rekkefølgen. Et manglende svar og en manglende rute ser like ut i en nettleser og helt forskjellige ut i en resolverlogg.

Når resolveren endres, endres svaret

En VPN-klient skyver ofte inn sin egen resolver eller tar over hele forespørselsveien, og den resolveren syntetiserer kanskje ingenting. Forespørsler etter navn som bare har IPv4 gir da ingen AAAA-post, noe en klient som bare har IPv6 opplever som et navn den ikke når. Det motsatte skjer også: en resolver som faktisk syntetiserer, kan gi deg et prefiks som den tunnelierte veien din ikke bærer.

Bufring gjør dette vanskeligere å se. En syntetisert post hentet på kontornettverket kan overleve konteksten som laget den, slik at klienten fortsetter å koble til en adresse der oversetteren ikke lenger er nåbar. Se på resolveren som svarer nå, i stedet for den som svarte da oppføringen ble lagret. Å tømme bufferen uten å notere det gamle og det nye svaret ødelegger beviset du trenger.

Test oppslaget og veien hver for seg

Spør direkte på navnet før du trekker inn applikasjonen, og noter hvilken server som svarte. Kommandoene nedenfor viser AAAA-posten, resolveren som brukes, og om det finnes en rute til det syntetiserte prefikset. Kjør dem med tunnelen nede og deretter igjen 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/

Les resultatene som en kjede. En manglende AAAA-post betyr at resolveren foran deg ikke syntetiserer, så en vei som bare har IPv6 vil ikke virke for det navnet, uansett hva klienten gjør. En post som finnes uten rute betyr at prefikset ikke bæres av den gjeldende veien, og det er en rutingsbeslutning og ikke en resolverfeil. En rute som finnes mens forespørselen fortsatt feiler, peker på selve oversetteren, og det tilhører en annen eier.

Noter resolveren, nettverkskonteksten og adressefamilien ved siden av hvert resultat. Den noten er det som lar den neste sammenligningen skille et resolverskifte fra et rutingsskifte.