Změnil mi VPN DNS? Porovnejte stav před a po
Profil může vaše dotazy záměrně přesunout. Porovnejte politiku překladače a skutečnou odpověď před připojením VPN a po něm a udržte jednu proměnnou.
Připojíte tunel, otevřete soukromý panel a jméno se přeloží na adresu, kterou jste nikdy neviděli. Nebo se stane opak: prohlížeč dál funguje, zatímco nástroj příkazové řádky najednou nic nepřeloží. Oba výsledky pocházejí ze stejné změny a lidé to obvykle vysvětlují jednou větou o VPN, která „používá vlastní DNS“, což není dost přesné k ladění ani k ověření. V té větě jsou skryté dvě otázky: které dotazy má tento profil převzít a poslal váš stroj ty dotazy skutečně překladači, který mu byl přidělen? Držet je oddělené je celá metoda, protože test, který je míchá, dává v obou směrech sebevědomou špatnou odpověď.
Proč profil vůbec poskytuje překladač
Uvnitř tunelu se jména za vzdáleným koncem obvykle překládají na adresy, které existují jen v této síti. Soukromá zóna jako corp.internal nemá veřejnou delegaci, takže překladač, který ji obsluhuje, musí být dostupný zevnitř tunelu. Stejný mechanismus slouží druhému účelu: když by dotazy jinak vyšly přes vašeho poskytovatele, překladač na vzdálené straně udrží dotaz uvnitř šifrované cesty. Proto adresa DNS serveru přichází jako součást politiky připojení, a ne jako globální nastavení, které jste jednou zvolili pro stroj.
Adresa sama o sobě nic nevyřeší. Překladač může odpovědět jen tehdy, když k němu vede trasa, a nejčastější závada je překladač dostupný jen po dobu, kdy je tunel nahoře. Když tunel spadne a politika zůstane, dotazy jdou na adresu bez cesty a příznakem je vypršení časového limitu, ne čistá chyba. Ten rozdíl je důležitý, když čtete další výsledek testu, protože vypršení limitu posílá lidi do nastavení přenosu, která s tím nikdy nesouvisela.
Porovnejte oba návrhy dřív než odpovědi
Plný tunel a rozdělený DNS dávají opačná očekávání a ani jedno není porucha. Pod plným tunelem se každý dotaz může přesunout k poskytovateli nebo ke korporátnímu překladači, takže jiná odpověď veřejných jmen po připojení je očekávaná. Pod rozděleným DNS jdou k soukromému překladači jen uvedené domény, zatímco vše ostatní zůstává lokálně; ve Windows žije seznam domén v Name Resolution Policy Table, v macOS v odpovídajících doménách nastavení DNS a na hostiteli se systemd-resolved v doménách směrování pro jednotlivá spojení.
Toto porovnání je třeba udělat nejdřív, protože rozhoduje o tom, co se počítá jako závada. U rozděleného DNS je veřejné jméno odpovídající z nového překladače to, co stojí za vyšetření, kdežto interní jméno odpovídající správně je systém, který dělá svou práci. U plného tunelu je anomálií veřejné jméno, které stále odpovídá z překladače vašeho poskytovatele. Dokumentace Microsoftu k překladu jmen ve VPN popisuje pořadí těchto pravidel ve Windows, včetně toho, jak se odpovídající položka politiky konzultuje před vlastními servery adaptéru.
V místnosti je třetí překladač, na který se snadno zapomíná. Zabezpečené DNS prohlížeče překládá jména samo a může odpovídat dál poté, co tunel změnil politiku operačního systému, takže načtená stránka dokazuje, že překladač prohlížeče fungoval, ne že byl profil aplikován. Pokud porovnáváte jen to, co ukazuje prohlížeč, testujete polovinu času špatnou vrstvu.
Zaznamenejte výchozí stav s jedinou proměnnou
Změňte tunel. Neměňte zároveň jméno, nástroj ani příponu hledání ve stejném kroku. Vyberte jméno, na které smíte dotazovat, poznamenejte, kterou aplikaci jste použili, a zapište buď vrácenou adresu, nebo přesnou chybu. Ve Windows Get-DnsClientServerAddress -AddressFamily IPv4 vypisuje servery pro jednotlivé adaptéry a Get-DnsClientNrptPolicy vypisuje položky politiky; v Linuxu se systemd-resolved resolvectl status ukazuje DNS servery a domény směrování pro jednotlivá spojení; v macOS scutil --dns vypisuje pořadí překladačů, které systém skutečně dodrží.
Pak se připojte běžnými ovládacími prvky klienta a zopakujte přesně tytéž příkazy. Uchovejte první výstup, ne vzpomínku na něj, protože celý smysl je v porovnání a druhé čtení po vyčištění mezipaměti je už jiné měření. Pokud byl výchozí stav pořízen s prohlížečem vpředu a běh po připojení probíhá v terminálu, porovnáváte dva překladače, ne dva stavy jednoho překladače.
Explicitní dotaz a vyhledání aplikací jsou různé testy
Zeptat se jednoho konkrétního serveru pomocí nslookup name 10.20.0.1 nebo dig @10.20.0.1 name dokazuje jedinou věc: že server, který jste uvedli, odpovídá, když se k němu dostanete. Úplně obchází logiku výběru, takže vám nemůže říct, zda by systém tento server pro toto jméno vybral. Použijte ho k ověření, zda je přidělený překladač dostupný, a nepoužívejte ho k ověřování politiky.
Vyhledání přes místní překladač výběr skutečně procvičuje. resolvectl query name prochází stejná pravidla domén směrování a hlásí, který protokol odpověděl, Resolve-DnsName ve Windows prochází tabulkou politiky a klientskou mezipamětí a scutil --dns ukazuje pořadí, které by vyhledání následovalo. Spusťte oba druhy a držte je v oddělených sloupcích svých poznámek. Úspěšný explicitní dotaz vedle neúspěšného vyhledání aplikací je problém směrování nebo výběru, ne překladač, který odmítá pracovat.
Mezipaměť stojí mezi vámi a odpovědí. Operační systém, místní stub překladač, prohlížeč i negativní mezipaměť drží výsledky, takže vyhledání může uspět, aniž by jediný paket opustil stroj. Zaznamenejte výsledek, než cokoli vyčistíte: ipconfig /flushdns, resolvectl flush-caches nebo sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder v macOS. Široký reset sítě v této fázi vynechte, protože ničí důkazy, které ještě sbíráte.
Co rozdíl znamená
Porovnejte dva řádky, které jste zaznamenali, a klasifikujte změnu dřív, než se dotknete jediného nastavení.
| Observation after connect | Most likely cause | Next step |
|---|---|---|
| Answer moves to a private address range | Expected under split DNS or a private zone | Confirm the suffix is in the effective policy, then test the service |
| Lookup times out while connected, works after disconnect | The assigned resolver has no route from this machine | Probe it with an explicit query, then re-read the policy |
| Internal name fails, public names work | Wrong namespace or a suffix missing from the policy | Query the fully qualified name and check the domain list per platform |
| Internal name returns a public address | Split DNS not applied; a public resolver answered | Check browser secure DNS first, then the per-link domain list |
Jeden řádek si zaslouží zdůraznění. Jméno, které se přeloží, není služba, která funguje, a úspěch DNS říká jen to, že byla nalezena adresa. Neříká nic o přesměrování, pravidlech firewallu ani o tom, zda váš účet smí službu vůbec používat, takže skončete testem skutečné aplikace místo předpokladu, že závada sama odešla.
Obnovte výchozí stav a ověřte ho
Odpojte se vlastními ovládacími prvky klienta místo zabití procesu a pak znovu přečtěte stejné tři příkazy. Servery pro jednotlivá spojení, položky politiky a odpověď pro vaše testovací jméno by se měly vrátit k výchozímu stavu, který jste si dřív zapsali. Zbytková položka politiky po čistém odpojení je skutečná závada, kterou stojí za to zaznamenat, a právě proto jsou ruční úpravy generovaného souboru překladače špatný zvyk: soubor se přepíše a úprava zmizí, nebo úprava přežije a připíchne překladač, který už nemá trasu.
Projděte tento seznam jednou, popořadě. Rozhodněte, který návrh profil uplatňuje, než posoudíte jakýkoli výsledek. Držte jméno, nástroj a příponu pevně v obou bězích. Oddělte explicitní dotaz od vyhledání aplikací. Čtěte efektivní politiku, ne jen odpověď. Mezipaměti čistěte nakonec, až po zapsání porovnání. Ověřte skutečnou aplikací, pak jednou restartujte a potvrďte, že stav po odpojení je stále čistý.