Azure P2S VPN kann einen privaten Endpunktnamen nicht auflösen

Sie verbinden den Punkt-zu-Standort-Tunnel, pingen die private Adresse, öffnen die App und bekommen stattdessen einen 403 oder einen Zertifikatfehler. Beide Symptome deuten auf DNS, sind aber verschiedene Fehler: Der eine bedeutet, der Client hat die öffentliche Adresse aufgelöst, der andere, er hat die private Adresse aufgelöst und dann einen Namen angeboten, den das Zertifikat nicht abdeckt. Arbeiten Sie die Prüfungen unten der Reihe nach ab und halten Sie beim ersten Fehlschlag an, denn ein hosts-Eintrag oder eine gecachte Antwort kann jede spätere Prüfung aus dem falschen Grund bestehen lassen. Ich halte diese Reihenfolge in einer Textdatei neben meinen VPN-Profilen fest, weil die Korrektur nichts am Tunnel ändert und alles daran, was der Client weiß.

Beginnen Sie mit der Adresse, die der Client tatsächlich bekommt

Fragen Sie den Resolver direkt, statt der Anwendung zu vertrauen. Unter Windows zeigt nslookup adminuidev-fedqcubyd9bfb2bq.canadacentral-01.azurewebsites.net, welche Sicht der Client erhalten hat. Eine öffentliche Antwort bedeutet, dass nichts weiter unten den Endpunkt erreichen wird; die private Adresse des Endpunkts bedeutet, dass DNS erledigt ist und die nächste Prüfung die Verbindung selbst ist.

Ein privater Endpunkt benennt den Dienst nicht um. Das Konto oder die App behält ihren gewohnten vollqualifizierten Namen, und der Endpunkt ändert nur die Adresse, zu der dieser Name für Clients innerhalb des virtuellen Netzwerks aufgelöst wird. Deshalb wird derselbe Hostname von einer VM im Netzwerk privat und von einem Laptop, der die private Sicht nie bekommen hat, öffentlich aufgelöst.

Prüfen Sie Zone, Verknüpfung und Eintrag vor dem Tunnel

Drei Bedingungen müssen zusammen gelten: Die private Zone existiert, sie ist mit dem virtuellen Netzwerk verknüpft, in das das VPN-Gateway und die Clients nach Azure gelangen, und sie enthält einen A-Eintrag für den Endpunkt, der auf die private Adresse zeigt. Verknüpfen Sie die Zone mit einem fremden Netzwerk, löst das Gateway weiter den öffentlichen Eintrag auf, während am Tunnel alles gesund aussieht.

Zonennamen gehören zu Diensten, nicht allgemein zu privaten Links. App Service nutzt normalerweise privatelink.azurewebsites.net, Speicher und SQL haben eigene Namespaces, und eine Zone eines anderen Dienstes auszuleihen erzeugt eine Zone, die existiert und nichts Nützliches beantwortet.

Geben Sie dem Client einen Resolver, den er wirklich erreicht

168.63.129.16 antwortet von virtuellen Azure-Maschinen und ist kein DNS-Server für einen Laptop auf der anderen Seite eines Punkt-zu-Standort-Tunnels. Der Client braucht einen über den Tunnel erreichbaren Resolver: einen eingehenden Endpunkt des Azure DNS Private Resolver, einen Weiterleiter innerhalb des virtuellen Netzwerks oder DNS-Server-Einträge, die im VPN-Clientprofil mitgeführt werden, damit der Client das virtuelle Netzwerk direkt fragt.

Ein konfigurierter, aber unerreichbarer Resolver verhält sich genau wie kein Resolver, und das Symptom ist ein Timeout statt einer falschen Antwort, weshalb es als Firewallproblem missdeutet wird. Testen Sie ihn mit einer Abfrage, die der Tunnel tragen soll, nicht mit einem öffentlichen Namen, der über die lokale Verbindung ohnehin geklappt hätte.

Wenn Sie weiterleiten statt Einstellungen zu pushen, leiten Sie den Namespace weiter, den die private Zone besitzt, privatelink.azurewebsites.net statt des ganzen azurewebsites.net. Ein bedingter Weiterleiter, der das gesamte übergeordnete Suffix verschluckt, schickt jede Suche für den Dienst nach Azure, auch die, die lokal bleiben sollten.

Verwenden Sie den Namen, für den das Zertifikat ausgestellt wurde

Sobald die Adresse stimmt, zeigt sich der zweite Fehler. Speicher und App Service veröffentlichen einen privatelink-Alias, und dieser Alias ist nicht zwangsläufig der Name im Zertifikat. Ein AzCopy-Upload an privatelink.blob.core.windows.net scheiterte an der Validierung; derselbe Upload an <account>.blob.core.windows.net/<container> wurde auf die private Adresse aufgelöst und ging durch, blieb also ohne Umgehung auf dem privaten Pfad.

Die Regel gilt im Browser und auch für App Service: Verbinden Sie sich mit dem Hostnamen, den das Zertifikat abdeckt, und lassen Sie DNS die private Adresse liefern. Greifen Sie nicht zu einer Validierungsumgehung, denn sie macht aus einem Benennungsfehler eine Sicherheitsregression. Ein erfolgreicher Ping beweist die Route und sagt nichts über den Namen im Handshake, deshalb bleiben das getrennte Prüfungen.

Eine Reihenfolge in vier Schritten, die jede Schicht isoliert

1. Bestätigen Sie, dass der VPN-Client eine Adresse aus dem Punkt-zu-Standort-Pool und eine Route zur privaten Adresse des Endpunkts hat.
2. Lösen Sie den exakten Namen auf, den die Anwendung verwendet, und vergleichen Sie die Antwort mit der Adresse des Endpunkts.
3. Öffnen Sie eine TCP-Verbindung zum Endpunkt auf dem Dienstport und lesen Sie dann den Zertifikatnamen, der auf dieser Verbindung präsentiert wird.
4. Testen Sie erst jetzt die Autorisierung, denn ein funktionierender Pfad und ein gültiges Zertifikat gewähren noch keinen Zugriff auf die Ressource.

Eine abgelehnte Verbindung bei korrekter Adresse deutet auf die Netzwerksicherheitsgruppe oder den Verbindungszustand des privaten Endpunkts, nicht auf DNS, also prüfen Sie diese, bevor Sie die Resolver-Einstellungen erneut bearbeiten. Eine TLS-Namensabweichung schickt Sie zurück zum Hostnamen in der URL und zum Subject des Zertifikats. Halten Sie Auflösungsausgabe, Zertifikatname und die exakte URL zusammen; diese drei Werte erklären die meisten dieser Fälle, ohne das Gateway anzufassen.

Nutzen Sie eine VM im virtuellen Netzwerk als Kontrolle. Wird der Name dort privat und über den Tunnel öffentlich aufgelöst, sind Zone und Eintrag korrekt, und der einzige Unterschied ist der Resolverpfad des Clients, was schneller zu bestätigen ist als ein weiterer Durchgang durch die Endpunktkonfiguration.

Auch Clients cachen. Ein Eintrag, der vor zehn Minuten öffentlich geantwortet hat, antwortet weiter, nachdem Sie die Zone korrigiert haben, also leeren Sie den Cache vor dem erneuten Test. Unter Windows räumt ipconfig /flushdns den Client-Cache auf; Regeln zur Namensauflösungsrichtlinie bleiben bestehen, entscheiden, welches Suffix zu welchem Server geht, und können den Namespace weiter an den Resolver schicken, den Sie gerade ersetzt haben.

Wohin ein hosts-Eintrag gehört

Die Adresse des Endpunkts in eine hosts-Datei einzutragen ist eine gute Diagnose und ein schlechtes Design. Es beweist, dass die Zuordnung von Name zu Adresse das fehlende Teil ist, und lässt Sie alles danach testen, aber es ist für Ihre Nutzer unsichtbar, bricht, wenn sich die Adresse des Endpunkts ändert, und verdeckt die Zone, die eigentlich antworten sollte.

Ein zurückgebliebener Testeintrag ist schlimmer als ein veralteter Cache, denn er kann den reparierten Pfad kaputt oder den kaputten Pfad repariert aussehen lassen, je nach Richtung des Fehlers. Entfernen Sie ihn vor dem letzten Durchlauf und lösen Sie nur mit dem Produktionsresolver auf.

Kurze Namen brauchen ein Suchsuffix, vollqualifizierte nicht, also testen Sie zuerst den vollqualifizierten Namen und entscheiden Sie dann, ob der Workflow ein Suffix braucht, das über das Clientprofil gepusht wird. Microsoft dokumentiert die Zonennamen und Eintragsformen je Dienst in seinen Hinweisen zu DNS für private Endpunkte; lesen Sie den Eintrag für Ihren Dienst, statt eine Zone von einem anderen zu kopieren.