Proč se odpovědi DNS64 mění, jakmile se připojí VPN?

Odpověď DNS64 kóduje předpoklad o překladu. Zkontrolujte, který resolver odpověděl, zda je prefix směrován a zda na vaší cestě stojí překladač.

Odpovědi DNS64 popisují uspořádání sítě, nikoli vlastnost serveru. Resolver syntetizuje adresu IPv6 z adresy IPv4 a výsledek funguje jen tam, kde na konci tohoto prefixu stojí překladač. Zapojte do cesty VPN a toto uspořádání může vydržet, změnit se nebo přestat platit podle tří podmínek.

Těmi podmínkami jsou resolver, který odpověděl, trasa, kterou vaše zařízení má k syntetizovanému prefixu, a to, zda na této trase něco provádí překlad. Každou lze pozorovat, a právě proto je porucha diagnostikovatelná.

Na co syntetizovaný záznam AAAA skutečně ukazuje

Resolver DNS64 odpovídá na dotaz AAAA pro jméno pouze s IPv4 tím, že adresu IPv4 vloží do prefixu, který má nakonfigurováno používat, a známý prefix pro tento úkol je 64:ff9b::/96, jak popisuje RFC 6147. Aplikace vidí záznam jako každý jiný záznam AAAA, a o to jde: klient pouze s IPv6 může zkusit spojení, aniž by věděl, že cíl nikdy IPv6 neměl. Takové spojení pak závisí na funkci NAT64, která někde na cestě překládá mezi oběma rodinami. Bez tohoto překladače je syntetizovaná adresa věrohodně vypadající cíl, který nikam nevede.

Záznam tedy kóduje dvě věci najednou: původní adresu IPv4 a předpoklad, že překladač je dosažitelný. V samotné odpovědi je vidět jen první z nich.

Tři podmínky rozhodují, zda to ještě funguje

První podmínkou je, který resolver záznam vytvořil, protože ten bez nakonfigurovaného DNS64 nic pro to jméno nevrací a aplikace selže jiným způsobem. Druhou je, zda vaše zařízení má trasu k syntetizovanému prefixu, protože odpověď může být platná, zatímco cesta k ní chybí. Třetí je, zda překladač, který tento prefix vlastní, je na cestě, kterou byste použili, protože tunel odnášející 64:ff9b::/96 jinam dosáhne jiné funkce nebo ničeho. Všechny tři mohou před tunelem platit a po něm selhat, a proto symptom vypadá jako náhlá regrese.

Prověřujte je v tomto pořadí. Chybějící odpověď a chybějící trasa vypadají v prohlížeči stejně a v logu resolveru úplně jinak.

Když se resolver změní, odpověď se změní

Klient VPN často protlačí vlastní resolver nebo zcela převezme cestu dotazu a tento resolver nemusí nic syntetizovat. Dotazy na jména pouze s IPv4 pak nevracejí záznam AAAA, což klient pouze s IPv6 zažívá jako jméno, na které se nedostane. Děje se i opak: resolver, který skutečně syntetizuje, vám může dát prefix, který vaše tunelová cesta nenese.

Kešování to činí hůře viditelným. Syntetizovaný záznam získaný v kancelářské síti může přežít kontext, který jej vytvořil, takže klient se dál připojuje k adrese, jejíž překladač už není dosažitelný. Dívejte se na resolver, který odpovídá nyní, ne na ten, který odpověděl, když byl záznam uložen. Vymazání keše bez zaznamenání staré a nové odpovědi zničí důkaz, který potřebujete.

Testujte dotaz a cestu odděleně

Dotážete se na jméno přímo, než zapojíte aplikaci, a poznamenejte si, který server odpověděl. Příkazy níže ukazují záznam AAAA, použitý resolver a to, zda existuje trasa k syntetizovanému prefixu. Spusťte je s vypnutým tunelem a potom znovu se 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/

Čtěte výsledky jako řetěz. Chybějící záznam AAAA znamená, že resolver před vámi nesyntetizuje, takže cesta pouze s IPv6 pro to jméno fungovat nebude, ať klient dělá cokoli. Záznam existuje a trasa chybí — prefix nenese současná cesta, a to je rozhodnutí o směrování, nikoli porucha resolveru. Trasa existuje a požadavek přesto selhává — to ukazuje na samotný překladač a ten patří jinému vlastníkovi.

Zaznamenejte resolver, kontext sítě a rodinu adres vedle každého výsledku. Právě tato poznámka umožní dalšímu srovnání oddělit změnu resolveru od změny směrování.

Související články