Prečo sa odpovede DNS64 menia, hneď ako sa pripojí VPN?

Odpovede DNS64 opisujú usporiadanie siete, nie vlastnosť servera. Resolver syntetizuje adresu IPv6 z adresy IPv4 a výsledok funguje len tam, kde na konci tohto prefixu stojí prekladač. Zaveďte VPN do cesty a toto usporiadanie môže vydržať, zmeniť sa alebo prestať platiť podľa troch podmienok.

Tými podmienkami sú resolver, ktorý odpovedal, trasa, ktorú má vaše zariadenie k syntetizovanému prefixu, a to, či na tej trase niečo vykonáva preklad. Každú možno pozorovať, a práve preto je porucha diagnostikovateľná.

Na čo syntetizovaný záznam AAAA skutočne ukazuje

Resolver DNS64 odpovedá na dopyt AAAA pre meno, ktoré má iba IPv4, tak, že adresu IPv4 vloží do prefixu, ktorý má nakonfigurovaný na používanie, a známy prefix pre túto úlohu je 64:ff9b::/96, ako opisuje RFC 6147. Aplikácia vidí záznam ako každý iný záznam AAAA, a o to ide: klient s iba IPv6 môže vyskúšať spojenie bez toho, aby vedel, že cieľ nikdy nemal IPv6. To spojenie potom závisí od funkcie NAT64, ktorá niekde na trase prekladá medzi oboma rodinami. Bez tohto prekladača je syntetizovaná adresa vierohodne vyzerajúci cieľ, ktorý nikam nevedie.

Záznam teda kóduje dve veci naraz: pôvodnú adresu IPv4 a predpoklad, že prekladač je dostupný. V samotnej odpovedi je viditeľná len prvá.

Tri podmienky rozhodujú, či to ešte funguje

Prvou podmienkou je, ktorý resolver záznam vytvoril, pretože ten bez nakonfigurovaného DNS64 pre to meno nič nevráti a aplikácia zlyhá iným spôsobom. Druhou je, či má vaše zariadenie trasu k syntetizovanému prefixu, pretože odpoveď môže byť platná, kým cesta k nej chýba. Treťou je, či prekladač, ktorý tento prefix vlastní, je na trase, ktorú by ste použili, pretože tunel odnášajúci 64:ff9b::/96 inam dosiahne inú funkciu alebo nič. Všetky tri môžu pred tunelom platiť a po ňom zlyhať, a preto symptóm vyzerá ako náhla regresia.

Kontrolujte ich v tomto poradí. Chýbajúca odpoveď a chýbajúca trasa vyzerajú v prehliadači rovnako a v logu resolvera úplne inak.

Keď sa resolver zmení, odpoveď sa zmení

Klient VPN často pretlačí vlastný resolver alebo prevezme celú cestu dopytu, a tento resolver nemusí nič syntetizovať. Dopyty na mená s iba IPv4 potom nevracajú záznam AAAA, čo klient s iba IPv6 zažíva ako meno, na ktoré sa nedostane. Deje sa aj opak: resolver, ktorý skutočne syntetizuje, vám môže dať prefix, ktorý vaša tunelová cesta nenesie.

Kešovanie to robí ťažšie viditeľným. Syntetizovaný záznam získaný v kancelárskej sieti môže prežiť kontext, ktorý ho vytvoril, takže klient sa ďalej pripája k adrese, ktorej prekladač už nie je dostupný. Pozerajte sa na resolver, ktorý odpovedá teraz, nie na ten, ktorý odpovedal, keď sa záznam uložil. Vymazanie keše bez zaznamenania starej a novej odpovede zničí dôkaz, ktorý potrebujete.

Testujte dopyt a trasu oddelene

Opýtajte sa na meno priamo predtým, než zapojíte aplikáciu, a poznamenajte si, ktorý server odpovedal. Príkazy nižšie ukazujú záznam AAAA, použitý resolver a to, či existuje trasa k syntetizovanému prefixu. Spustite ich s vypnutým tunelom a potom znova so zapnutým.

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/

Čítajte výsledky ako reťaz. Chýbajúci záznam AAAA znamená, že resolver pred vami nesyntetizuje, takže cesta s iba IPv6 pre to meno fungovať nebude, nech klient robí čokoľvek. Záznam existuje a trasa chýba — prefix nenesie súčasná cesta, a to je rozhodnutie o smerovaní, nie porucha resolvera. Trasa existuje a dopyt napriek tomu zlyháva — to ukazuje na samotný prekladač, a ten patrí inému vlastníkovi.

Zaznamenajte resolver, kontext siete a rodinu adries vedľa každého výsledku. Práve táto poznámka umožní ďalšiemu porovnaniu oddeliť zmenu resolvera od zmeny smerovania.