Wo bleiben die Azure-Point-to-Site-VPN-Protokolle? Im Monitor nachsehen

Ein Benutzer kann keine Verbindung zum Point-to-Site-Gateway aufbauen, Sie öffnen das Gateway-Blade, und nirgends auf der Seite findet sich ein Verbindungsverlauf. Konfiguration, Zertifikate, Status: alles vorhanden, keine Datensätze. Die Protokolle existieren, aber sie werden keineswegs von den Netzwerkseiten erzeugt. Sie stammen aus einer Diagnoseeinstellung, die an die Gateway-Ressource angehängt ist, und diese Einstellung liegt unter Monitor; deshalb liefert die erste Suche an der naheliegenden Stelle nichts, und man schließt daraus, dass der Dienst kein Prüfprotokoll führt.

Warum die naheliegende Suche scheitert

Ältere Anleitungen behaupten, Azure-Point-to-Site-VPN habe keine Überwachung, und das stimmte, als der Dienst noch keinen Datensatz pro Verbindung bereitstellte. Aktuelle Gateways veröffentlichen Tunnel-Diagnosedatensätze, daher hat sich die sinnvolle Frage geändert: nicht ob Protokolle existieren, sondern welche Ressource sie ausgibt und welche Kategorie Sie aktiviert haben. Das Gateway-Blade ist eine Konfigurationsoberfläche, und Konfigurationsoberflächen dienen selten zugleich als Protokollanzeige. Eine Diagnoseeinstellung ist ein Objekt pro Ressource, daher bestimmt die gewählte Ressource alles Weitere.

Die andere Hälfte der Verwirrung betrifft die Authentifizierung. Zertifikatsbasierte Point-to-Site-Verbindungen erzeugen kein Anmeldeereignis pro Benutzer wie ein Identitätsanbieter, daher gibt es keinen Datensatz über eine namentlich bekannte Person, die ein Kennwort eingibt.

Die Diagnoseeinstellung an die Gateway-Ressource hängen

Öffnen Sie Monitor, dann Diagnoseeinstellungen, und fügen Sie eine neue Einstellung hinzu, deren Ziel das virtuelle Netzwerkgateway selbst ist und nicht das virtuelle Netzwerk, das es enthält. Wählen Sie die Point-to-Site-Diagnosekategorie, die den Namen P2SDiagnosticLog trägt, denn sie enthält die Verbindungsdatensätze pro Client; fügen Sie die Kategorien Tunnel, Route oder IKE nur für die Site-to-Site-Fehler hinzu, die sie abdecken. Senden Sie die Daten dann an einen Log Analytics-Arbeitsbereich, den Sie kontrollieren, mit einer Aufbewahrungsfrist, die Sie bewusst gewählt haben. Die meisten erfolglosen Suchen beruhen auf einer Einstellung, die an die falsche Ressource gehängt wurde, nicht auf einer fehlenden Funktion.

Die Kategorielisten unterscheiden sich je nach Gateway-Typ und Generation. Fehlt die Point-to-Site-Kategorie, ist das Gateway möglicherweise älter als die Funktion oder läuft mit einer SKU, die sie nie ausgibt; prüfen Sie daher die unterstützten Kategorien, bevor Sie ein Berechtigungsproblem suchen. Ein Gateway ohne Point-to-Site-Kategorie ist nicht defekt; es kann schlicht nicht die Quelle dieses Datensatzes sein, und der nächste Ersatz ist die Kategorie Tunnel oder IKE, die die Client-Adresse erfasst, auch wenn sie keine Point-to-Site-Sitzung beschreibt. Bestätigen Sie die Kategorieliste, bevor Sie einen Supportfall zu fehlenden Protokollen eröffnen.

Die Datensätze in der Tabelle lesen, die Ihr Modus verwendet

Im älteren Erfassungsmodus landen die Einträge in der Tabelle AzureDiagnostics, und die Kategorie erscheint als Spaltenwert; bei ressourcenspezifischen Tabellen hat das Gateway eine eigene Tabelle. Fragen Sie in beiden Fällen nach der Gateway-Ressource und einem Zeitfenster um den fehlgeschlagenen Versuch, und lesen Sie dann die Korrelation statt der einzelnen Zeilen:

AzureDiagnostics
| where ResourceType == "VIRTUALNETWORKGATEWAYS"
| where _ResourceId has "gateway-name"
| where TimeGenerated > ago(2h)
| project TimeGenerated, Category, OperationName, ResultType, ResultDescription
| order by TimeGenerated desc

Die Spaltenauswahl richtet sich nach Ihrem Erfassungsmodus, betrachten Sie die Abfrage daher als Form und nicht als Skript. Sie suchen eine Client-Adresse, die auftaucht und dann verschwindet, mit einem Ergebnistyp, der nicht Erfolg lautet.

Den Gateway-Datensatz mit der Sicht des Clients abgleichen

Gateway-Protokolle beschreiben den Tunnel, nicht warum ein Laptop keinen aufbauen konnte. Erfassen Sie die Client-Seite zum selben Zeitstempel: das Windows-Ereignisprotokoll für den RAS-Client, das macOS-Verbindungsprotokoll oder den Fehlertext, den die Client-App angezeigt hat. Ein Gateway-Datensatz ohne passenden Client-Versuch deutet auf den Client hin; meldet ein Client Erfolg, während das Gateway nichts erfasst, zielt das Profil meist auf ein anderes Gateway.

Halten Sie beide Hälften im selben Ticket fest. Ein Gateway-Protokoll allein verleitet zu einem falschen Schluss, und ein Client-Protokoll allein kann nicht zeigen, ob das Paket je ankam.

Erscheint an keiner der beiden Stellen etwas, prüfen Sie die Uhr des Clients, bevor Sie die Plattform anzweifeln. Verzerrte Zeitstempel lassen die Korrelation so scheitern, dass es genau wie fehlende Daten aussieht.

Aufbewahrung, Umfang und der Eintrag im Runbook

Tunnel-Datensätze enthalten Client-Adressen und Verbindungszeitstempel, behandeln Sie sie daher als personenbezogene Daten mit einem Löschplan, statt die Standardeinstellung der Plattform zu belassen. Prüfen Sie außerdem, ob der Arbeitsbereich nicht jede Kategorie von jeder Ressource im Abonnement aufnimmt, denn ein übervoller Arbeitsbereich macht die Korrelation langsamer, als das Client-Protokoll direkt zu lesen.

Schreiben Sie schließlich den Namen der Einstellung, den Arbeitsbereich und die gewählten Kategorien in das Runbook des Gateways. Die nächste Person, die einen Client debuggt, schaut zuerst in das Gateway-Blade, findet nichts und schließt daraus, dass es keine Protokolle gibt.