Az irodai feloldóra küldött ping az "OpenVPN" csatlakozása után is választ kap, mégis minden névkeresés meghiúsul. A cím elérhető, a port nem, ez a kombináció akkor válik érthetővé, ha tudja, hogy a Windows adapterenként szűrheti a DNS-t. Ha a profilban block-outside-dns van, az a szűrő az első gyanúsított, és az útvonaltábla a rossz hely, ahol keresni kell. Az alábbi két teszt másodpercek alatt szétválasztja a rétegeket.

Elérhető cím, halott port

A sikeres ping bizonyítja, hogy a gazdagép fut, és létezik útvonal. Semmit nem mond az 53-as port elérésének engedélyéről, mert a szóban forgó szűrő másik rétegen dolgozik, és az adapterhez kötődik. Ezért ugyanaz a gép válaszolhat ICMP-re, és utasíthatja el az ugyanarra a címre küldött minden lekérdezést. Futtassa mindkét tesztet ugyanabban a munkamenetben, mielőtt bármilyen beállítást módosít.

ping <resolver-ip>
nslookup <name> <resolver-ip>

Ez a pár a diagnózis. Az alhálózat felé menő szokásos forgalom tovább működik, miközben a névfeloldás meghal, és az emberek arra jutnak, hogy a kiszolgáló elromlott, vagy hogy a DNS-t soha nem küldték le. Mindkét magyarázat drága utánajárni, és a bizonyítékok szűkebb helyre mutatnak. Erősítse meg a párt, mielőtt bármilyen beállításhoz nyúl.

Az opció a szűrőplatform szabálya

Az OpenVPN referenciája a block-outside-dns-t a Windows Filtering Platform olyan korlátozásaként írja le, amely megakadályozza, hogy az alkalmazások elérjék a DNS-t az alagúton kívüli adaptereken. Lefedi a TCP és UDP 53-as portját. Mivel a szűrő a WFP-ben él, nem pedig a szokásos tűzfal-szabálylistában, egy máshol felvett engedélyező szabály nem feltétlenül változtat az eredményen. Ezért bukik meg továbbra is a DNS engedélyezésére vonatkozó szokásos tanács.

A beállítás az importált profilból vagy a kiszolgálóról érkezhet, és az a fájl, amelyet utoljára szerkesztett, "nem bizonyítja, mit töltött be a kliens". Olvassa együtt a tényleges konfigurációt és a kapcsolati naplót. Az opció Windows-specifikus is, és hordozhatónak tekintve olyan tanácsokat ad, amelyek nem érvényesek.

Keresse azt a klienskomponenst, amely a korlátozást birtokolja, ahelyett hogy további szabályokat adna hozzá. A tulajdonos az, ami valóban el tudja távolítani.

A szűrő nem feloldó

Az alagúton kívüli forgalom blokkolása nem telepít működő feloldót azon belül. Az opció eltávolít egy útvonalat, és az alagút DNS-konfigurációját arra hagyja, aki a profilt beállította. Egy profil, amely soha nem küldött feloldót, most egyáltalán nem rendelkezik vele.

Három ellenőrzést végezzen el sorrendben. Először, melyik feloldót használja valójában a meghiúsuló alkalmazás. Másodszor, alkalmazta-e a kliens a VPN DNS-beállításait. Harmadszor, melyik interfész viszi a forgalmat ahhoz a feloldóhoz.

  1. Használt feloldó: hasonlítsa össze Resolve-DnsName -Server <resolver-ip> <name> a ipconfig /all által felsorolt DNS-kiszolgálókkal.
  2. VPN DNS alkalmazva: vizsgálja meg az alagútadapter DNS-bejegyzéseit ugyanabban a ipconfig /all kimenetben.
  3. Használt interfész: Find-NetRoute -RemoteIPAddress <resolver-ip> megnevezi az adott cél kimenő interfészét.

A LAN-feloldó e szabályzat alatt terv szerint elérhetetlenné válik, még akkor is, ha más LAN-forgalom működik. Ez az opció végzi a dolgát. Ha a terv VPN DNS-t igényel, javítsa a feloldó regisztrációját és az alagút útvonalát; ha helyi kivételekkel működő split DNS kell, a konfiguráció tulajdonosának ezeket a kivételeket támogatott módon ki kell fejeznie.

Amit az opció nem fed le

Az 53-as port nem a teljes névfeloldás. A DNS over HTTPS és a DNS over TLS más szállítást használ, és egyes alkalmazások saját feloldói logikát futtatnak a rendszerbeállításoktól függetlenül. A böngésző ezért fel tudja oldani a neveket, míg a parancssor nem.

Ezt a különbséget diagnózisként kezelje, ne ellentmondásként. Hasonlítsa össze a kettőt, mielőtt eldönti, hogy a rendszer feloldója elromlott.

Írás közben tartsa szűken a következtetést. Ez az opció egy szállítást korlátoz egy platformon, a feloldási útvonal többi része pedig külön tervezési kérdés, saját tulajdonossal.

Ellenőrizze az állapotot leválasztás előtt és után

Futtassa ugyanazt a keresést a kapcsolat alatt, majd újra, miután a birtokló kliens lecsatlakozik. Az elsőnek külső feloldó esetén meg kell hiúsulnia, amíg az alagút áll, a másodiknak pedig sikerülnie kell, amint a szűrő eltűnik. Ha leválasztás után is meghiúsul, a szűrő nem lett kitakarítva.

ipconfig /displaydns
nslookup <name> <resolver-ip>

A kliensszolgáltatás vagy a gép újraindítása általában kitakarítja az elavult szűrőt. Ez megerősíti a diagnózist anélkül, hogy tartós javítást bizonyítana. Jegyezze fel, mit látott, mert a leválasztást túlélő szűrő újra megteszi, és a feljegyzés az, ami igazol egy hibajelentést.

Csak ezek után az ellenőrzések után van értelme lecserélni a feloldót vagy újjáépíteni a tűzfal-szabályzatot. Mindkettő nagyobb változás, mint amit a bizonyítékok alátámasztanak.

Kapcsolódó cikkek