Zakaj se odgovori DNS64 spremenijo takoj, ko se poveže VPN?

Odgovori DNS64 opisujejo omrežno ureditev, ne lastnosti strežnika. Razreševalnik sintetizira naslov IPv6 iz naslova IPv4, in rezultat deluje le tam, kjer na koncu te predpone stoji prevajalnik. Vnesite VPN na pot in ta ureditev lahko zdrži, se spremeni ali preneha biti resnična glede na tri pogoje.

Ti pogoji so razreševalnik, ki je odgovoril, pot, ki jo ima vaša naprava do sintetizirane predpone, in to, ali karkoli na tej poti izvaja prevajanje. Vsak je opazljiv, in prav to naredi okvaro diagnostično.

Na kaj sintetizirani zapis AAAA v resnici kaže

Razreševalnik DNS64 odgovori na poizvedbo AAAA za ime, ki ima samo IPv4, tako da naslov IPv4 vgradi v predpono, ki je konfigurirana za uporabo, in dobro znana predpona za to delo je 64:ff9b::/96, kot je opisano v RFC 6147. Zapis se aplikaciji zdi kot vsak drug zapis AAAA, in to je bistvo: odjemalec s samo IPv6 lahko poskusi povezavo, ne da bi vedel, da cilj nikoli ni imel IPv6. Ta povezava je nato odvisna od funkcije NAT64, ki nekje na poti prevaja med družinama. Brez tega prevajalnika je sintetizirani naslov verjetno videti cilj, ki ne vodi nikamor.

Zapis torej kodira dve stvari hkrati: izvirni naslov IPv4 in predpostavko, da je prevajalnik dosegljiv. V samem odgovoru je viden le prvi.

Trije pogoji odločajo, ali še deluje

Prvi pogoj je, kateri razreševalnik je ustvaril zapis, saj tisti brez konfiguriranega DNS64 za to ime ne vrne ničesar in aplikacija odpove drugače. Drugi je, ali ima vaša naprava pot do sintetizirane predpone, ker je odgovor lahko veljaven, medtem ko pot do njega manjka. Tretji je, ali je prevajalnik, ki ima to predpono, na poti, ki bi jo uporabili, ker tunel, ki nosi 64:ff9b::/96 drugam, doseže drugo funkcijo ali nič. Vsi trije lahko veljajo pred tunelom in odpovejo za njim, zato je simptom videti kot nenaden regres.

Preverite jih v tem vrstnem redu. Manjkajoč odgovor in manjkajoča pot sta v brskalniku videti enako, v dnevniku razreševalnika pa povsem drugače.

Ko se razreševalnik spremeni, se odgovor spremeni

Odjemalec VPN pogosto vsili svoj razreševalnik ali prevzame celotno pot poizvedbe, in ta razreševalnik morda ne sintetizira ničesar. Poizvedbe za imena s samo IPv4 potem ne vrnejo zapisa AAAA, kar odjemalec s samo IPv6 doživi kot ime, do katerega ne more priti. Zgodi se tudi obratno: razreševalnik, ki res sintetizira, vam lahko da predpono, ki je vaša tunelirana pot ne nosi.

Predpomnjenje to oteži videti. Sintetiziran zapis, pridobljen v pisarniškem omrežju, lahko preživi kontekst, ki ga je ustvaril, zato se odjemalec še naprej povezuje z naslovom, katerega prevajalnik ni več dosegljiv. Poglejte razreševalnik, ki odgovarja zdaj, ne tistega, ki je odgovoril, ko je bil vnos shranjen. Čiščenje predpomnilnika brez zapisa starega in novega odgovora uniči dokaz, ki ga potrebujete.

Preizkusite poizvedbo in pot ločeno

Povprašajte po imenu neposredno, preden vključite aplikacijo, in zabeležite, kateri strežnik je odgovoril. Spodnji ukazi prikažejo zapis AAAA, uporabljeni razreševalnik in to, ali pot do sintetizirane predpone obstaja. Zaženite jih s spuščenim tunelom in nato znova z dvignjenim.

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/

Rezultate berite kot verigo. Manjkajoč zapis AAAA pomeni, da razreševalnik pred vami ne sintetizira, zato pot s samo IPv6 za to ime ne bo delovala, ne glede na to, kaj odjemalec naredi. Zapis je, poti pa ni — predpone ne nosi trenutna pot, in to je odločitev o usmerjanju, ne okvara razreševalnika. Pot je, zahteva pa še vedno ne uspe — to kaže na sam prevajalnik, in to pripada drugemu lastniku.

Zabeležite razreševalnik, omrežni kontekst in družino naslovov ob vsakem rezultatu. Prav ta zapisek omogoči naslednji primerjavi, da loči spremembo razreševalnika od spremembe usmerjanja.