OpenVPN pusht DNS, doch der Resolver sieht es vielleicht nie

Das Client-Log zeigt den gepushten DNS-Server, der Tunnel ist verbunden, und ein interner Name löst weiterhin nicht auf. An der Übertragung selbst ist nichts defekt. Die Option kam an, und der Resolver des Betriebssystems hat sie nie benutzt, weil OpenVPN auf den meisten Unix-Clients den Wert liefert und die Anwendung der Plattform überlässt.

Das Symptom: Das Log zeigt DNS, und Namen schlagen weiterhin fehl

OpenVPN dhcp-option überträgt DNS- und Domäneninformationen, und der Client protokolliert, was er empfangen hat. Bei manchen Implementierungen wendet der Client diese Einstellungen intern an; bei anderen exportiert er sie für ein Integrationsskript oder einen Netzwerkdienst. Die Logzeile beschreibt nur die erste Hälfte. Die zweite Hälfte geschieht dort, wo der Client nicht zuständig ist. Genau dort sitzt der Fehler meistens.

Deshalb treten ein verbundener Tunnel und ein fehlschlagender interner Name so oft gemeinsam auf. Der Wert ist da, der Abnehmer fehlt oder ist falsch konfiguriert, und der Resolver verwendet still weiter den öffentlichen Server, den er vor der Verbindung nutzte.

Empfangen heißt nicht angewandt

Ein Client kann einen gepushten DNS-Wert protokollieren, während der Systemresolver weiterhin einer anderen Dienststelle gehört. Ein Browser kann zudem eine eigene Richtlinie für verschlüsseltes DNS haben, die den Systemresolver vollständig umgeht, was die denkwürdige Lage erzeugt, in der eine Anwendung interne Namen auflöst und eine andere nicht.

Prüfen Sie die unterstützte Integration der Implementierung, statt anzunehmen, jeder Unix-Client schreibe dieselbe Datei um. Diese Annahme ist der Grund, warum Leute eine Resolverkonfiguration bearbeiten, die niemand liest.

Finden Sie den Eigentümer des Resolvers je Plattform

Unter Windows kann die Namensauflösungsrichtlinientabelle bestimmte Suffixe an bestimmte Server leiten, und der VPN-Client kann dort Regeln installieren. Prüfen Sie die Richtlinie, nicht nur die DNS-Liste des Adapters. Unter Linux kann NetworkManager oder systemd-resolved die Konfiguration besitzen, und wer sie besitzt, entscheidet, was ein erneutes Verbinden bewahrt.

Lesen Sie den effektiven Zustand mit dem Werkzeug, das tatsächlich Abfragen beantwortet: resolvectl query internal.example.net auf einem systemd-resolved-Host oder das Plattformäquivalent. Vergleichen Sie dann diese Antwort mit dem DNS-Server, den das Client-Log als gepusht meldet.

Vermeiden Sie mehrere Dienste, die Resolver-Einstellungen ohne Abstimmung überschreiben. Zwei Eigentümer erzeugen ein Ergebnis, das sporadisch wirkt, und jedes erneute Verbinden scheint es zufällig zu reparieren oder zu zerstören.

Skripte und foreign_option

OpenVPN exportiert gepushte Optionen über Variablen namens foreign_option_N an Skripte, und ein Skript kann sie in Resolver-Befehle übersetzen. Diese Einrichtung ist eine unterstützte Integration, kein automatisches Verhalten, und sie muss auf dem Client installiert und aufgerufen werden.

Wenn Sie sich auf ein Skript verlassen, protokollieren Sie dessen Ausführung und Exit-Status. Ein Skript, das läuft, aber lautlos scheitert, hinterlässt dasselbe Symptom wie gar kein Skript, und es ist schwerer zu bemerken, weil die Konfiguration vollständig aussieht. Prüfen Sie die Ausgabe des Skripts, nicht die Skriptdatei. Eine vorhandene Datei ist kein Skript, das gelaufen ist.

Testen Sie den Namen, nicht das Log

Fragen Sie nach dem Verbinden vom Client aus einen nur intern erreichbaren Hostnamen ab, dann einen öffentlichen Namen, und prüfen Sie, welcher Server geantwortet hat. In einem funktionierenden Aufbau kommen die beiden Antworten von verschiedenen Stellen, und beide sollten zum Entwurf passen.

Wenn der Name auflöst, aber der Dienst fehlschlägt, gehen Sie weiter zu Routing und Anwendungszugriff, statt DNS erneut zu ändern. Das OpenVPN-Handbuch dokumentiert dhcp-option und die Skriptumgebung; nutzen Sie es, um zu bestätigen, was Ihr Client anwenden soll, bevor Sie eine weitere Resolverdatei bearbeiten.