Split-DNS und VPN: Domänenregeln sind keine IP-Routen

Ihr Laptop löst intranet.corp über den Tunnel auf, während gitlab.com weiterhin zum Resolver des Providers geht, und das ist die Anordnung, die wie entworfen funktioniert. Zwei getrennte Entscheidungen haben sie erzeugt: Eine Namensabgleichsregel wählte den Resolver, und eine Route trug die Antwort zurück. Bricht man eine der beiden, zeigt der Browser einen Fehler, der von außen gleich aussieht. Die meisten Berichte über Split-DNS beschreiben den zweiten Fehler und zitieren dabei Belege für den ersten.

Die beiden Hälften leben an verschiedenen Orten und werden meist von verschiedenen Personen bearbeitet. Die eine ist eine DNS-Richtlinie am VPN-Profil, die andere eine Route, die der Tunnel installiert oder zurückhält. Die Fehlersuche stockt, wenn niemand feststellt, welche Hälfte sich tatsächlich bewegt hat.

Zwei Entscheidungen in einer Anfrage

Die Namenshälfte ist ein Richtlinienobjekt, keine Route. Unter Windows ist es eine Namensauflösungsrichtlinie am VPN-Profil; auf Apple-Plattformen eine Menge von Abgleichsdomänen an einem DNS-Einstellungsobjekt; unter Linux eine Routingdomäne, eine Split-Resolver-Zeile oder die Reihenfolge des Namensdienst-Umschalters. Die Pfadhälfte ist gewöhnliches Routing, vom Tunnel oder von Hand installiert, und sie weiß nicht, was ein Hostname ist. Ein Profil, das ein Suffix zulässt, entscheidet nur, wer antwortet; es macht die Antwort nie erreichbar.

Ein schneller Symptomtest trennt sie: Ersetzen Sie den Namen durch eine Adresse. Funktioniert die Adresse, ist der Pfad in Ordnung und die Regel falsch. Schlägt auch die Adresse fehl, kann die Regel richtig sein und der Pfad fehlen.

Wie jede Plattform dieselbe Namensregel ausdrückt

Die Absicht ist identisch, die Feldnamen nicht. Ein von einem Client in einen anderen kopiertes Beispiel wird sauber geparst und trifft nie zu. Die drei Formen sehen so aus:

Eine Abgleichs- oder Routingdomäne ist ein Suffixtest, daher deckt intranet.corp git.intranet.corp ab und nicht corp.intranet, und das Umzudrehen ist der häufigste Fehler in der gesamten Einrichtung. Windows trägt die Zuordnung als Namensauflösungsrichtlinie am Profil, mit eigener Prioritätsreihenfolge gegenüber der Suffixliste, die die Schnittstelle bereits hatte. Apple-Plattformen hängen Abgleichsdomänen an das DNS-Einstellungsobjekt der Netzwerkerweiterung, und das System wendet sie je abgegrenztem Resolver an. Keine dieser Formen ist eine Route, und keine kann eine unerreichbare Adresse erreichbar machen. Die Referenz Windows-Namensauflösungsrichtlinie listet die Feldnamen und Prioritätsregeln für diese Plattform, und es sind nicht die der Apple- oder systemd-Dokumente.

Eine richtige Antwort braucht noch einen Pfad

Eine Resolver-Antwort ist nur eine Adresse, und die Anwendung muss sie noch erreichen. Ein Split-Tunnel-Design schiebt häufig 10.20.0.0/16 und hält die Standardroute zurück, sodass der interne Name aufgelöst wird und die Verbindung dann hängt. Der umgekehrte Fall ist genauso häufig: Die Route existiert, ein öffentlicher Resolver beantwortet den privaten Namen mit NXDOMAIN, und der Fehler wird als Routingproblem abgelegt. Wer zuerst den Pfad testet, starrt auf Routen für einen Namen, der nie aufgelöst worden wäre.

Es gibt auch ein drittes Tor, das keine der Hälften abdeckt. Eine ACL am Gateway, eine Firewallregel oder eine Client-Richtlinie kann die Verbindung verwerfen, nachdem beide Entscheidungen richtig waren. Wenn der Name aufgelöst wird, die Route existiert und die Verbindung trotzdem ausläuft, hören Sie auf, DNS zu testen.

Namen und Pfade in fester Reihenfolge testen

Wählen Sie eine Reihenfolge und halten Sie sie ein, sonst jagen Sie dem Schritt nach, der zuletzt fehlschlug. Lösen Sie den dokumentierten vollständigen internen Namen auf, bestätigen Sie, dass die Antwort eine Adresse ist, die die Routentabelle tragen kann, und wiederholen Sie es dann mit einem öffentlichen Namen, um zu beweisen, dass der Tunnel nicht alles eingefangen hat. Auf einem systemd-Host liegen die Abfrage und die Routingdomäne des Resolvers einen Befehl auseinander:

resolvectl query intranet.corp
resolvectl domain
ip route get 10.20.5.10

Ein Windows-Client stellt dieselben zwei Fragen mit anderen Cmdlets. Die zweite meldet die Schnittstelle, die das System tatsächlich verwenden würde:

Resolve-DnsName intranet.corp -Type A
Find-NetRoute -RemoteIPAddress 10.20.5.10

Wenn die Abfrage eine Adresse zurückgibt und die Pfadprüfung die physische Schnittstelle nennt, hat die Namensregel gewirkt und die Route nicht. Wenn der kurze Name fehlschlägt, während der vollständige aufgelöst wird, ist die Suffixliste falsch und nicht der Resolver.

Wo der Vergleich meistens schiefgeht

Der erste Fehler ist, einen unabhängigen öffentlichen Resolver nach einem privaten Namen zu fragen und die Ablehnung als Beleg über das VPN zu lesen. Der zweite ist anzunehmen, dass eine funktionierende öffentliche Abfrage den Resolverpfad des Tunnels beweist. Der dritte ist, Split-Tunneling und Split-DNS als eine Designentscheidung zu behandeln, obwohl ein Einsatz in dem einen richtig und in dem anderen kaputt sein kann. Jeder Fehler liefert sichere Schlussfolgerungen aus einem Test, der den beschuldigten Teil nie geübt hat.

Ein Browser mit eigenem sicheren DNS kann die Systemregel ebenfalls umgehen, weshalb es kein Widerspruch ist, wenn ein Browser scheitert und ein anderer gelingt. Vergleichen Sie den Resolver, der geantwortet hat, nicht den Browser, der sich beschwert hat.

Sobald beide Hälften sichtbar sind, ist die verbleibende Frage eine Richtlinienfrage und keine technische: Welche Namensräume gehören der Organisation, wem gehört jede Antwort, und welche davon sollten die Maschine überhaupt verlassen. Schreiben Sie das neben das Profil, denn die nächste Person, die die Regel anfasst, wird es brauchen.