Split-DNS über OpenVPN: Was eine Routing-Domain auf jedem Betriebssystem leisten muss

Jede Split-DNS-Anfrage beginnt mit demselben Satz: Firmennamen gehen an das Firmen-DNS, alles andere funktioniert weiter. Diesen Satz in eine Konfiguration zu übersetzen heißt, pro Betriebssystem drei Fragen zu beantworten, und die Antworten nutzen auf jedem System andere Mechanismen. Profile, die auf einem Linux-Laptop funktionieren, scheitern unter Windows oft aus Gründen, die nichts mit dem Tunnel zu tun haben. Die Lücke ist meist eine Resolver-Einstellung, die für eine Route gehalten wird.

Benennen Sie zuerst die Richtlinie und wählen Sie dann das Plattform-Primitiv, das sie ausdrückt.

Drei Einstellungen, die leicht zu verwechseln sind

Ein Suchsuffix erweitert einen kurzen Namen: Aus files wird files.corp.example, wenn der Resolver Suffixe der Reihe nach probiert. Eine Routing-Domain wählt aus, welcher Resolver Abfragen innerhalb eines Namensraums beantwortet. Eine IP-Route macht den gewählten Resolver nur erreichbar. Diese drei leben in unterschiedlichen Schichten, und das eine durch das andere zu ersetzen erzeugt eine Konfiguration, die richtig aussieht und nichts auflöst.

Die Verwechslung hat einen Preis: Ein Suchsuffix schickt jeden kurzen Namen an den Firmen-Resolver, auch Namen, die woanders hingehören. Eine Routing-Domain hält fremde Abfragen beim lokalen Resolver und schickt *.corp.example trotzdem durch den Tunnel.

Linux: eine reine Routing-Domain, kein Suchsuffix

Bei systemd-resolved ist eine Domain mit vorangestellter Tilde eine reine Routing-Domain: Abfragen für diesen Namensraum gehen an den verknüpften Resolver, ohne zugleich zu einem Suchsuffix zu werden. resolvectl domain tun0 '~corp.example' setzt das, und resolvectl dns tun0 10.8.0.1 benennt den Server. Beide Einstellungen gehören zur Schnittstelle und verschwinden mit ihr. Die Tilde ist der Teil, den viele weglassen, und ohne sie werden kurze Namen über den Firmen-Resolver aufgelöst.

Installieren Sie dieselbe Domain nicht zusätzlich als globales Suchsuffix. Die beiden Einstellungen sind nicht redundant; die eine routet, die andere schreibt um, was Sie getippt haben.

Windows braucht eine Namensraum-Richtlinie, kein Suffix

Windows hält die Split-DNS-Richtlinie in der Name Resolution Policy Table, nicht im DNS-Suffix des Adapters. Eine Regel ordnet einen Namensraum bestimmten Servern zu: Add-DnsClientNrptRule -Namespace .corp.example -NameServers 10.8.0.1. Nur das Suffix zu setzen ändert das Aussehen kurzer Namen; es leitet die Abfrage nicht an einen anderen Server.

Prüfen Sie die wirksame Richtlinie nach dem Verbinden mit Get-DnsClientNrptPolicy, denn eine Regel aus einer früheren Verbindung kann den Tunnel überleben. Entfernen Sie Regeln nach Namen, wenn der Tunnel abbaut, und halten Sie den Anzeigenamen stabil, damit die Bereinigung den richtigen Eintrag trifft.

Halten Sie pro Plattform einen Resolver-Eigentümer

Ein Desktop-Manager, ein OpenVPN-up-Skript und ein lokaler Resolver-Daemon können alle versuchen, dieselbe Konfiguration zu schreiben. Wenn sie sich uneinig sind, gewinnt der letzte Schreiber, und das Ergebnis hängt von der Abbau-Reihenfolge ab. Wählen Sie eine Komponente, die den Resolver-Zustand besitzt, lassen Sie die anderen berichten statt schreiben und testen Sie ein erneutes Verbinden: Die Richtlinie sollte es ohne doppelte Regeln überstehen. Testen Sie auch ein Trennen, denn übrig gebliebener Zustand ist das, was die nächste Verbindung anders verhalten lässt.

Anwendungen, die einen eigenen verschlüsselten Resolver mitbringen, ignorieren die Richtlinie des Betriebssystems vollständig. Das ist eine Eigenschaft der Anwendung, kein Defekt des Tunnels.

Prüfen Sie das Ergebnis, nicht den Profiltext

Lösen Sie auf jeder Plattform einen Namen auf, der durch den Tunnel gehen soll, und einen, der nicht soll, und bestätigen Sie, welcher Server geantwortet hat. resolvectl query host.corp.example und Resolve-DnsName host.corp.example melden beide den Server, der geantwortet hat. Wiederholen Sie das nach einem erneuten Verbinden. Bestätigen Sie dann, dass der Resolver des Tunnels unter der vom Profil vorgegebenen Adresse erreichbar ist, denn eine korrekte Richtlinie, die auf einen unerreichbaren Server zeigt, scheitert genauso wie gar keine Richtlinie.

Halten Sie das beabsichtigte Verhalten in den Notizen des Profils fest: welches Suffix geroutet wird, welcher Server es beantwortet und was mit allem anderen geschieht. Die nächste Plattform, die Sie unterstützen, braucht diesen Satz mehr als die Konfigurationsdatei.