Von OpenVPN gepushter DNS wird ignoriert: welche Komponente ihn anwendet

Das Protokoll zeigt die Option, die der Server gepusht hat, der Tunnel steht, und interne Namen schlagen weiterhin fehl. Eine Abfrage direkt an den Resolver antwortet, der Server ist also in Ordnung, doch jede Anwendung fragt weiter den lokalen Router. Was beim Client ankommt, ist ein Angebot, keine Änderung am Resolver, und die Komponente, die die Namensauflösung besitzt, unterscheidet sich unter Linux, Windows und macOS. Sobald Sie die Option von ihrem Besitzer trennen, decken vier Fehler fast jeden Bericht ab: kein Hook, zwei konkurrierende Hooks, Split-DNS, das wie vorgesehen arbeitet, oder ein kurzer Name, der ein Suffix statt eines Servers braucht.

Eine gepushte Option ist ein Angebot, keine Installation

Auf dem Server beschreiben zwei Direktiven die Absicht, nicht die Wirkung:

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

Der Client erhält keinen konfigurierten Resolver. Er erhält Umgebungsvariablen, foreign_option_1 und weitere, eine pro gepushter Zeile, und etwas Lokales muss sie lesen und den Resolver-Zustand des Betriebssystems umschreiben. Unter Linux tut das standardmäßig nichts, deshalb können ein korrekter Server und ein verbundener Client weiterhin über das LAN auflösen.

Zwischen beiden Enden liegen drei Stufen: Der Push muss ankommen, der Client muss ihn offenlegen, und ein Hook muss ihn anwenden. Lesen Sie die mittlere Stufe im Client-Protokoll und die letzte im Resolver-Zustand, nie umgekehrt, denn eine Protokollzeile belegt nur die ersten beiden.

Bestätigen Sie, dass der Push ankam, und finden Sie den Besitzer

Beginnen Sie mit dem Namen des Starters: ein blankes openvpn Kommando, eine systemd-Instanz, NetworkManager oder ein Hersteller-Client. Das entscheidet, wo ein Hook leben kann. Auf einem Host mit systemd-resolved resolvectl status listet jede Strecke mit den tatsächlich genutzten DNS-Servern und Suchdomänen, und die Tunnel-Strecke heißt nicht immer tun0.

Erscheint die gepushte Adresse im Protokoll, aber auf keiner Strecke, fehlt die Integration. Erscheint sie auf der Strecke und verlassen Abfragen dennoch andere Wege, liegt das Problem darin, welche Abfragen diese Strecke wählen. NetworkManager dns=dnsmasq in der Datei /etc/NetworkManager/NetworkManager.conf betreibt einen lokalen Weiterleiter, der Split-DNS absichtlich umsetzt: Namen innerhalb der VPN-Domäne gehen an den VPN-Resolver, alles andere behält seinen bisherigen Weg. Dieses Verhalten wirkt wie ein Fehler, wenn Sie erwartet haben, dass der gesamte Verkehr umzieht; prüfen Sie die Einstellungen pro Verbindung mit nmcli connection show "My VPN", wo ipv4.dns und ipv4.dns-search die Werte hinter dem halten, was das Gerät meldet, bevor Sie es als defekt bezeichnen. Soll jede Abfrage wirklich den VPN-Resolver erreichen, entfernen Sie dns=dnsmasq aus NetworkManager.conf und starten NetworkManager neu, was die Auflösung den Verbindungseinstellungen zurückgibt; andernfalls behalten Sie Split-DNS und korrigieren stattdessen die gepushte Domain-Liste.

Linux: die Optionen dem Resolver übergeben

Distributionspakete liefern dafür einen Hook, und dem Client muss erlaubt sein, ihn auszuführen. Eine typische Anordnung auf einem Host ohne systemd-resolved:

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

Mit systemd-resolved ändert das ältere resolv.conf-Skript womöglich nichts Wesentliches, weil der Stub-Resolver Zustand pro Strecke hält. update-systemd-resolved Helfer dokumentiert eine Hook-Form, die up-restart und down-pre verwendet, was zählt, wenn eine Schnittstelle einen einzelnen Verbindungsversuch überlebt. Was immer Sie wählen, eine Komponente muss den Zustand besitzen. Ein fremder Hook neben NetworkManager ergibt zwei Schreiber für dieselbe Strecke, und das Ergebnis hängt dann von der Reihenfolge ab statt von Ihrer Konfiguration.

Es gibt auch den Fall, dass NetworkManager die gepushte Option völlig ignorierte, bis die Serveradresse in den IPv4-Einstellungen der Verbindung eingetragen war, woraufhin der Resolver-Zustand sie als in Gebrauch zeigte. Das ist einen Versuch wert, bevor Sie Skripte umschreiben, weil es das Problem von einem Shell-Hook in das Verbindungsprofil verschiebt, das den Tunnel ohnehin trägt.

Windows und macOS wenden unterschiedliche Teile an

Der Windows-Client setzt zwar die DNS-Server des VPN-Adapters, aber Windows wählt die Schnittstelle weiterhin nach Metrik und braucht weiterhin ein Suffix, um einen kurzen Namen zu erweitern. Prüfen Sie den Adapterzustand statt das Profil:

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

Fehlt die Adresse, setzen Sie sie mit Set-DnsClientServerAddress -InterfaceAlias "My VPN" -ServerAddresses 10.8.0.1, dann fügen Sie das Suffix den IPv4-Eigenschaften des Adapters hinzu, sodass fileserver zu fileserver.corp.example wird. Ein maschinenweiter SearchList Wert unter Tcpip\Parameters tut dasselbe. Wo der lange Name auflöst und der blanke nicht, ist der Resolver bereits korrekt, und die Suchliste ist schuld. Die Korrekturen der Reihe nach: pushen Sie ein DOMAIN damit der Client das Suffix lernt, fügen Sie das Suffix der Suchliste des Adapters oder der Verbindung hinzu, und pinnen Sie den Namen als vorübergehende Maßnahme in hosts, oder LMHOSTS unter Windows; NetBIOS-Browsing überquert keinen Router, der Broadcast, der im Büro-LAN einen kurzen Namen findet, erreicht also nie einen Tunnel-Client.

block-outside-dns block-outside-dns ist ein Windows-Client-Verhalten, keine portable Profilzeile, und das Kopieren in ein Linux- oder macOS-Profil bildet es dort nicht nach. Funktionieren öffentliche Namen und interne scheitern unter Windows, vergleichen Sie die Adapterreihenfolge unter Erweiterte Einstellungen mit ipconfig /all. Unter macOS gehört die Resolver-Reihenfolge pro Dienst zum System, verwenden Sie also scutil --dns , um zu sehen, welcher Resolver für welche Domäne befragt wird, und behandeln Sie jede einzelne gemeldete Profilkorrektur als clientabhängig statt als allgemein.

Eine virtuelle Maschine auf demselben Laptop erbt davon nichts. Geben Sie dem Gast einen eigenen Resolver-Eintrag für die interne Domäne, oder lassen Sie das NAT des Hypervisors seine Abfragen über den Host weiterleiten, was nur stimmt, solange der Host-Tunnel steht.

Die Historie ist die dritte Ursache. DNS-Server oder Suffix-Einstellungen aus einem früheren Profil können Neuverbindungen überleben; wenn der Adapter korrekt aussieht und Namensauflösungen dennoch scheitern, vergleichen Sie den aktiven Adapter mit Get-VpnConnection und löschen oder überschreiben Sie den veralteten Eintrag, bevor Sie den Server anfassen.

Beweisen Sie, wohin die Abfrage ging

Eine Aufzeichnung während einer Auflösung entscheidet den Streit: tcpdump -ni eth0 port 53 zeigt Abfragen auf der physischen Schnittstelle, was bedeutet, dass sie den Tunnel verlassen und der Resolver nie umgestellt wurde. dig @10.8.0.1 name.corp.example trennt dann die beiden verbleibenden Fälle. Antwortet die direkte Abfrage, arbeitet der Resolver und der Client nutzt ihn nicht; läuft sie in eine Zeitüberschreitung, ist der Resolver durch den Tunnel nicht erreichbar und keine lokale Änderung hilft.

Ist der noch genutzte Resolver der vom Anbieter ausgegebene, verschlüsselt der Tunnel den Verkehr, während die Namen für diesen Anbieter sichtbar bleiben. Das ist eine Leak-Frage und keine funktionale, und dieselbe Aufzeichnung beantwortet sie: eine Abfrage auf der physischen Schnittstelle geht an jemanden außerhalb des Tunnels.

Zur Erreichbarkeit gehört die Firewall auf dem VPN-Host, die UDP und TCP 53 aus dem Pool erlauben muss. Ein blockierter Port sieht genau wie ein defekter Push aus, und ein Resolver, der nur aus dem Tunnelnetz antwortet, ebenso. Wiederholen Sie die Aufzeichnung nach einem Trennen und erneuten Verbinden, denn Einstellungen, die beim ersten Verbinden erscheinen und beim zweiten verschwinden, sind ein Lebenszyklusfehler im Hook, keine fehlende Option.

Halten Sie einen Besitzer und prüfen Sie der Reihe nach

Ein Skript, das Adapter-DNS anhand eines geratenen Tunnelzustands umschreibt, dupliziert Konfiguration, die das Profil bereits trägt, und versagt still, sobald die Vermutung das erste Mal falsch ist. Bevorzugen Sie die DNS-Einstellungen der Verbindung selbst oder einen dokumentierten Hook, und notieren Sie, welchen Sie gewählt haben, damit die nächste Person keinen zweiten hinzufügt.

Schließen Sie den Kreis mit vier Prüfungen: die gepushte Adresse auf der Tunnel-Strecke, der interne Name als voll qualifizierter Name aufgelöst, derselbe Name ohne Suffix aufgelöst, und beides nach einer Neuverbindung weiterhin wahr. Eine Aufzeichnung sagt Ihnen, welche der vier gescheitert ist. OpenVPN 2.6-Handbuch listet dhcp-option und Skript-Direktiven mit ihren Plattformhinweisen.