Kvifor endrar DNS64-svar seg så snart VPN-et koplar til?

Eit DNS64-svar kodar ei føresetnad om omsetjing. Sjekk kva resolver som svara, om prefikset er ruta, og om det sit ein omsetjar på vegen din.

DNS64-svar skildrar eit netverksoppsett og ikkje ein eigenskap ved tenaren. Resolveren syntetiserer ein IPv6-adresse frå ein IPv4-adresse, og resultatet verkar berre der ein omsetjar sit i enden av prefikset. Ta eit VPN inn i vegen, og det oppsettet kan halde, endre seg eller slutte å vere sant avhengig av tre vilkår.

Desse vilkåra er resolveren som svara, ruta eininga di har til det syntetiserte prefikset, og om noko på den ruta gjer omsetjinga. Kvar av dei kan observerast, og det er nettopp det som gjer feilen diagnostiserbar.

Kva ein syntetisert AAAA-post eigentleg peikar på

Ein DNS64-resolver svarar på ein AAAA-førespurnad for eit namn som berre har IPv4 ved å byggje IPv4-adressa inn i eit prefiks han er konfigurert til å bruke, og det velkjende prefikset for den jobben er 64:ff9b::/96 slik det er skildra i RFC 6147. Posten ser for applikasjonen ut som kvar annan AAAA-post, og det er poenget: ein klient som berre har IPv6, kan prøve ei tilkopling utan å vite at målet aldri hadde IPv6. Den tilkoplinga avheng då av ein NAT64-funksjon som ein stad på vegen omset mellom dei to familiane. Utan den omsetjaren er den syntetiserte adressa eit truverdig utsjåande mål som ikkje fører nokon stad.

Posten kodar altså to ting på ein gong: den opphavlege IPv4-adressa og føresetnaden om at ein omsetjar er nåbar. Berre det første er synleg i sjølve svaret.

Tre vilkår avgjer om det framleis verkar

Det første vilkåret er kva resolver som laga posten, sidan ein utan konfigurert DNS64 ikkje returnerer noko for det namnet, og applikasjonen feilar på ein annan måte. Det andre er om eininga di har ei rute til det syntetiserte prefikset, fordi eit svar kan vere gyldig medan vegen dit manglar. Det tredje er om omsetjaren som eig prefikset, er på vegen du ville bruke, fordi ein tunnel som ber 64:ff9b::/96 ein annan stad, når ein annan funksjon eller ingenting. Alle tre kan halde før tunnelen og feile etter han, og difor ser symptomet ut som ein brå regresjon.

Sjekk dei i den rekkjefølgja. Eit manglande svar og ei manglande rute ser like ut i ein nettlesar og heilt forskjellige ut i ein resolverlogg.

Når resolveren blir endra, blir svaret endra

Ein VPN-klient dyttar ofte inn sin eigen resolver eller tek over heile førespurnadsvegen, og den resolveren syntetiserer kanskje ingenting. Førespurnader etter namn som berre har IPv4 gir då ingen AAAA-post, noko ein klient som berre har IPv6 opplever som eit namn han ikkje når. Det motsette skjer òg: ein resolver som faktisk syntetiserer, kan gje deg eit prefiks som den tunneliserte vegen din ikkje ber.

Bufring gjer dette vanskelegare å sjå. Ein syntetisert post henta på kontornettverket kan overleve samanhengen som laga han, slik at klienten held fram med å kopie til ei adresse der omsetjaren ikkje lenger er nåbar. Sjå på resolveren som svarar no, i staden for den som svara då oppføringa vart lagra. Å tømme bufferen utan å notere det gamle og det nye svaret øydelegg beviset du treng.

Test oppslaget og vegen kvar for seg

Spør direkte på namnet før du dreg inn applikasjonen, og noter kva tenar som svara. Kommandoane nedanfor viser AAAA-posten, resolveren som blir brukt, og om det finst ei rute til det syntetiserte prefikset. Køyr dei med tunnelen nede og deretter igjen med han 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 resultata som ei kjede. Ein manglande AAAA-post betyr at resolveren framfor deg ikkje syntetiserer, så ein veg som berre har IPv6 vil ikkje verke for det namnet, uansett kva klienten gjer. Ein post som finst utan rute betyr at prefikset ikkje blir bore av den gjeldande vegen, og det er eit rutingsvedtak og ikkje ein resolverfeil. Ei rute som finst medan førespurnaden framleis feilar, peikar på sjølve omsetjaren, og det høyrer til ein annan eigar.

Noter resolveren, nettverkssamanhengen og adressefamilien ved sida av kvart resultat. Den notata er det som lèt den neste samanlikninga skilje eit resolverskifte frå eit rutingsskifte.

Relaterte artiklar