Zwei VPNs, ein Resolver: Wer zuletzt schreibt, gewinnt

Zwei VPN-Clients sind verbunden, einer für die Arbeit und einer für ein Labornetz, und interne Namen werden nur für den Client aufgelöst, der zuletzt verbunden wurde. Dieses Muster sieht wie ein Fehler in einem der Clients aus. Meist ist es das vorhersehbare Ergebnis zweier Programme, die dieselbe Resolver-Konfiguration schreiben, ohne sich darüber zu einigen, wem welcher Name gehört.

Der Mythos: Das neueste VPN besitzt DNS

Es gibt keine allgemeine Regel, dass die neueste Verbindung gewinnt. Was passiert, hängt vom Mechanismus der Plattform und davon ab, wie jeder Client ihn schreibt. Ein Client, der eine Resolver-Datei ersetzt, erzeugt ein Ergebnis; ein Client, der pro Link eine Domäne hinzufügt, ein anderes; ein Client, der nichts tut, lässt den vorherigen Zustand unangetastet.

Das beobachtete Verhalten ist also eine Eigenschaft der beiden Implementierungen, keine dokumentierte Priorität. Wer allein aus der Startreihenfolge darauf schließt, liegt manchmal richtig und manchmal falsch, und zwar auf schwer reproduzierbare Weise. Schreiben Sie stattdessen die Zuordnung auf. Ein Design, das in zwei Clients lebt, ist kein Design.

Ordnen Sie Namensräume Resolvern zu

Listen Sie die privaten Suffixe und den Resolver auf, den jedes Netz benötigt, und entscheiden Sie dann, wohin öffentliche Namen gehen sollen. Diese Liste ist das Design. Ohne sie entscheiden die Clients versehentlich.

Eine Plattform, die DNS pro Link oder Routing-Domänen unterstützt, kann die Aufteilung bewusst ausdrücken: Eine Domäne geht an einen Link, eine andere an den anderen, und alles Übrige folgt einem ausdrücklichen Standard. Zwei flache Skripte, die dieselbe Datei überschreiben, können dieses Design nicht bewahren, weil jedes glaubt, die gesamte Konfiguration zu besitzen.

Unter Windows kann die Richtlinientabelle für Namensauflösung Suffixe an bestimmte Server leiten, und ein VPN-Client kann dort Regeln installieren. Prüfen Sie die Richtlinie statt der Adapterliste, denn nicht die Adapterliste löst den Namen auf.

Halten Sie einen Bootstrap-Pfad

Jeder Client muss seinen eigenen Endpunkt finden, bevor er den Dienst nutzen kann, den dieser Endpunkt bereitstellt. Wenn der Hostname des Endpunkts nur über den Tunnel aufgelöst werden kann und der Tunnel den aufgelösten Hostnamen braucht, haben Sie eine zirkuläre Abhängigkeit, die als Verbindungs-Zeitüberschreitung erscheint. Halten Sie einen Bootstrap-Pfad außerhalb beider Tunnel. Er kostet nichts bis zu dem Tag, an dem er die Verbindung rettet.

Betrachten Sie den Pfad zu jedem Resolver, nicht nur den dafür konfigurierten Namen. Ein Resolver, der nur über den anderen Tunnel erreichbar ist, verhält sich wie ein fehlender, und das Symptom ist eine Zeitüberschreitung statt eines Routing-Fehlers.

Überlappende Adressen sind kein DNS-Problem

Zwei private Netze mit demselben Adressbereich lassen sich nicht durch DNS-Reihenfolge reparieren. Wenn beide Tunnel 10.0.0.0/8 beanspruchen, verweist ein korrekt aufgelöster Name weiterhin auf eine Adresse, die der Host nicht in den richtigen Tunnel routen kann. Das braucht eine Lösung auf Adressebene, etwa getrennte Bereiche, einen Namensraum oder Übersetzung, nicht eine weitere Resolver-Einstellung. Diese Entscheidung früh zu treffen erspart einen langen Umweg über eine DNS-Konfiguration, die nie funktioniert hätte.

Vergleichen Sie die Adresszuweisungen beider Tunnel, bevor Sie die Namensauflösung beschuldigen. Wenn beide Seiten dasselbe Präfix pushen, behält der Host eine Route dafür, und ein über den zweiten Tunnel aufgelöster Name landet trotzdem auf einer Adresse, die der erste Tunnel besitzt. Getrennte Bereiche, ein Namensraum pro Netz oder Übersetzung sind die Korrekturen; prüfen Sie nach jeder Client-Verbindung, ob die Routentabelle den beabsichtigten Pfad zeigt.

Beweisen Sie es mit echten Anwendungen

Wählen Sie zwei Hosts, die nur in ihrem eigenen Namensraum existieren, und einen öffentlichen Namen und lösen Sie dann jeden über den Client auf, der ihn besitzen sollte. Eine korrekte Antwort vom erwarteten Resolver beweist nicht, dass die Anwendung den Host erreicht, denn die Route zu dieser Adresse kann weiterhin scheitern. Lassen Sie jedem Lookup einen Verbindungstest aus dem Programm folgen, das der Benutzer tatsächlich ausführen wird.

Ein Client mit eigener verschlüsselter DNS-Option kann die gerade geprüfte Richtlinie umgehen, prüfen Sie diese Einstellung daher als Teil der Durchsicht. Verbinden Sie dann beide Clients in der vom Anbieter unterstützten Reihenfolge erneut und wiederholen Sie die Lookups; wenn sich die Antworten beim Wechsel der Reihenfolge vertauschen, besitzt ein konkurrierender Schreiber noch einen Teil der Konfiguration. Finden Sie heraus, welche Komponente die Regel installiert - der Client, das Betriebssystemprofil oder ein Verwaltungsagent -, bevor Sie etwas ändern. Notieren Sie Reihenfolge und Eigentümer, damit die nächste Person sie nicht erneut entdecken muss.