VPN-Endpunktname versus Name eines privaten Dienstes: zwei Verantwortliche

Zwei Namen können denselben Standort beschreiben und völlig verschiedene Fragen beantworten. vpn.branch.example sagt einem entfernten Peer, wo der VPN-Endpunkt zu finden ist, und muss aufgelöst werden, bevor irgendein Tunnel existiert. inventory.branch.example sagt einem berechtigten Benutzer, wo eine private Anwendung liegt, und ist erst relevant, wenn der Tunnel steht. Die Pflege des einen bewirkt für den anderen nichts.

Benennen Sie beide Einträge, bevor Sie einen davon debuggen

Schreiben Sie beide mit ihren Verantwortlichen auf. Für den Endpunkt notieren Sie, wer die öffentliche Adresse aktualisiert und wie der VPN-Client seine Antwort erneuert. Für den Dienst notieren Sie, wem die private Adresse gehört, welche Zone den Eintrag hält und welche Resolver dafür antworten sollen.

Diese kurze Liste verhindert die häufigste Fehldiagnose in diesem Bereich: einen funktionierenden Standort-Tunnel neu zu starten, um einen Eintrag zu reparieren, der vollständig in ihm lebt. Der Tunnel ist der Transportweg für den Dienstnamen; er ist nicht dessen Autorität.

Wenn eine Änderung vorgeschlagen wird, fragen Sie, welchen der beiden Einträge sie berührt. Kann das niemand beantworten, ist die Änderung nicht planungsreif.

Der Endpunkt muss aufgelöst werden, bevor irgendein Tunnel existiert

Angenommen, die Internetverbindung des Standorts erhält eine neue öffentliche Adresse. Der Endpunkt-Aktualisierer veröffentlicht die neue Adresse, und die entfernte VPN-Implementierung muss die geänderte Antwort lesen können. Welcher Resolver diese Antwort auch liefert, er muss ohne den Tunnel erreichbar sein, sonst jagt der Client einem Namen nach, den er erst auflösen kann, nachdem er sich mit dem verbunden hat, was er nicht findet.

Diese Bootstrap-Abhängigkeit sollte man klar benennen, denn sie entsteht leicht versehentlich, wenn alle internen Resolver hinter dem VPN liegen. Halten Sie einen Pfad vor dem Tunnel für die Endpunkt-Abfrage bereit und bestätigen Sie das Wiederverbindungsverhalten des Clients, statt anzunehmen, eine neue Antwort werde sofort übernommen.

Auch dynamisches DNS hat Grenzen, die die Eintragsaktualisierung nicht überschreiten kann. Das Aktualisieren eines Eintrags öffnet keinen Firewall-Port, erzeugt keine NAT-Zuordnung und beweist keine Peer-Identität. Eine veröffentlichte Adresse mit geschlossenem Port ergibt einen Client, der korrekt auflöst und sich trotzdem mit nichts verbinden kann.

Schließlich kann ein laufender Client einen zwischengespeicherten Endpunkt weiterverwenden, bis er sich neu verbindet. Trennen Sie Veröffentlichung, Cache und Wiederverbindungsrichtlinie in Ihren Notizen, damit ein veralteter Peer nicht für einen defekten Aktualisierer gehalten wird.

Der Dienstname beschreibt, wo die Anwendung liegt

Nehmen Sie nun an, der Tunnel bleibt gesund, aber der Inventarserver wechselt von 172.26.14.20 zu 172.26.14.35. Der öffentliche Endpunkteintrag bleibt unberührt, während sich der private Diensteintrag ändern muss. Eine für diesen Dienst reservierte Adresse oder eine statische Zuweisung macht das seltener; ein berechtigter Aktualisierungspfad deckt die Fälle ab, in denen es beabsichtigt ist.

Hier werden zwei Aktualisierungsmechanismen vermengt. RFC 2136 definiert ein Protokoll zum Hinzufügen und Löschen von DNS-Einträgen in einer Zone, während ein kommerzieller Anbieter für dynamisches DNS eine völlig andere HTTP-API für einen anderen Zweck bereitstellen kann. Die Nutzung des einen bedeutet nicht, dass der andere in Ihrer Umgebung existiert. Prüfen Sie, welchen Mechanismus Ihre Zone tatsächlich akzeptiert, bevor Sie einen Aktualisierer dagegen schreiben.

Eine korrekte private Antwort ist nur die erste Bedingung. Damit ein entfernter Aufrufer sie nutzen kann, braucht der Client einen Resolver, der die private Zone führt, eine Richtlinie, die Abfragen an diesen Resolver erlaubt, und Weiterleitung für die Adresse, die zurückkommt. Ein Name, der auf eine für den Client unerreichbare Adresse auflöst, erzeugt eine Zeitüberschreitung, die wie ein Serverfehler aussieht.

Testen Sie die beiden Pfade getrennt

Prüfen Sie den Endpunkt von außerhalb des Tunnels und den Dienst von innen, und halten Sie die Ergebnisse als zwei unabhängige Fakten fest:

$ dig +short vpn.branch.example @1.1.1.1
$ dig +short inventory.branch.example @172.26.0.53
$ ip route get 172.26.14.35

Schlägt die erste Abfrage fehl, liegt das Problem in der öffentlichen Veröffentlichung oder im Auflösungspfad vor dem Tunnel, und keine interne Änderung hilft. Liefert die zweite eine Adresse, zeigt die dritte aber keine Route durch den Tunnel, ist die DNS-Ebene in Ordnung und die Weiterleitungsrichtlinie nicht.

Führen Sie das Paar nach jeder Adressänderung aus und notieren Sie, welcher Eintrag sich bewegt hat. Eine Übergabe, die nur sagt „DNS wurde aktualisiert“, lässt den nächsten Ingenieur raten, welcher der beiden Lebenszyklen tatsächlich gelaufen ist.