VPN připojeno, ale jména nefungují: kde se DNS skutečně láme

Tunel běží, ikona je zelená a každá karta prohlížeče hlásí selhání překladu jmen. Tento obraz vytvářejí tři různé mechanismy: resolver může být nedostupný, klient se může ptát resolveru, který jste nečekali, nebo mohou selhávat jen soukromá jména. Oddělte je, než cokoli změníte v protokolu tunelu, protože každý se opravuje na jiném místě. Pořadí níže začíná pozorováními, která ty tři případy oddělují.

Co dotaz skutečně potřebuje

Dotaz potřebuje tři věci: adresu resolveru, trasu k této adrese a odpověď, která odpovídá otázce. Každá může selhat sama o sobě a viditelný příznak je stejná stránka, která se nenačte. Proto vám chybová stránka neřekne téměř nic, dokud nevíte, které ze tří se rozbilo.

Klient zjišťuje svůj resolver z profilu VPN, z DHCP na tunelu nebo z vlastní konfigurace a to, který zdroj vyhraje, závisí na platformě. Ve Windows ipconfig /all vypisuje servery DNS pro každý adaptér, takže vidíte, zda odeslaná hodnota skutečně dorazila. Odeslaná hodnota, která se nikdy nedostala do operačního systému, je tichá a častá porucha. Přečtěte si nakonfigurovanou hodnotu, než se dotknete profilu.

Linux a macOS odpovídají na stejnou otázku jinými příkazy a odpověď si zaslouží stejné čtení: resolvectl status a scutil --dns oba vypisují servery podle rozhraní. Porovnejte tento seznam s adresou, kterou profil tvrdí, že odesílá. Nesoulad zde vysvětluje vše další, proto ho vyřešte, než začnete testovat jména.

Otestujte jedno veřejné a jedno soukromé jméno

Dotážete se na běžné veřejné jméno hostitele a dokumentované soukromé jméno hostitele ze stejného počítače a poznamenejte, který server na každé odpověděl. Pokud selžou obě, je rozbitý resolver nebo jeho trasa. Pokud selže jen soukromé jméno, resolver odpověděl a otázka se mění na zónu nebo směrování. Spusťte oba dotazy do minuty po sobě, aby rozdíl nemohla vysvětlit změna trasy.

Držte interní jména mimo veřejné snímky obrazovky a mimo veřejné resolvery. Časový limit a odpověď o neexistující doméně jsou různá pozorování: první říká, že se nic nevrátilo, druhé, že autorita odpověděla, že jméno neexistuje. Když je berete jako jednu chybu, jdete na špatnou vrstvu, a varování o certifikátu je zase třetí věc, nikoli selhání DNS.

nslookup vypisuje i server, na který se ptal, i přijatou odpověď, a to je přesně dvojice, kterou potřebujete. Spusťte ho dvakrát ve stejném shellu a napište odpovídající adresu vedle každé odpovědi.

nslookup example.com
nslookup host.corp.example 10.20.30.53

Ověřte, že se klient na tento server skutečně dostane

Soukromý resolver odeslaný profilem je užitečný jen tehdy, když na něj klient při běžícím tunelu dosáhne. Adresa, která vypadá správně, ale nemá trasu, vytvoří časový limit, a připojený stav tunelu o této trase nic neříká. Kontrolou je hledání trasy k samotnému resolveru, ne ke koncovému bodu VPN.

Každá platforma na to odpovídá jedním řádkem a rozhraní uvedené ve výstupu je celá odpověď. Pokud ukazuje na fyzický adaptér, zatímco resolver je za tunelem, profil neodesílá prefix, který by ho pokrýval.

ip route get 10.20.30.53                      # Linux
route -n get 10.20.30.53                     # macOS
Find-NetRoute -RemoteIPAddress 10.20.30.53   # Windows PowerShell

U profilu rozděleného tunelu může resolver ležet mimo odeslané trasy, což je problém profilu, ne serveru. Porovnejte adresu resolveru s odeslanými prefixy a potvrďte, že jeden z nich ji pokrývá. Stejný nesoulad vysvětluje, proč DNS funguje v jedné síti a selhává v jiné s identickým profilem.

Pamatujte, že prohlížeče mohou systémový resolver obejít

Prohlížeč se zapnutým zabezpečeným DNS může posílat dotazy přes HTTPS poskytovateli podle vlastního výběru a resolver operačního systému úplně ignorovat. Pak systém vypadá správně, zatímco prohlížeč selhává, nebo naopak. To je otázka zásad pro prohlížeč, ne pro tunel.

Zkontrolujte nastavení zabezpečeného DNS v prohlížeči a všechny spravované zásady, které ho řídí, a potom zkuste druhou aplikaci nebo prohlížeč s nezměněným tunelem. Pokud selhává jen jedna aplikace, oprava patří do této aplikace. Soukromé okno není čisté srovnání, protože v jednom prohlížeči může ve výchozím nastavení vypnout rozšíření a v jiném ne, a nikdy neobchází spravované zásady. Použijte místo toho druhý profil prohlížeče nebo jinou aplikaci.

Vyčistěte mezipaměť a znovu otestujte skutečný úkol

Po opravě nastavení vyčistěte místní mezipaměť resolveru, aby stará odpověď nepřežila opravu. Krátké zotavení následované další poruchou znamená, že příčina stále existuje, ne že čištění selhalo. Vyberte řádek, který odpovídá vašemu počítači, protože tři mezipaměti jsou oddělené.

ipconfig /flushdns                 # Windows
resolvectl flush-caches            # Linux
sudo killall -HUP mDNSResponder    # macOS

Potom zopakujte původní úkol místo syntetického dotazu, protože úkol je to, na čem uživateli záleží. Připojte se také jednou znovu, aby opakovaný test pokryl stav, ve kterém uživatel skutečně bude. Referenční stránka nslookup od Microsoftu je stránka, kterou si nechte pro argumenty dotazu.

Pokud jména selhávají až po odpojení, klient neobnovil předchozí konfiguraci, což je chyba životního cyklu, kterou je třeba nahlásit, a ne server DNS, který je třeba vyměnit. Fungující dotaz také není test úniku, protože země odchodu vám neřekne, který resolver odpověděl.