Vum OpenVPN geschéckten DNS gëtt ignoréiert: wéi eng Komponent en uwendet

D'Logbuch weist d'Optioun, déi de Server geschéckt huet, den Tunnel ass um, an déi intern Nimm schloe weider feel. Eng direkt Ufro un de Resolver äntwert, also ass de Server an der Rei, awer all Applikatioun freet weider de lokale Router. Wat beim Client ukomm ass, ass en Ubett, keng Ännerung um Resolver, an d'Komponent, déi d'Namenopservatioun huet, ënnerscheet sech op Linux, Windows an macOS. Soubal Dir d'Optioun vun hirem Besëtzer trennt, decken véier Feeler bal all Rapport of: keen Hook, zwee konkurréierend Hooks, gespléckten DNS, dee wéi geplangt funktionéiert, oder en kuerzen Numm, deen e Suffix brauch an net e Server.

Eng geschéckte Optioun ass en Ubett, keng Installatioun

Um Server beschreiwen zwee Direktiven d'Absicht, net den Effekt:

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

De Client kritt keen ageriichtenen Resolver. Hie kritt Ëmfeldvariabelen, foreign_option_1 an déi nächst, eng pro geschéckter Zeil, an eppes Lokales muss se liesen an den Zoustand vum Resolver am Betribssystem nei schreiwen. Op Linux mécht standardméisseg näischt dat, dofir kënnen e korrekte Server an e verbonne Client nach ëmmer iwwer d'LAN Nimm opléisen.

Tëschent den zwou Enner stinn dräi Etappen: de Push muss ukommen, de Client muss en exponéieren, an en Hook muss en uwenden. Liest déi mëttelst Etapp am Client-Logbuch an déi lescht am Resolver-Zoustand, ni ëmgedréint, well eng Logbuchzeil nëmmen déi éischt zwee beweist.

Vergewëssert Iech, datt de Push ukomm ass, a fannt de Besëtzer

Fänkt mat dem Numm vum Starter un: en einfachen openvpn Befehl, eng systemd-Instanz, NetworkManager oder e Client vum Hiersteller. Dat entscheet, wou en Hook ka liewen. Op engem Host mat systemd-resolved, resolvectl status lëscht all Verbindung mat den DNS-Serveren an de Sichdomänen, déi se tatsächlech benotzt, an d'Verbindung vum Tunnel heescht net ëmmer tun0.

Wann déi geschéckt Adress am Logbuch steet, awer op kengem Verbindung, feelt d'Integratioun. Wann se op der Verbindung steet an d'Ufroe ginn nach ëmmer soss eraus, ass de Problem, wéi eng Ufroe déi Verbindung auswielen. NetworkManager dns=dnsmasq an der Datei /etc/NetworkManager/NetworkManager.conf bedreift en lokalen Iwwerleefer, dee gespléckten DNS bewosst ëmsetzt: Nimm bannent der VPN-Domän ginn un de VPN-Resolver, alles anescht behält säi fréiere Wee. Dëst Verhalen erschéngt als Feeler, wann Dir erwaart hutt, datt de ganze Verkéier sech verréckelt; kontrolléiert d'Astellunge pro Verbindung mat nmcli connection show "My VPN", wou ipv4.dns an ipv4.dns-search d'Wäerter hannert deem halen, wat den Apparat mellt, ier Dir en als futti bezeechent. Wann all Ufro wierklech de VPN-Resolver erreeche soll, huet dns=dnsmasq aus der NetworkManager.conf Datei eraus a startet NetworkManager nei, wat d'Namenopservatioun un d'Verbindungsastellungen zréckgëtt; soss behält de gespléckten DNS a korrigéiert d'geschéckte Domännelëscht.

Linux: gitt d'Optiounen un de Resolver

D'Distributiounspäck ginn en Hook dofir mat, an de Client muss et dierfe lafen. Eng typesch Uerdnung op engem Host ouni systemd-resolved:

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

Mat systemd-resolved ännert dat méi al resolv.conf-Skript vläicht näischt Wichteges, well de Stub-Resolver den Zoustand pro Verbindung hält. update-systemd-resolved den Helfer dokumentéiert eng Hook-Form, déi up-restart an down-pre benotzt, wat zielt, wann eng Interface eng eenzeg Verbindungsversuch iwwerlieft. Wat Dir och wielt, eng Komponent muss den Zoustand besëtzen. En onverbonnene Hook nieft NetworkManager gëtt zwou Schreiwer op déiselwecht Verbindung, an d'Resultat hänkt dann vun der Uerdnung of an net vun Ärer Konfiguratioun.

Et gëtt och de Fall, wou NetworkManager déi geschéckt Optioun komplett ignoréiert huet, bis d'Serveradress an den IPv4-Astellunge vun der Verbindung agedroe gouf, duerno huet den Zoustand vum Resolver se als a Gebrauch gewisen. Et ass e Versuch wäert, ier Dir Skripten ëmschreift, well et de Problem vun engem Shell-Hook an de Verbindungsprofil verréckelt, deen den Tunnel schonn dréit.

Windows an macOS wenden ënnerschiddlech Deeler un

De Windows-Client setzt wierklech d'DNS-Servere vum VPN-Adapter, awer Windows wielt nach ëmmer eng Interface no der Metrik a brauch nach ëmmer e Suffix, fir e kuerzen Numm auszebreeden. Bestätegt den Zoustand vum Adapter an net de Profil:

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

Wann d'Adress feelt, setzt se mat Set-DnsClientServerAddress -InterfaceAlias "My VPN" -ServerAddresses 10.8.0.1, da füügt de Suffix den IPv4-Eegenschafte vum Adapter bäi, sou datt fileserver gëtt fileserver.corp.example. En SearchList Wäert ënner Tcpip\Parameters mécht datselwecht. Wou den lange Numm sech opléist an dee bloe net, ass de Resolver schonn richteg an d'Sichlëscht ass schold. D'Korrekturen, der Rei no: schéckt en DOMAIN sou datt de Client de Suffix léiert, füügt dee Suffix an d'Sichlëscht vum Adapter oder der Verbindung, a fixéiert als temporär Mesure den Numm an hosts, oder LMHOSTS op Windows; d'NetBIOS-Browsing geet net iwwer e Router, dofir erreecht de Broadcast, deen en kuerzen Numm an der Büro-LAN fënnt, ni e Tunnel-Client.

block-outside-dns block-outside-dns ass e Verhalen vum Windows-Client, keng portable Profilszeil, an d'Kopéieren an e Linux- oder macOS-Profil reproduzéiert et do net. Wann ëffentlech Nimm fonctionéieren an déi intern op Windows feel schloen, vergläicht d'Adaptersuerdnung ënner Erweidert Astellungen mat ipconfig /all. Op macOS gehéiert d'Resolveruerdnung pro Service zum System, benotzt also scutil --dns fir ze gesinn, wéi en Resolver fir wéi eng Domän gefrot gëtt, a behandelt all eenzel gemellte Profilkorrektur als clientofhängeg an net allgemeng.

Eng virtuell Maschinn op dësem Laptop ierft dovun näischt. Gitt dem Gaascht seng eegen Resolver-Andro fir déi intern Domän, oder loosst den NAT vum Hypervisor seng Ufroe iwwer den Host viruleeden, wat nëmme richteg ass, soulaang den Tunnel vum Host um ass.

D'Historie ass déi drëtt Ursaach. DNS-Servere oder Suffix-Astellunge vun engem fréiere Profil kënnen Neiverbindungen iwwerliewen, also wann den Adapter richteg ausgesäit an d'Sich weider feel schléit, vergläicht den aktiven Adapter mat Get-VpnConnection a läscht oder iwwerschreift den ale Andro, ier Dir de Server beréiert.

Beweist, wou d'Ufro higaangen ass

Eng Opnam während enger Sich entscheet de Sträit: tcpdump -ni eth0 port 53 weist Ufroe op der physikalescher Interface, dat heescht se ginn aus dem Tunnel eraus an de Resolver gouf ni ëmgestallt. dig @10.8.0.1 name.corp.example trennt dann déi zwee reschtlech Fäll. Wann déi direkt Ufro äntwert, funktionéiert de Resolver an de Client benotzt en net; wann se iwwer d'Zäit geet, ass de Resolver iwwer den Tunnel net erreechbar an keng lokal Ännerung hëlleft.

Wann de Resolver, deen nach benotzt gëtt, dee vum Provider verdeelte ass, verschlësselt den Tunnel de Verkéier, awer d'Nimm bleiwen deem Provider sichtbar. Et ass eng Fro vum Lechen an net vun der Funktioun, an déiselwecht Opnam äntwert drop: eng Ufro op der physikalescher Interface geet un een ausserhalb vum Tunnel.

D'Erreechbarkeet enthält d'Firewall um VPN-Host, déi UDP an TCP 53 aus dem Pool erlaben muss. E gespaarte Port gesäit genee wéi e futti Push aus, an och e Resolver, deen nëmmen aus dem Tunnelnetz äntwert. Widderhëlt d'Opnam no engem Trennen an Neiverbannen, well Astellungen, déi bei der éischter Verbindung erschéngen an bei der zweeter verschwanne, e Feeler am Liewenszyklus vum Hook sinn, keng fehlend Optioun.

Halt een eenzege Besëtzer a verifizéiert der Rei no

E Skript, dat den Adapter-DNS op Grond vun engem ugehollenen Tunnelzoustand ëmschreift, duplizéiert Konfiguratioun, déi de Profil schonn dréit, an et feelt stëll beim éischte Kéier, wou d'Vermuddung falsch ass. Bevirzugt d'DNS-Astellunge vun der Verbindung selwer oder een dokumentéierten Hook, a schreift op, wéien Dir gewielt hutt, sou datt déi nächst Persoun keen zweete bäisetzt.

Schléisst de Krees mat véier Kontrollen: déi geschéckt Adress op der Tunnelverbindung, den internen Numm als vollqualifizéierten Numm opgeléist, deeselwechten Numm ouni de Suffix opgeléist, an alleb zwee nach wouer no enger Neiverbindung. Eng Opnam seet Iech, wéi eng vun de véier feel geschloen huet. Den Handbuch vum OpenVPN 2.6 lëscht dhcp-option an d'Skript-Direktiven mat hire Plattformnotizen.