Az OpenVPN küldi a DNS-t, de a feloldód lehet, hogy soha nem látja

A kliensnapló mutatja a küldött DNS-kiszolgálót, az alagút csatlakoztatva van, és egy belső név mégsem oldódik fel. Magában a küldésben nincs semmi elromolva. A beállítás megérkezett, és az operációs rendszer feloldója soha nem használta, mert a legtöbb Unix-ügyfélen az OpenVPN átadja az értéket, és az alkalmazást a platformra hagyja.

A tünet: a napló DNS-t mutat, a nevek mégis meghiúsulnak

OpenVPN dhcp-option DNS- és tartományadatokat hordoz, és az ügyfél rögzíti, mit kapott. Egyes megvalósításokban az ügyfél belsőleg alkalmazza ezeket a beállításokat; másokban integrációs szkriptnek vagy hálózati szolgáltatásnak exportálja őket. A naplósor csak a történet első felét írja le. A második fél ott történik, amit az ügyfél nem irányít. A hiba általában ott lakik.

Ezért jár olyan gyakran együtt a csatlakoztatott alagút és a meghiúsuló belső név. Az érték jelen van, a fogyasztó hiányzik vagy rosszul van konfigurálva, a feloldó pedig csendben tovább használja azt a nyilvános kiszolgálót, amelyet a kapcsolat előtt használt.

A megérkezés nem alkalmazás

Az ügyfél naplózhatja a küldött DNS-értéket, miközben a rendszer feloldója továbbra is egy másik szolgáltatás tulajdonában van. A böngészőnek lehet saját titkosított DNS-szabályzata, amely teljesen megkerüli a rendszer feloldóját, és ez azt az emlékezetes helyzetet szüli, amikor az egyik alkalmazás feloldja a belső neveket, a másik pedig nem.

Ellenőrizze a megvalósítás támogatott integrációját, ahelyett hogy feltételezné, minden Unix-ügyfél ugyanazt a fájlt írja át. Ez a feltevés az oka annak, hogy az emberek olyan feloldókonfigurációt szerkesztenek, amelyet semmi sem olvas.

Keresse meg a feloldó tulajdonosát platformonként

Windowson a névfeloldási szabályzattábla bizonyos utótagokat bizonyos kiszolgálókhoz irányíthat, és a VPN-ügyfél szabályokat telepíthet oda. A szabályzatot ellenőrizze, ne csak az adapter DNS-listáját. Linuxon a konfiguráció a NetworkManager vagy a systemd-resolved tulajdonában lehet, és hogy melyiké, az dönti el, mit őriz meg az újracsatlakozás.

Olvassa ki a tényleges állapotot azzal az eszközzel, amely valóban válaszol a lekérdezésekre: resolvectl query internal.example.net egy systemd-resolved gazdagépen, vagy a platform megfelelőjével. Ezután hasonlítsa össze a választ azzal a DNS-kiszolgálóval, amelyet a kliensnapló küldöttnek állít.

Kerülje több olyan szolgáltatás futtatását, amely koordináció nélkül írja felül a feloldó beállításait. Két tulajdonos időszakosnak látszó eredményt ad, és minden újracsatlakozás mintha véletlenszerűen javítaná vagy rontaná el.

Szkriptek és foreign_option

Az OpenVPN a küldött beállításokat foreign_option_N nevű változókon keresztül exportálja szkripteknek, és egy szkript lefordíthatja őket feloldóparancsokká. Ez az elrendezés támogatott integráció, nem automatikus viselkedés, és telepíteni kell, valamint meg kell hívni az ügyfélen.

Ha szkriptre támaszkodik, naplózza annak futását és kilépési állapotát. Egy futó, de csendben meghiúsuló szkript ugyanazt a tünetet hagyja, mint a szkript hiánya, és nehezebb észrevenni, mert a konfiguráció teljesnek tűnik. A szkript kimenetét ellenőrizze, nem a szkriptfájlt. Egy létező fájl nem futott szkript.

A nevet tesztelje, ne a naplót

Csatlakozás után kérdezzen le az ügyféltől egy csak belső gazdagépnevet, aztán egy nyilvános nevet, majd ellenőrizze, melyik kiszolgáló válaszolt. Egy működő beállításban a két válasz különböző helyekről jön, és mindkettőnek illeszkednie kell a tervhez.

Ha a név feloldódik, de a szolgáltatás meghiúsul, lépjen tovább a útválasztáshoz és alkalmazáshozzáféréshez ahelyett, hogy újra módosítaná a DNS-t. Az OpenVPN kézikönyv dokumentálja a dhcp-option beállítást és a szkriptkörnyezetet; használja, hogy megerősítse, mit kell alkalmaznia az ügyfélnek, mielőtt újabb feloldófájlt szerkeszt.