Váš VPN tlačí tři DNS servery: který odpovídá?
Další záznamy mohou být zálohou, trasou pro doménu nebo zbytkem fyzického spojení. Přiřaďte každý k rozsahu, než seznam nazvete únikem.
Po připojení otevřete stránku nastavení a uvidíte tři adresy DNS; otázkou auditu je, která z nich obsloužila váš poslední dotaz. Samotný počet nic neřeší, protože zatlačení klientem, fyzické rozhraní a zásada pro doménu píší do stejného zobrazení. Tyto záznamy nesou různé rozsahy a o tom, kdo odpovídá, rozhoduje rozsah, nikoli pozice. Začněte oddělením zdrojů a potom otestujte ten, který vlastní název, na kterém vám záleží.
Proč je seznam delší než váš profil
Klient VPN tlačí adresy resolveru pro spojení tunelu a operační systém je drží vedle toho, co fyzické rozhraní už mělo. Router, firemní leasing DHCP, druhý VPN a zásada pro doménu přidávají každý svůj záznam. Proto tři adresy na stránce mohou znamenat tři rozsahy, a ne tři kandidáty na jeden úkol. Číst počet jako důkaz úniku je první chyba tohoto auditu.
V rámci jednoho rozhraní klient skutečně zkouší své servery v pořadí, takže seřazený seznam není nesmyslný. Frontou není sloučené zobrazení, kde záznamy z profilu, z fyzického spojení a z pravidel pro doménu stojí vedle sebe bez jediného žebříčku. Tento rozdíl určuje, co testujete: pořadí vysvětluje chování v jednom rozsahu a rozsah vysvětluje všechno ostatní.
Šifrované DNS rozbíjí obraz zevnitř aplikace. Prohlížeč nebo chatovací klient s vlastním resolverem DNS-over-HTTPS posílá dotazy zcela mimo seznam operačního systému, takže adresy na stránce nastavení popisují provoz, který aplikace nikdy nevytvořila. Zkontrolujte vlastní nastavení resolveru aplikace, než obviníte profil ze špatně vráceného názvu.
Co říká každá ze tří kontrol
Každý zdroj zanechává stopu na jiném místě a žádný jediný příkaz neukáže všechny. Toto je mapování, které stojí za to mít vedle stránky nastavení:
| Entry source | Where it is visible | What it proves |
|---|---|---|
| Tunnel profile | Link-scoped DNS on the tunnel device | Which servers the VPN asked you to use, not which one answered |
| Per-domain policy | Suffix list or routing domains | Which names are steered to a particular resolver |
| Physical link | DNS on the LAN interface | Whether a second scope still exists outside the tunnel |
| Application resolver | App settings, absent from the OS list | Whether the system list was consulted at all |
V systému s systemd-resolved je směrodatná resolvectl status, protože hlásí DNS pro každé spojení spolu s doménami směrování. macOS odpovídá přes scutil --dns, které vypisuje resolvery s rozsahem v pořadí zkoušení. Windows dělí na dvě poloviny: Get-DnsClientServerAddress pro servery podle rozhraní a Get-DnsClientNrptPolicy pro pravidla přípon. Spusťte příkaz, který patří skutečně používanému resolveru, protože stroj s běhovým prostředím kontejnerů a desktopovým resolverem může mít nainstalovaný více než jeden.
Záložní resolver, který nedokáže odpovědět za vaši zónu
Druhý záznam obvykle existuje kvůli dostupnosti a dostupnost funguje jen tehdy, když záloha zná názvy. Zeptejte se veřejného resolveru na interní název hostitele a vrátí NXDOMAIN, nebo zástupnou odpověď z vyhledávací domény, která s vámi nemá nic společného. Neotestovaný převzetí pak způsobí výpadek přesně v okamžiku, kdy je potřeba.
Split DNS existuje, aby tomu zabránil: firemní přípony jdou k resolveru, který drží zónu, a veřejné názvy zůstávají na výchozí cestě. Návrh je pevný a závisí na tom, zda je seznam přípon úplný. Microsoft dokumentuje zásadu resolveru pro každou příponu, která to řídí ve Windows, a stejný nápad se objevuje jako domény směrování v systemd-resolved a jako resolvery s rozsahem v macOS.
Porovnejte zóny, za které záloha smí odpovídat, s příponami v zásadě. Toto porovnání najde mezeru dřív, než uživatel nahlásí, že jedna interní stránka přestala po změně tunelu fungovat.
Ptejte se přes zásadu, ne okolo ní
Ptejte se přes resolver operačního systému, protože přímý dotaz na server obchází zásadu a hlásí jen to, co by daný server řekl. Rozdíl mezi oběma odpověďmi je celý smysl:
resolvectl query intranet.example.com
dig +short intranet.example.com @198.51.100.53Pokud systémový dotaz vrací soukromou adresu a přímý dotaz vrací NXDOMAIN, zásada funguje a slabým místem je záloha. Pokud oba vracejí stejnou veřejnou odpověď, název se překládá mimo zamýšlený rozsah a seznam přípon je místo, kam se dívat. Uchovejte oba výstupy, protože spor o resolver se vyřeší rychleji dvěma řádky než snímkem obrazovky stránky nastavení.
Potom procvičte cestu selhání, protože záloha, kterou nikdo neotestoval, je pouhý předpoklad. Udělejte z preferovaného resolveru černou díru pro jeden dotaz a sledujte, která adresa se vrátí:
ip route add blackhole 198.51.100.53/32
resolvectl query intranet.example.com
ip route del blackhole 198.51.100.53/32Smažte tu trasu hned po skončení dotazu, jinak další člověk zdědí záhadu. Pokud se interní názvy v tom okně stále překládají, odpovědělo na ně něco mimo zamýšlený rozsah. Pokud místo toho vyprší, záloha chybí nebo je správně omezená, a vlastní log resolveru vám řekne, které z toho dvou to bylo.
Rozhodněte: ponechat, omezit nebo odstranit
Ponechte druhý resolver, když odpovídá na potřebný jmenný prostor a zůstává dostupný pod profilem. Omezte ho, když má vidět jednu příponu a nic jiného, a odstraňte ho, když nemá ani rozsah, ani zdokumentovaný účel. Záznam bez práce je budoucí únik bez užitku a výchozí hodnota dodavatele není účel.
Zaznamenejte výsledek do čtyř sloupců: přípona, resolver, rozhraní a vlastník. Ten řádek odpovídá na další otázku auditu rychleji než jakýkoli snímek obrazovky a přežije aktualizaci klienta, která seznam tiše přeskupí.