VPN pripojené, ale mená zlyhávajú: kde sa DNS skutočne láme

Tunel beží, ikona je zelená a každá karta prehliadača hlási zlyhanie prekladu mien. Tento obraz vytvárajú tri rôzne mechanizmy: resolver môže byť nedostupný, klient sa môže pýtať resolver, ktorý ste nečakali, alebo môžu zlyhávať len súkromné mená. Oddeľte ich, skôr než čokoľvek zmeníte v protokole tunela, pretože každý sa opravuje na inom mieste. Poradie nižšie začína pozorovaniami, ktoré tie tri prípady oddeľujú.

Čo dopyt skutočne potrebuje

Dopyt potrebuje tri veci: adresu resolvera, trasu k tejto adrese a odpoveď, ktorá zodpovedá otázke. Každá môže zlyhať sama a viditeľný príznak je tá istá stránka, ktorá sa nenačíta. Preto vám chybová stránka nepovie takmer nič, kým neviete, ktorá z troch sa pokazila.

Klient zisťuje svoj resolver z profilu VPN, z DHCP na tuneli alebo z vlastnej konfigurácie a to, ktorý zdroj vyhrá, závisí od platformy. Vo Windows ipconfig /all vypisuje servery DNS pre každý adaptér, takže vidíte, či odoslaná hodnota skutočne dorazila. Odoslaná hodnota, ktorá sa nikdy nedostala do operačného systému, je tichá a častá porucha. Prečítajte si nakonfigurovanú hodnotu, skôr než sa dotknete profilu.

Linux a macOS odpovedajú na rovnakú otázku inými príkazmi a odpoveď si zaslúži rovnaké čítanie: resolvectl status a scutil --dns oba vypisujú servery podľa rozhrania. Porovnajte tento zoznam s adresou, ktorú profil tvrdí, že odosiela. Nesúlad tu vysvetľuje všetko ďalej, preto ho vyriešte, skôr než začnete testovať mená.

Otestujte jedno verejné a jedno súkromné meno

Opýtajte sa na bežné verejné meno hostiteľa a dokumentované súkromné meno hostiteľa z toho istého počítača a poznamenajte, ktorý server na každé odpovedal. Ak zlyhajú obe, je pokazený resolver alebo jeho trasa. Ak zlyhá len súkromné meno, resolver odpovedal a otázka sa mení na zónu alebo smerovanie. Spustite oba dopyty do minúty po sebe, aby rozdiel nemohla vysvetliť zmena trasy.

Držte interné mená mimo verejných snímok obrazovky a mimo verejných resolverov. Časový limit a odpoveď o neexistujúcej doméne sú rôzne pozorovania: prvé hovorí, že sa nič nevrátilo, druhé, že autorita odpovedala, že meno neexistuje. Ak ich beriete ako jednu chybu, idete na nesprávnu vrstvu, a varovanie o certifikáte je zase tretia vec, nie porucha DNS.

nslookup vypisuje aj server, na ktorý sa pýtal, aj prijatú odpoveď, a to je presne dvojica, ktorú potrebujete. Spustite ho dvakrát v tom istom shelli a napíšte odpovedajúcu adresu vedľa každej odpovede.

nslookup example.com
nslookup host.corp.example 10.20.30.53

Overte, že sa klient na tento server skutočne dostane

Súkromný resolver odoslaný profilom je užitočný len vtedy, keď naň klient pri bežiacom tuneli dosiahne. Adresa, ktorá vyzerá správne, ale nemá trasu, vytvorí časový limit, a pripojený stav tunela o tejto trase nič nehovorí. Kontrolou je hľadanie trasy k samotnému resolveru, nie ku koncovému bodu VPN.

Každá platforma na to odpovedá jedným riadkom a rozhranie uvedené vo výstupe je celá odpoveď. Ak ukazuje na fyzický adaptér, zatiaľ čo resolver je za tunelom, profil neodosiela prefix, ktorý 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

V profile rozdeleného tunela môže resolver ležať mimo odoslaných trás, čo je problém profilu, nie servera. Porovnajte adresu resolvera s odoslanými prefixmi a potvrďte, že jeden z nich ju pokrýva. Rovnaký nesúlad vysvetľuje, prečo DNS funguje v jednej sieti a zlyháva v inej s identickým profilom.

Pamätajte, že prehliadače môžu systémový resolver obísť

Prehliadač so zapnutým zabezpečeným DNS môže posielať dopyty cez HTTPS poskytovateľovi podľa vlastného výberu a resolver operačného systému úplne ignorovať. Systém potom vyzerá správne, zatiaľ čo prehliadač zlyháva, alebo naopak. To je otázka zásad pre prehliadač, nie pre tunel.

Skontrolujte nastavenie zabezpečeného DNS v prehliadači a všetky spravované zásady, ktoré ho riadia, a potom skúste druhú aplikáciu alebo prehliadač s nezmeneným tunelom. Ak zlyháva len jedna aplikácia, oprava patrí do tej aplikácie. Súkromné okno nie je čisté porovnanie, pretože v jednom prehliadači môže predvolene vypnúť rozšírenia a v inom nie, a nikdy neobchádza spravované zásady. Použite namiesto toho druhý profil prehliadača alebo inú aplikáciu.

Vyčistite vyrovnávaciu pamäť a znova otestujte skutočnú úlohu

Po oprave nastavenia vyčistite miestnu vyrovnávaciu pamäť resolvera, aby stará odpoveď neprežila opravu. Krátke zotavenie nasledované ďalšou poruchou znamená, že príčina stále existuje, nie že čistenie zlyhalo. Vyberte riadok, ktorý zodpovedá počítaču, na ktorom ste, pretože tri vyrovnávacie pamäte sú oddelené.

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

Potom zopakujte pôvodnú úlohu namiesto syntetického dopytu, pretože úloha je to, na čom používateľovi záleží. Pripojte sa ešte raz, aby opakovaný test pokryl stav, v ktorom používateľ skutočne bude. Referenčná stránka nslookup od Microsoftu je stránka, ktorú si nechajte pre argumenty dopytu.

Ak mená zlyhávajú až po odpojení, klient neobnovil predchádzajúcu konfiguráciu, čo je chyba životného cyklu na nahlásenie, nie server DNS na výmenu. Fungujúci dopyt tiež nie je test úniku, pretože krajina odchodu vám nepovie, ktorý resolver odpovedal.