Warum ein privater Endpunkt weiterhin mit einer öffentlichen Adresse antwortet

Der Laptop verbindet, der Tunnel meldet sich als aktiv, und das Speicherkonto lehnt weiterhin jede Anfrage ab. Der private Endpunkt existiert, die Route zu seinem Subnetz existiert, und der Name antwortet entweder mit einer öffentlichen Adresse oder lässt sich nicht auflösen. Am Tunnel ist nichts falsch: Dem Client wurde nie mitgeteilt, welcher Server für diesen Namen antworten soll. Folgen Sie der Abfrage nach außen, und die Lücke wird offensichtlich.

Beginnen Sie beim Resolver des Clients

Fragen Sie den Client, welchen Server er abfragt, während der Tunnel aktiv ist. Ein Punkt-zu-Standort-Profil liefert diese Adresse, und ein Profil, das nichts liefert, überlässt es dem Betriebssystem, auf die Standardwerte des Adapters zurückzugreifen.

Öffentliche Resolver haben keine Sicht auf eine private Zone und antworten daher aus dem Internet, was genau ihre Aufgabe ist. Die erste Prüfung ist deshalb die verwendete Resolver-Adresse, nicht der Tunnel und nicht der Endpunkt.

Lesen Sie, was die Antwort tatsächlich ist

Lösen Sie den Dienstnamen auf, und lesen Sie die zurückkommende Adresse. Eine öffentliche Antwort bedeutet, dass die Abfrage einen Server erreicht hat, der die Zone nicht sehen kann. Keine Antwort bedeutet, dass der Name nur privat existiert und nichts, was der Client erreichen kann, ihn hält.

Diese beiden Ergebnisse erzeugen ähnliche Anwendungsfehler und gehören zu unterschiedlichen Zuständigkeiten. Das eine ist ein Problem der Resolver-Auswahl, das andere ein fehlender Zonen-Link.

Ein hosts-Eintrag beweist den Pfad und lügt dann

Die Endpunktadresse in die lokale hosts-Datei einzutragen ist der schnellste Weg zu beweisen, dass Tunnel und Dienst-Firewall bereits funktionieren. Wenn die Anfrage mit diesem Eintrag gelingt, ist nur die Namensauflösung defekt. Es ist außerdem eine Änderung pro Rechner, die genau einen Namen abdeckt.

Sie hilft nicht dem zweiten Konto, dem zweiten Endpunkt oder einem Kollegen, und sie bricht ohne Warnung, wenn der Endpunkt unter einer neuen Adresse neu erstellt wird.

Schlimmer noch, sie lässt Ihren Rechner sich anders verhalten als alle anderen, und so überlebt ein Resolver-Fehler eine Woche Untersuchung. Nutzen Sie sie, um den Pfad zu bestätigen, entfernen Sie sie dann und beheben Sie die Ursache.

Verknüpfen Sie die Zone und geben Sie einen Resolver aus

Zwei Bedingungen müssen gleichzeitig gelten. Die private Zone muss mit dem virtuellen Netzwerk verknüpft sein, in dem der Endpunkt liegt, und der Client muss seine Abfragen an einen Server senden, der diese Zone lesen kann. Ein eingehender Endpunkt des DNS Private Resolver stellt eine solche Adresse innerhalb des Netzwerks bereit und beantwortet Abfragen, die über den Tunnel eintreffen. Tragen Sie diese Adresse im VPN-Profil ein, und fügen Sie das private Suffix hinzu, das der Client anwenden soll.

Ein bereits vorhandener lokaler Resolver kann dasselbe Ergebnis über einen bedingten Weiterleiter, der auf die Zone zeigt, erreichen.

Netzwerkregeln am Resolver zählen ebenso viel wie das Routing. Wenn die eingehende Regel den Bereich der VPN-Clients ausschließt, laufen Abfragen in einen Timeout statt eine falsche Antwort zu liefern. Genau dieser Timeout schickt Leute zu einer Routentabelle zurück, in der nichts falsch ist.

Prüfen Sie Name, Port und Identität in dieser Reihenfolge

Arbeiten Sie der Reihe nach: Name auflösen, private Antwort bestätigen, Port öffnen, dann eine authentifizierte Anfrage stellen. Jede Stufe hat ihren eigenen Zuständigen und ihre eigene Fehlersignatur.

Eine private Antwort, gefolgt von einem Timeout, deutet auf eine Route oder eine Firewall. Eine öffentliche Antwort deutet auf den Resolver. Eine abgeschlossene Verbindung, die einen Identitätsfehler zurückgibt, gehört zum Dienst.

Ein weiterer Fehler gehört auf diese Liste. Eine Dienst-Firewall, die eine Client-Adresse zulässt, passt nicht mehr, wenn der Pool diese Adresse nach einer erneuten Verbindung an eine andere Sitzung vergibt. Lesen Sie die aufgerufene Adresse, die der Dienst aufgezeichnet hat, statt der, die der Client zu haben glaubt. Die beiden widersprechen sich häufiger, als Menschen erwarten. Die Azure DNS Private Resolver-Dokumentation behandelt die Zonen-Verknüpfung und die Weiterleitungsanordnung.