Megváltoztatta a VPN a DNS-emet? Hasonlítsa össze előtte és utána

Csatlakoztatja az alagutat, megnyit egy privát irányítópultot, és a név egy olyan címre oldódik fel, amelyet még soha nem látott. Vagy az ellenkezője történik: a böngésző tovább működik, miközben egy parancssori eszköz hirtelen semmit nem old fel. Mindkét eredmény ugyanabból a változásból származik, és az emberek általában egyetlen mondattal magyarázzák a VPN-ről, amely „a saját DNS-ét használja”, ami nem elég pontos a hibakereséshez vagy az ellenőrzéshez. Két kérdés rejlik abban a mondatban: mely lekérdezéseket kellene ennek a profilnak átvennie, és a gép valóban elküldte-e azokat a feloldónak, amelyet kapott? Külön tartásuk maga a módszer, mert az őket összekeverő teszt mindkét irányban magabiztos téves választ ad.

Miért ad egyáltalán feloldót egy profil

Egy alagúton belül a túlsó vég mögötti nevek általában olyan címekre oldódnak fel, amelyek csak abban a hálózatban léteznek. Egy privát zónának, mint a corp.internal, nincs nyilvános delegációja, ezért az azt kiszolgáló feloldónak az alagúton belülről elérhetőnek kell lennie. Ugyanez a mechanizmus egy második célt is szolgál: amikor a lekérdezések egyébként a szolgáltatóján keresztül hagynák el a gépet, a túlsó oldali feloldó a titkosított útvonalon belül tartja a lekérdezést. Ezért érkezik a DNS-kiszolgáló címe a kapcsolat szabályának részeként, és nem olyan globális beállításként, amelyet egyszer választott a géphez.

A cím önmagában semmit nem dönt el. Egy feloldó csak akkor tud válaszolni, ha van hozzá útvonal, és a leggyakoribb hiba az a feloldó, amely csak addig érhető el, amíg az alagút áll. Amikor az alagút leesik és a szabály megmarad, a lekérdezések egy útvonal nélküli címre mennek, és a tünet időtúllépés, nem tiszta hiba. Ez a különbség számít a következő teszt eredményének olvasásakor, mert az időtúllépés olyan átviteli beállításokhoz küldi az embereket, amelyek soha nem játszottak szerepet.

A válaszok összehasonlítása előtt hasonlítsa össze a két felépítést

A teljes alagút és a megosztott DNS ellentétes elvárásokat ad, és egyik sem üzemzavar. Teljes alagútnál minden lekérdezés a szolgáltatóhoz vagy a vállalati feloldóhoz kerülhet, ezért a nyilvános nevek eltérő válasza csatlakozás után várható. Megosztott DNS-nél csak a listázott tartományok mennek a privát feloldóhoz, minden más helyben marad; Windowson a tartománylista a Name Resolution Policy Table-ben él, macOS-en a DNS-beállítások illeszkedő tartományaiban, systemd-resolved gazdagépen pedig a kapcsolatonkénti útvonaltartományokban.

Ezt az összehasonlítást kell először elvégezni, mert ez dönti el, mi számít hibának. Megosztott DNS-nél a nyilvános név, amely új feloldótól válaszol, az, amit érdemes vizsgálni, míg a helyesen válaszoló belső név a rendszer, amely végzi a dolgát. Teljes alagútnál az anomália az a nyilvános név, amely még mindig a szolgáltatója feloldójától válaszol. A Microsoft VPN-névfeloldásról szóló dokumentációja leírja e szabályok Windows-sorrendjét, beleértve azt is, hogyan kerül egyező házirend-bejegyzés vizsgálatra az adapter saját kiszolgálói előtt.

Van egy harmadik feloldó is a szobában, amelyet könnyű elfelejteni. A böngésző biztonságos DNS-e maga old fel neveket, és tovább válaszolhat, miután az alagút megváltoztatta az operációs rendszer szabályát, ezért egy betöltődő oldal azt bizonyítja, hogy a böngésző feloldója működött, nem azt, hogy a profilt alkalmazták. Ha csak azt hasonlítja össze, amit a böngésző mutat, az idő felében a rossz réteget teszteli.

Rögzítsen kiindulási állapotot egyetlen változóval

Változtassa meg az alagutat. Ne változtassa meg ugyanabban a lépésben a nevet, az eszközt vagy a keresési utótagot sem. Válasszon egy nevet, amelyről jogosult kérdezni, jegyezze fel, melyik alkalmazást használta, és írja le vagy a visszakapott címet, vagy a pontos hibát. Windowson a Get-DnsClientServerAddress -AddressFamily IPv4 az adapterenkénti kiszolgálókat nyomtatja, a Get-DnsClientNrptPolicy pedig a házirend-bejegyzéseket; systemd-resolveddel Linuxon a resolvectl status a kapcsolatonkénti DNS-kiszolgálókat és útvonaltartományokat mutatja; macOS-en a scutil --dns azt a feloldósorrendet nyomtatja, amelyet a rendszer valóban követni fog.

Ezután csatlakozzon az ügyfél szokásos vezérlőivel, és ismételje meg pontosan ugyanazokat a parancsokat. Őrizze meg az első kimenetet, ne az emlékét, mert az összehasonlítás az egész lényeg, és a gyorsítótár ürítése után vett második leolvasás már más mérés. Ha a kiindulási állapotot a böngészővel előtérben vették fel, és a csatlakozás utáni futás terminálban történik, két feloldót hasonlít össze, nem egy feloldó két állapotát.

A kifejezett lekérdezés és az alkalmazáskeresés különböző tesztek

Egy adott kiszolgálóhoz intézett kérés, a nslookup name 10.20.0.1 vagy a dig @10.20.0.1 name használatával, egyetlen dolgot bizonyít: hogy a megnevezett kiszolgáló válaszol, amikor elérhető. Teljesen megkerüli a kiválasztási logikát, ezért nem tudja megmondani, hogy a rendszer ezt a kiszolgálót választotta volna-e ehhez a névhez. Arra használja, hogy ellenőrizze, elérhető-e a kiosztott feloldó, és ne használja a szabály ellenőrzésére.

A helyi feloldón keresztüli keresés valóban gyakorolja a kiválasztást. A resolvectl query name ugyanazokat az útvonaltartomány-szabályokat járja be, és jelenti, melyik protokoll válaszolt, a Resolve-DnsName Windowson a házirendtáblán és az ügyfél gyorsítótárán halad át, a scutil --dns pedig azt a sorrendet mutatja, amelyet egy keresés követne. Futtassa mindkét fajtát, és tartsa őket jegyzetei külön oszlopaiban. Egy sikeres kifejezett lekérdezés egy sikertelen alkalmazáskeresés mellett útvonal- vagy kiválasztási probléma, nem munka megtagadásáról szóló feloldó.

A gyorsítótár Ön és a válasz között áll. Az operációs rendszer, a helyi stub feloldó, a böngésző és a negatív gyorsítótár mind tárolnak eredményeket, ezért egy keresés sikerülhet anélkül, hogy egyetlen csomag elhagyná a gépet. Rögzítse az eredményt, mielőtt bármit ürítene: ipconfig /flushdns, resolvectl flush-caches vagy sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder macOS-en. Hagyja ki a széles hálózati visszaállítást ebben a szakaszban, mert az megsemmisíti a még gyűjtött bizonyítékokat.

Mit jelent a különbség

Hasonlítsa össze a rögzített két sort, és sorolja be a változást, mielőtt egyetlen beállításhoz hozzányúlna.

Egy sor kiemelést érdemel. Az a név, amely feloldódik, nem működő szolgáltatás, és a DNS sikere csak azt mondja meg, hogy találtak egy címet. Semmit nem mond a továbbításról, a tűzfal szabályairól vagy arról, hogy a fiókja egyáltalán használhatja-e a szolgáltatást, ezért fejezze be a tényleges alkalmazás tesztelésével, ahelyett hogy feltételezné, a hiba magától elvonult.

Állítsa vissza a kiindulási állapotot és ellenőrizze

Az ügyfél saját vezérlőivel bontsa a kapcsolatot, ne a folyamat megölésével, majd olvassa újra ugyanazt a három parancsot. A kapcsolatonkénti kiszolgálóknak, a házirend-bejegyzéseknek és a teszthez használt név válaszának vissza kell térnie a korábban felírt kiindulási állapothoz. Egy tiszta bontás után megmaradó házirend-bejegyzés valódi hiba, amelyet érdemes rögzíteni, és éppen ezért rossz szokás a generált feloldófájl kézi szerkesztése: a fájlt újraírják és a szerkesztés eltűnik, vagy a szerkesztés megmarad és olyan feloldót rögzít, amelynek már nincs útvonala.

Egyszer járja végig ezt a listát, sorrendben. Döntse el, melyik felépítést valósítja meg a profil, mielőtt bármely eredményt megítél. Tartsa rögzítve a nevet, az eszközt és az utótagot mindkét futásban. Válassza külön a kifejezett lekérdezést az alkalmazáskeresésről. Az érvényes szabályt olvassa, ne csak a választ. Utoljára ürítse a gyorsítótárakat, miután az összehasonlítás le van írva. Ellenőrizze a valódi alkalmazással, majd indítsa újra egyszer, és erősítse meg, hogy a bontott állapot továbbra is tiszta.