VPN csatlakoztatva, de a nevek meghiúsulnak: hol törik el valójában a DNS

Az alagút áll, az ikon zöld, és a böngésző minden lapja névfeloldási hibát jelez. Három különböző mechanizmus állítja elő ezt a képet: a feloldó elérhetetlen lehet, a kliens olyan feloldót kérdezhet, amelyre nem számított, vagy csak a privát nevek hiúsulhatnak meg. Válassza szét őket, mielőtt bármit változtat az alagút protokollján, mert mindegyiket más helyen javítják. Az alábbi sorrend azokkal a megfigyelésekkel kezdődik, amelyek szétválasztják a hármat.

Mire van valójában szüksége egy lekérdezésnek

Egy lekérdezésnek három dologra van szüksége: egy feloldócímre, egy útvonalra ehhez a címhez és a kérdéshez illő válaszra. Mindegyik önmagában is meghiúsulhat, és a látható tünet ugyanaz az oldal, amely nem töltődik be. Ezért a hibaoldal szinte semmit sem mond, amíg nem tudja, melyik három hibázott.

A kliens a feloldóját a VPN-profilból, az alagút DHCP-jéből vagy a saját konfigurációjából tanulja, és hogy melyik forrás nyer, a platformtól függ. Windowson a ipconfig /all adapterenként listázza a DNS-kiszolgálókat, így láthatja, megérkezett-e a küldött érték. A soha az operációs rendszerig el nem jutó küldött érték csendes és gyakori hiba. Olvassa el a beállított értéket, mielőtt a profilhoz nyúl.

A Linux és a macOS ugyanerre a kérdésre más parancsokkal válaszol, és a válasz ugyanazt az olvasást érdemli: resolvectl status és a scutil --dns mindkettő interfészenként listázza a kiszolgálókat. Hasonlítsa össze ezt a listát azzal a címmel, amelyet a profil küldeni állít. Az itteni eltérés mindent megmagyaráz lejjebb, ezért rendezze, mielőtt neveket tesztel.

Teszteljen egy nyilvános és egy privát nevet

Kérdezzen meg egy közönséges nyilvános gazdanevet és a dokumentált privát gazdanevet ugyanarról a gépről, és jegyezze fel, melyik kiszolgáló melyikre válaszolt. Ha mindkettő meghiúsul, a feloldó vagy annak útvonala törött. Ha csak a privát név hiúsul meg, a feloldó válaszolt, és a kérdés a zóna vagy az útvonalválasztás lesz. Futtassa a két lekérdezést egy percen belül, hogy egy útvonalváltozás ne magyarázhassa a különbséget.

Tartsa a belső neveket nyilvános képernyőképeken kívül és nyilvános feloldókon kívül. Az időtúllépés és a nem létező tartományra adott válasz különböző megfigyelések: az első azt mondja, hogy semmi sem jött vissza, a második azt, hogy egy hatóság azt válaszolta, a név nem létezik. Ha egyetlen hibaként kezeli őket, rossz rétegre kerül, és a tanúsítványfigyelmeztetés megint harmadik dolog, nem DNS-hiba.

nslookup kiírja azt a kiszolgálót is, amelyet kérdezett, és a kapott választ is, és pontosan ez a pár, amire szüksége van. Futtassa kétszer ugyanabban a héjban, és írja a válaszoló címet minden válasz mellé.

nslookup example.com
nslookup host.corp.example 10.20.30.53

Erősítse meg, hogy a kliens valóban eléri azt a kiszolgálót

A profil által küldött privát feloldó csak akkor hasznos, ha a kliens eléri, miközben az alagút áll. A helyesnek látszó cím útvonal nélkül időtúllépést okoz, és az alagút csatlakoztatott állapota semmit sem mond erről az útvonalról. Az ellenőrzés a feloldóra magára irányuló útvonalkeresés, nem a VPN végpontjára.

Minden platform egy sorban válaszol erre, és a kimenetben megnevezett interfész a teljes válasz. Ha a fizikai adapterre mutat, miközben a feloldó az alagút mögött van, a profil nem küld olyan előtagot, amely lefedi.

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

Osztott alagútú profilban a feloldó a küldött útvonalakon kívül lehet, ami profilprobléma, nem kiszolgálóprobléma. Hasonlítsa össze a feloldó címét a küldött előtagokkal, és erősítse meg, hogy egyikük lefedi. Ugyanez az eltérés magyarázza, miért működik a DNS az egyik hálózaton, és miért hiúsul meg egy másikon azonos profillal.

Ne feledje, hogy a böngészők megkerülhetik a rendszer feloldóját

Egy biztonságos DNS-t használó böngésző HTTPS-en keresztül a saját választott szolgáltatójához küldheti a lekérdezéseket, és teljesen figyelmen kívül hagyhatja az operációs rendszer feloldóját. Ilyenkor a rendszer helyesnek látszik, miközben a böngésző meghiúsul, vagy fordítva. Ez a böngésző, nem az alagút szabályozási kérdése.

Ellenőrizze a böngésző biztonságos DNS-beállítását és minden őt szabályozó kezelt szabályzatot, majd próbáljon ki egy második alkalmazást vagy böngészőt változatlan alagút mellett. Ha csak egy alkalmazás hiúsul meg, a javítás ahhoz az alkalmazáshoz tartozik. A privát ablak nem tiszta összehasonlítás, mert az egyik böngészőben alapértelmezésben letilthatja a bővítményeket, a másikban nem, és soha nem kerüli meg a kezelt szabályzatot. Használjon inkább második böngészőprofilt vagy más alkalmazást.

Ürítse a gyorsítótárat, és tesztelje újra a valódi feladatot

Egy beállítás javítása után ürítse a helyi feloldó gyorsítótárát, hogy egy régi válasz ne élje túl a javítást. Egy rövid helyreállás után újabb hiba azt jelenti, hogy az ok még mindig fennáll, nem azt, hogy az ürítés hiúsult meg. Válassza azt a sort, amelyik a gépéhez illik, mert a három gyorsítótár különálló.

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

Ezután ismételje meg az eredeti feladatot szintetikus lekérdezés helyett, mert a feladat az, ami a felhasználót érdekli. Csatlakozzon újra egyszer, hogy az ismételt teszt lefedje azt az állapotot, amelyben a felhasználó valóban lesz. A Microsoft nslookup-referenciája az az oldal, amelyet érdemes megtartani a lekérdezés argumentumaihoz.

Ha a nevek csak a leválasztás után hiúsulnak meg, a kliens nem állította vissza az előző konfigurációt, ami életciklus-hiba, amelyet jelenteni kell, nem pedig DNS-kiszolgáló, amelyet le kell cserélni. Egy működő lekérdezés sem szivárgásteszt, mert a kilépési ország semmit sem mond arról, melyik feloldó válaszolt.