Váš VPN tlačí tri DNS servery: ktorý odpovedá?
Ďalšie záznamy môžu byť zálohou, trasou pre doménu alebo zvyškom fyzického spojenia. Priraďte každý k rozsahu, skôr než zoznam nazvete únikom.
Po pripojení otvorte stránku nastavení a uvidíte tri adresy DNS; otázkou auditu je, ktorá z nich obslúžila vašu poslednú požiadavku. Samotný počet nič nerieši, pretože zatlačenie klientom, fyzické rozhranie a pravidlo pre doménu píšu do rovnakého zobrazenia. Tieto záznamy nesú rôzne rozsahy a o tom, kto odpovedá, rozhoduje rozsah, nie pozícia. Začnite oddelením zdrojov a potom otestujte ten, ktorý vlastní názov, na ktorom vám záleží.
Prečo je zoznam dlhší ako váš profil
Klient VPN tlačí adresy resolvera pre spojenie tunela a operačný systém ich drží vedľa toho, čo fyzické rozhranie už malo. Smerovač, firemný leasing DHCP, druhý VPN a pravidlo pre doménu pridávajú každý svoj záznam. Preto tri adresy na stránke môžu znamenať tri rozsahy, a nie troch kandidátov na jednu úlohu. Čítať počet ako dôkaz úniku je prvá chyba tohto auditu.
V rámci jedného rozhrania klient skutočne skúša svoje servery v poradí, takže zoradený zoznam nie je nezmyselný. Frontom nie je zlúčené zobrazenie, kde záznamy z profilu, z fyzického spojenia a z pravidiel pre doménu stoja vedľa seba bez jediného rebríčka. Tento rozdiel určuje, čo testujete: poradie vysvetľuje správanie v jednom rozsahu a rozsah vysvetľuje všetko ostatné.
Šifrované DNS rozbíja obraz zvnútra aplikácie. Prehliadač alebo chatovací klient s vlastným resolverom DNS-over-HTTPS posiela požiadavky úplne mimo zoznamu operačného systému, takže adresy na stránke nastavení opisujú prevádzku, ktorú aplikácia nikdy nevytvorila. Skontrolujte vlastné nastavenie resolvera aplikácie, skôr než obviníte profil zo zle vráteného názvu.
Čo hovorí každá z troch kontrol
Každý zdroj zanecháva stopu na inom mieste a žiadny jediný príkaz neukáže všetky. Toto je mapovanie, ktoré sa oplatí mať vedľa 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éme s systemd-resolved je smerodajná resolvectl status, pretože hlási DNS pre každé spojenie spolu s doménami smerovania. macOS odpovedá cez scutil --dns, ktoré vypisuje resolvery s rozsahom v poradí skúšania. Windows delí na dve polovice: Get-DnsClientServerAddress pre servery podľa rozhrania a Get-DnsClientNrptPolicy pre pravidlá prípon. Spustite príkaz, ktorý patrí skutočne používanému resolveru, pretože stroj s behovým prostredím kontajnerov a desktopovým resolverom môže mať nainštalovaný viac ako jeden.
Záložný resolver, ktorý nedokáže odpovedať za vašu zónu
Druhý záznam zvyčajne existuje kvôli dostupnosti a dostupnosť funguje len vtedy, keď záloha pozná názvy. Spýtajte sa verejného resolvera na interný názov hostiteľa a vráti NXDOMAIN, alebo zástupnú odpoveď z vyhľadávacej domény, ktorá s vami nemá nič spoločné. Neotestovaný prevratný prechod potom spôsobí výpadok presne v okamihu, keď je potrebný.
Split DNS existuje, aby tomu zabránil: firemné prípony idú k resolveru, ktorý drží zónu, a verejné názvy zostávajú na predvolenej ceste. Návrh je pevný a závisí od toho, či je zoznam prípon úplný. Microsoft dokumentuje zásadu resolvera pre každú príponu, ktorá to riadi vo Windows, a rovnaký nápad sa objavuje ako domény smerovania v systemd-resolved a ako resolvery s rozsahom v macOS.
Porovnajte zóny, za ktoré záloha smie odpovedať, s príponami v zásade. Toto porovnanie nájde medzeru skôr, než používateľ nahlási, že jedna interná stránka prestala po zmene tunela fungovať.
Pýtajte sa cez zásadu, nie okolo nej
Pýtajte sa cez resolver operačného systému, pretože priamy dotaz na server obchádza zásadu a hlási len to, čo by daný server povedal. Rozdiel medzi oboma odpoveďami je celý zmysel:
resolvectl query intranet.example.com
dig +short intranet.example.com @198.51.100.53Ak systémový dotaz vracia súkromnú adresu a priamy dotaz vracia NXDOMAIN, zásada funguje a slabým miestom je záloha. Ak oba vracajú rovnakú verejnú odpoveď, názov sa prekladá mimo zamýšľaného rozsahu a zoznam prípon je miesto, kam sa treba pozrieť. Uchovajte oba výstupy, pretože spor o resolver sa vyrieši rýchlejšie dvoma riadkami než snímkou obrazovky stránky nastavení.
Potom precvičte cestu zlyhania, pretože záloha, ktorú nikto neotestoval, je len predpoklad. Urobte z preferovaného resolvera čiernu dieru pre jeden dotaz a sledujte, ktorá adresa sa vráti:
ip route add blackhole 198.51.100.53/32
resolvectl query intranet.example.com
ip route del blackhole 198.51.100.53/32Zmažte tú trasu hneď po skončení dotazu, inak ďalší človek zdedí záhadu. Ak sa interné názvy v tom okne stále prekladajú, odpovedalo na ne niečo mimo zamýšľaného rozsahu. Ak namiesto toho vypršia, záloha chýba alebo je správne obmedzená, a vlastný log resolvera vám povie, ktoré z toho dvoch to bolo.
Rozhodnite: ponechať, obmedziť alebo odstrániť
Ponechajte druhý resolver, keď odpovedá na potrebný menný priestor a zostáva dostupný pod profilom. Obmedzte ho, keď má vidieť jednu príponu a nič iné, a odstráňte ho, keď nemá ani rozsah, ani zdokumentovaný účel. Záznam bez práce je budúci únik bez úžitku a predvolená hodnota dodávateľa nie je účel.
Zaznamenajte výsledok do štyroch stĺpcov: prípona, resolver, rozhranie a vlastník. Ten riadok odpovedá na ďalšiu otázku auditu rýchlejšie než akákoľvek snímka obrazovky a prežije aktualizáciu klienta, ktorá zoznam ticho preusporiada.