OpenVPN hat einen DNS-Server übertragen, aber Linux ignoriert ihn

Der übertragene DNS-Server steht im Log, der Tunnel ist oben, und interne Namen scheitern weiterhin. An der Übertragung selbst ist nichts kaputt; die Einstellung kam an und blieb dort stehen. Eine übertragene DNS-Option ist eine Nachricht an den Client, keine Anweisung an den Resolver des Betriebssystems, und die Übergabe zwischen beiden ist der Punkt, an dem die meisten dieser Fälle enden. Fünf Prüfungen, der Reihe nach, finden die Übergabe, die nicht stattgefunden hat.

Prüfung eins: wie die Verbindung beginnt

Der Eigentümer der Verbindung bestimmt, wer Resolver-Einstellungen anwenden kann. Ein direktes openvpn-Kommando aus einer Shell besitzt nichts außer seinem eigenen Prozess, während eine systemd-Unit, NetworkManager oder ein Hersteller-Client jeweils ihren eigenen Weg haben, DNS zu veröffentlichen. Lesen Sie die Prozessliste und den Unit-Namen, bevor Sie eines davon annehmen.

Ein Kommandozeilenprozess ist nicht automatisch eine NetworkManager-Verbindung, und eine NetworkManager-Verbindung ist nicht automatisch das, was resolv.conf geschrieben hat. Diese beiden Annahmen erklären den Großteil der verschwendeten Stunden in dieser Untersuchung. Fragen Sie, welche Komponente DNS für die Schnittstelle veröffentlichen würde, die Sie tatsächlich sehen.

Notieren Sie den Eigentümer, bevor Sie fortfahren. Jede spätere Prüfung hängt davon ab.

Prüfung zwei: was die Resolver-Verknüpfung tatsächlich enthält

Auf einem systemd-resolved-Host listet resolvectl status jede Verknüpfung mit ihren DNS-Servern und Domänen auf. Finden Sie die Tunnel-Verknüpfung und lesen Sie ihre Einträge, und nehmen Sie nicht an, dass die Schnittstelle tun0 heißt, denn die Nummerierung folgt der Reihenfolge der Erstellung. Fehlt die übertragene Adresse in der Verknüpfung, ist die Übergabe gescheitert und nicht die Abfrage.

Ist die Adresse vorhanden, lautet die nächste Frage, welche Domänen diese Verknüpfung beansprucht. Eine Verknüpfung ohne Domänenliste beantwortet nur Namen, nach denen direkt gefragt wird, und das ist selten, was ein Split-DNS-Deployment will. Die Adresse allein ist notwendig, aber nicht ausreichend.

Vergleichen Sie den Verknüpfungsnamen in der Resolver-Ausgabe mit dem Schnittstellennamen im VPN-Log, bevor Sie irgendeinen Schluss ziehen. Eine Abweichung dort bedeutet meist, dass die Logzeile von einem anderen Prozess kam.

Prüfung drei: ob der Namensraum diese Verknüpfung wählt

Ein Resolver kann den richtigen Server halten und trotzdem nicht befragt werden. Die Domäne pro Verknüpfung entscheidet, welche Anfragen an welche Verknüpfung gehen, und ohne Routing-Domäne fällt der private Namensraum auf das zurück, was die Standard-Verknüpfung sagt. Deshalb kann resolvectl query für den internen Namen gelingen, während eine Anwendung weiterhin scheitert. Die Anwendung nutzt möglicherweise einen ganz anderen Resolver-Pfad.

Prüfen Sie die Domänenzuweisung, nicht nur die Serveradresse. Eine als ~corp.example geschriebene Domäne ist eine Routing-Domäne, und die Tilde ändert, wie der Name abgeglichen wird.

Wenn die Anwendung einen eigenen Resolver hat, testen Sie mit demselben Mechanismus, den sie verwendet, statt mit dem Systemwerkzeug. Ein Abfragetool, das den System-Resolver umgeht, wird unabhängig vom Zustand der Verknüpfung Erfolg haben.

Prüfung vier: ein Eigentümer, nicht zwei

Wenn NetworkManager bereits das VPN und den Resolver-Zustand verwaltet, erzeugt das Hinzufügen eines unabhängigen Hook-Skripts konkurrierende Schreiber. Der vom Paket bereitgestellte Hook für systemd-resolved ist eine unterstützte Integration und erwartet einen bestimmten Lebenszyklus: script-security 2, einen up-Pfad, up-restart, einen down-Pfad und down-pre. Diese Optionen sorgen dafür, dass Registrierung und Entfernung zu den richtigen Zeitpunkten geschehen und nicht nur bei der ersten Verbindung.

Verwenden Sie den installierten Pfad aus dem Paket statt eines illustrativen aus einer Anleitung kopierten. Auch die Berechtigungen zählen, denn der Hook läuft, nachdem die Privilegien abgefallen sind.

Ein Distributions-Resolver-Skript zu bearbeiten, um sein Ausgabeziel zu ändern, dokumentiert den Workaround eines einzelnen Hosts. Es ist keine allgemeine Reparatur.

Prüfung fünf: dasselbe Ergebnis nach einer Neuverbindung

Verbinden Sie sich neu und lesen Sie die Verknüpfung erneut. Eine Registrierung, die einmal erscheint und beim nächsten Übergang verschwindet, ist der Fehler, für den diese ganze Checkliste existiert. Testen Sie nach einem Suspend, nach einer erzwungenen Neuverbindung und nach einem Neustart des Resolver-Dienstes. Jeder Übergang prüft eine andere Annahme über die Reihenfolge.

Erst wenn alle fünf Prüfungen bei einer Neuverbindung bestehen, können Sie sagen, dass die übertragenen Einstellungen in Gebrauch sind. Alles Frühere ist eine Momentaufnahme eines glücklichen Moments.