Miks muutuvad DNS64 vastused kohe, kui VPN ühendub?

DNS64 vastused kirjeldavad võrgu korraldust, mitte serveri omadust. Resolver sünteesib IPv6 aadressi IPv4 aadressist ja tulemus töötab ainult seal, kus selle prefiksi lõpus istub tõlkija. Tooge VPN teele ja see korraldus võib püsida, muutuda või lakkada kehtimast sõltuvalt kolmest tingimusest.

Need tingimused on vastanud resolver, marsruut, mis teie seadmel sünteesitud prefiksini on, ja see, kas miski sellel marsruudil tõlget teostab. Igaüks neist on vaadeldav ja just see teeb rikke diagnoositavaks.

Millele sünteesitud AAAA-kirje tegelikult osutab

DNS64 resolver vastab ainult IPv4 nime AAAA päringule, põimides IPv4 aadressi prefiksisse, mille kasutamiseks see on seadistatud, ja selle töö jaoks tuntud prefiks on 64:ff9b::/96 nii, nagu on kirjeldatud dokumendis RFC 6147. Rakenduse jaoks näeb kirje välja nagu iga teine AAAA-kirje ja see ongi mõte: ainult IPv6 klient saab ühendust proovida teadmata, et sihtkohal ei olnud kunagi IPv6-t. See ühendus sõltub siis NAT64 funktsioonist, mis kuskil teel kahe perekonna vahel tõlgib. Ilma selle tõlkijata on sünteesitud aadress usutavana näiv sihtkoht, mis ei vii kuhugi.

Kirje kodeerib seega korraga kahte asja: algset IPv4 aadressi ja eeldust, et tõlkija on kättesaadav. Ainult esimene on vastuses endas nähtav.

Kolm tingimust otsustavad, kas see veel töötab

Esimene tingimus on, milline resolver kirje tootis, sest ilma seadistatud DNS64-ta resolver ei tagasta selle nime jaoks midagi ja rakendus ebaõnnestub teisiti. Teine on, kas teie seadmel on marsruut sünteesitud prefiksini, sest vastus võib olla kehtiv, samal ajal kui tee sinna puudub. Kolmas on, kas seda prefiksit omav tõlkija on teel, mida te kasutaksite, sest tunnel, mis viib 64:ff9b::/96 mujale, jõuab teise funktsioonini või mitte millenigi. Kõik kolm võivad enne tunnelit kehtida ja pärast seda ebaõnnestuda ning seetõttu näeb sümptom välja nagu äkiline regressioon.

Kontrollige neid selles järjekorras. Puuduv vastus ja puuduv marsruut näevad brauseris ühesugused välja ja resolveri logis täiesti erinevad.

Kui resolver muutub, muutub vastus

VPN klient surub sageli peale oma resolveri või võtab kogu päringutee üle ja see resolver ei pruugi midagi sünteesida. Päringud ainult IPv4 nimede jaoks ei tagasta siis AAAA-kirjet, mida ainult IPv6 klient kogeb nimena, milleni ei saa. Juhtub ka vastupidist: resolver, mis tõesti sünteesib, võib anda teile prefiksi, mida teie tunneliga tee ei kanna.

Vahemälu teeb selle raskemini nähtavaks. Kontorivõrgus saadud sünteesitud kirje võib üle elada selle konteksti, mis selle tootis, nii et klient jätkab ühendamist aadressiga, mille tõlkija ei ole enam kättesaadav. Vaadake resolverit, mis vastab praegu, mitte seda, mis vastas kirje salvestamise ajal. Vahemälu tühjendamine ilma vana ja uue vastuse kirjapanekuta hävitab tõendi, mida vajate.

Testige päringut ja teed eraldi

Pärige nime otse enne rakenduse kaasamist ja märkige, milline server vastas. Allolevad käsud näitavad AAAA-kirjet, kasutatavat resolverit ja seda, kas sünteesitud prefiksini on marsruut olemas. Käivitage need tunneliga maas ja seejärel uuesti tunneliga üleval.

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/

Lugege tulemusi ahelana. Puuduv AAAA-kirje tähendab, et teie ees olev resolver ei sünteesi, seega ainult IPv6 tee selle nime jaoks ei tööta, mida iganes klient teeb. Kirje on olemas, kuid marsruut puudub — prefiksi ei kanna praegune tee ja see on marsruutimisotsus, mitte resolveri rike. Marsruut on olemas, kuid päring ikka ebaõnnestub — see osutab tõlkijale endale ja kuulub juba teisele omanikule.

Kirjutage resolver, võrgukontekst ja aadressiperekond iga tulemuse kõrvale. Just see märge lubab järgmisel võrdlusel eraldada resolveri muutust marsruutimise muutusest.