Az OpenVPN által tolt DNS figyelmen kívül marad: melyik komponens alkalmazza

A napló mutatja a szerver által tolt beállítást, az alagút él, és a belső nevek mégis meghiúsulnak. A feloldóhoz intézett közvetlen lekérdezés válaszol, tehát a szerver rendben van, mégis minden alkalmazás a helyi útválasztót kérdezi. Ami a klienshez eljutott, az ajánlat, nem a feloldó megváltoztatása, és a névfeloldást birtokló komponens Linuxon, Windowson és macOS-en eltér. Amint elválasztja a beállítást a tulajdonosától, négy hiba lefedi szinte az összes jelentést: nincs hook, két versengő hook, a megosztott DNS a tervezés szerint működik, vagy egy rövid névhez utótag kell, nem szerver.

A tolt beállítás ajánlat, nem telepítés

A szerveren két utasítás szándékot ír le, nem hatást:

push "dhcp-option DNS 10.8.0.1"
push "dhcp-option DOMAIN corp.example"

A kliens nem kap konfigurált feloldót. Környezeti változókat kap, foreign_option_1 és továbbiakat, egyet minden tolt sorhoz, és valaminek helyben olvasnia kell őket, és át kell írnia az operációs rendszer feloldói állapotát. Linuxon alapértelmezés szerint semmi nem teszi ezt, ezért egy helyes szerver és egy csatlakozott kliens még mindig feloldhat neveket a LAN-on keresztül.

Két vég között három szakasz van: a pushnak el kell jutnia, a kliensnek fel kell tárnia, és egy hooknak alkalmaznia kell. A középső szakaszt a kliens naplójában, az utolsót a feloldó állapotában olvassa, soha fordítva, mert egy naplósor csak az első kettőt bizonyítja.

Erősítse meg, hogy a push megérkezett, és keresse meg a tulajdonost

Kezdje az indító megnevezésével: egy csupasz openvpn parancs, egy systemd-példány, a NetworkManager vagy egy gyártói kliens. Ez dönti el, hol élhet hook. Egy systemd-resolveddal futó gazdagépen, resolvectl status minden kapcsolatot felsorol a ténylegesen használt DNS-szerverekkel és keresési tartományokkal, és az alagút kapcsolata nem mindig tun0 néven szerepel.

Ha a tolt cím megjelenik a naplóban, de egyetlen kapcsolaton sem, hiányzik az integráció. Ha megjelenik a kapcsolaton, és a lekérdezések mégis máshova mennek, a probléma az, mely lekérdezések választják azt a kapcsolatot. NetworkManager dns=dnsmasq a fájlban /etc/NetworkManager/NetworkManager.conf helyi továbbítót futtat, amely szándékosan megosztott DNS-t valósít meg: a VPN-tartományon belüli nevek a VPN feloldójához mennek, minden más megtartja a korábbi útvonalát. Ez a viselkedés hibának tűnik, amikor azt várta, hogy minden forgalom átköltözik; ellenőrizze a kapcsolatonkénti beállításokat ezzel nmcli connection show "My VPN", ahol ipv4.dns és ipv4.dns-search az eszköz által jelentett mögötti értékeket tartják, mielőtt töröttnek nevezné. Ha minden lekérdezésnek valóban a VPN feloldójához kell jutnia, távolítsa el dns=dnsmasq a NetworkManager.conf fájlból, és indítsa újra a NetworkManagert, ami visszaadja a névfeloldást a kapcsolat beállításainak; ellenkező esetben tartsa meg a megosztott DNS-t, és javítsa a tolt tartománylistát.

Linux: adja át a beállításokat a feloldónak

A disztribúciós csomagok hookot szállítanak ehhez, és a kliensnek engedélyezni kell a futtatását. Tipikus elrendezés systemd-resolved nélküli gazdagépen:

script-security 2
up /etc/openvpn/update-resolv-conf
down /etc/openvpn/update-resolv-conf

Systemd-resolveddal a régebbi resolv.conf-szkript talán semmi lényegeset nem változtat, mert a stub feloldó kapcsolatonként tartja az állapotot. update-systemd-resolved a segéd dokumentál egy hookformát, amely up-restart és down-pre beállítást használ, ami akkor számít, amikor egy interfész túlél egyetlen kapcsolódási kísérletet. Bármit is választ, egy komponensnek birtokolnia kell az állapotot. Egy nem kapcsolódó hook melléállítása a NetworkManagerhez két írót ad ugyanahhoz a kapcsolathoz, és az eredmény akkor a sorrendtől függ, nem a konfigurációjától.

Olyan eset is van, amikor a NetworkManager teljesen figyelmen kívül hagyta a tolt beállítást, míg a szerver címét be nem írták a kapcsolat IPv4-beállításaiba, ezután a feloldó állapota használatban mutatta. Érdemes kipróbálni a szkriptek újraírása előtt, mert a problémát a shell-hooktól az alagutat már hordozó kapcsolati profilba helyezi át.

A Windows és a macOS különböző részeket alkalmaz

A Windows kliens valóban beállítja a VPN-adapter DNS-szervereit, de a Windows továbbra is metrika szerint választ interfészt, és továbbra is utótag kell a rövid név kiterjesztéséhez. Az adapter állapotát erősítse meg, nem a profilt:

Get-DnsClientServerAddress -InterfaceAlias "My VPN"
Get-DnsClientNrptPolicy

Ha a cím hiányzik, állítsa be ezzel Set-DnsClientServerAddress -InterfaceAlias "My VPN" -ServerAddresses 10.8.0.1, majd adja hozzá az utótagot az adapter IPv4-tulajdonságaihoz, hogy fileserver legyen fileserver.corp.example. Egy gép szintű SearchList érték a Tcpip\Parameters alatt ugyanezt teszi. Ahol a hosszú név feloldódik, a csupasz pedig nem, a feloldó már helyes, és a keresési lista a hibás. A javítások sorrendben: toljon egy DOMAIN hogy a kliens megtanulja az utótagot, adja hozzá azt az utótagot az adapter vagy a kapcsolat keresési listájához, és ideiglenes intézkedésként rögzítse a nevet a hosts fájlban, vagy LMHOSTS alatt Windowson; a NetBIOS-böngészés nem lép át útválasztón, ezért az irodai LAN-on rövid nevet találó szórás soha nem ér el egy alagútklienst.

block-outside-dns A block-outside-dns a Windows kliens viselkedése, nem hordozható profilsor, és Linux vagy macOS profilba másolva nem reprodukálja ott. Ha a nyilvános nevek működnek, a belsők pedig meghiúsulnak Windowson, hasonlítsa össze az adapterek sorrendjét a Speciális beállítások alatt ezzel ipconfig /all. macOS-en a szolgáltatásonkénti feloldósorrend a rendszerhez tartozik, ezért használja ezt scutil --dns , hogy lássa, melyik tartományhoz melyik feloldót kérdezik, és a jelentett egyedi profiljavítást kliensfüggőnek tekintse, nem általánosnak.

A virtuális gép ugyanazon a laptopon semmit nem örököl ebből. Adjon a vendégnek saját feloldóbejegyzést a belső tartományhoz, vagy hagyja, hogy a hipervizor NAT-ja továbbítsa a lekérdezéseit a gazdagépen át, ami csak addig helyes, amíg a gazdagép alagútja él.

A történet a harmadik ok. Egy korábbi profil DNS-szerverei vagy utótagbeállításai túlélhetik az újracsatlakozásokat, ezért amikor az adapter helyesnek látszik, és a keresések mégis meghiúsulnak, hasonlítsa össze az élő adaptert ezzel Get-VpnConnection , és törölje vagy írja felül az elavult bejegyzést, mielőtt a szerverhez nyúl.

Bizonyítsa, hova ment a lekérdezés

Egy rögzítés egyetlen keresés alatt eldönti a vitát: tcpdump -ni eth0 port 53 lekérdezéseket mutat a fizikai interfészen, ami azt jelenti, hogy kilépnek az alagúton kívülre, és a feloldót soha nem kapcsolták át. dig @10.8.0.1 name.corp.example majd elválasztja a két fennmaradó esetet. Ha a közvetlen lekérdezés válaszol, a feloldó működik, és a kliens nem használja; ha lejár, a feloldó az alagúton át elérhetetlen, és semmilyen helyi változtatás nem segít.

Ha a még használt feloldó az, amelyet a szolgáltató osztott ki, az alagút titkosítja a forgalmat, miközben a nevek láthatók maradnak annak a szolgáltatónak. Ez szivárgási kérdés, nem működési, és ugyanaz a rögzítés válaszol rá: a fizikai interfészen lévő lekérdezés az alagúton kívüli valakihez megy.

Az elérhetőség magában foglalja a VPN-gazdagép tűzfalát, amelynek engedélyeznie kell az UDP és TCP 53 forgalmát a poolból. Egy zárt port pontosan úgy néz ki, mint egy törött push, és egy olyan feloldó is, amely csak az alagúthálózat belsejéből válaszol. Ismételje meg a rögzítést egy leválasztás és újracsatlakozás után, mert az első kapcsolatnál megjelenő, a másodiknál eltűnő beállítások életciklus-hiba a hookban, nem hiányzó beállítás.

Tartson egy tulajdonost, és sorrendben ellenőrizzen

Egy szkript, amely kitalált alagútállapot alapján írja át az adapter DNS-ét, megkettőzi a profilon már meglévő konfigurációt, és csendben meghiúsul, amikor a találgatás először téves. Részesítse előnyben a kapcsolat saját DNS-beállításait vagy egy dokumentált hookot, és jegyezze fel, melyiket választotta, hogy a következő ember ne adjon hozzá egy másodikat.

Zárja le a hurkot négy ellenőrzéssel: a tolt cím jelen van az alagút kapcsolatán, a belső név teljesen minősített névként oldódik fel, ugyanaz a név utótag nélkül is feloldódik, és mindkettő még igaz egy újracsatlakozás után. Egy rögzítés megmondja, melyik a négy közül hiúsult meg. Az OpenVPN 2.6 kézikönyve felsorolja dhcp-option és a szkriptutasításokat a platformmegjegyzéseikkel.