Problembehandlung bei Azure VPN Gateway mithilfe von Diagnoseprotokollen
In diesem Artikel werden die für die VPN Gateway-Diagnose verfügbaren Protokolle beschrieben, und es wird erläutert, wie diese zur effizienten Problembehandlung von VPN Gateway-Problemen verwendet werden.
Besuchen Sie die Azure-Foren von Microsoft Q&A und Stack Overflow, falls Sie Ihr Azure-Problem mit diesem Artikel nicht beheben konnten. Sie können Ihr Problem in diesen Foren oder an @AzureSupport auf Twitter posten. Sie können auch eine Azure-Supportanfrage senden. Wenn Sie eine Supportanfrage senden möchten, wählen Sie auf der Azure-Support-Seite die Option Support erhalten aus.
Die folgenden Protokolle sind in Azure verfügbar*:
Name | Beschreibung |
---|---|
GatewayDiagnosticLog | Enthält Diagnoseprotokolle für Konfigurationsereignisse, wichtige Änderungen und Wartungsereignisse, die das Gateway betreffen. |
TunnelDiagnosticLog | Enthält Ereignisse, die die Änderung des Tunnelzustands betreffen. Ereignisse im Zusammenhang mit der Herstellung und Trennung der Tunnelverbindung beinhalten ggf. eine Zusammenfassung, in der die Ursache der Zustandsänderung beschrieben wird. |
RouteDiagnosticLog | Enthält Änderungen an statische Routen und BGP-Ereignisse, die am Gateway auftreten. |
IKEDiagnosticLog | Enthält IKE-Kontrollnachrichten und -ereignisse, die am Gateway erfasst werden. |
P2SDiagnosticLog | Enthält Point-to-Site-Kontrollnachrichten und -ereignisse, die am Gateway erfasst werden. |
*Für richtlinienbasierte Gateways sind nur GatewayDiagnosticLog und RouteDiagnosticLog verfügbar.
Beachten Sie, dass in diesen Tabellen mehrere Spalten verfügbar sind. In diesem Artikel werden jedoch nur die wichtigsten dargestellt, um die Protokolliernutzung zu erleichtern.
Einrichten der Protokollierung
Führen Sie dieses Verfahren aus, um zu erfahren, wie Sie Diagnoseprotokollereignisse von Azure VPN Gateway mithilfe von Azure Log Analytics einrichten:
Erstellen Sie anhand der Informationen in diesem Artikel einen Log Analytics-Arbeitsbereich.
Suchen Sie Ihr VPN Gateway auf dem Blatt „Überwachung“ > „Diagnoseeinstellungen“.
- Wählen Sie das Gateway aus, und klicken Sie auf „Diagnoseeinstellung hinzufügen“.
- Geben Sie den Namen der Diagnoseeinstellung ein, wählen Sie alle Protokollkategorien aus, und wählen Sie den Log Analytics-Arbeitsbereich aus.
Hinweis
Es kann einige Stunden dauern, bis die Daten erstmalig angezeigt werden.
GatewayDiagnosticLog
Konfigurationsänderungen werden in der Tabelle GatewayDiagnosticLog überwacht. Es kann einige Minuten dauern, bis die von Ihnen vorgenommen Änderungen in den Protokollen angezeigt werden.
Im Folgenden ist eine Beispielabfrage als Referenz dargestellt.
AzureDiagnostics
| where Category == "GatewayDiagnosticLog"
| project TimeGenerated, OperationName, Message, Resource, ResourceGroup
| sort by TimeGenerated asc
Diese Abfrage für GatewayDiagnosticLog enthält mehrere Spalten.
Name | Beschreibung |
---|---|
TimeGenerated | Zeitstempel der einzelnen Ereignisse in UTC-Zeit. |
OperationName | Das Ereignis, das aufgetreten ist. Dabei kann es sich um SetGatewayConfiguration, SetConnectionConfiguration, HostMaintenanceEvent, GatewayTenantPrimaryChanged, MigrateCustomerSubscription, GatewayResourceMove, ValidateGatewayConfiguration handeln. |
Meldung | Details zum Vorgang und Liste mit Ergebnissen (Erfolg/Fehler). |
Das folgende Beispiel zeigt die Aktivität, die beim Anwenden einer neuen Konfiguration aufgezeichnet wurde:
Ein SetGatewayConfiguration-Vorgang wird jedes Mal aufgezeichnet, wenn eine Konfiguration auf einem VPN Gateway oder auf einem lokalen Netzwerkgateway geändert wird. Mithilfe von Querverweisen auf die Ergebnisse aus der Tabelle GatewayDiagnosticLog und aus der Tabelle TunnelDiagnosticLog können wir ermitteln, ob ein Tunnelverbindungsfehler zur der Zeit aufgetreten ist, als eine Konfiguration geändert oder eine Wartung durchgeführt wurde. Wenn dies der Fall ist, haben wir einen guten Anhaltspunkt für die mögliche Grundursache.
TunnelDiagnosticLog
Die Tabelle TunnelDiagnosticLog ist sehr nützlich, um die historischen Konnektivitätsstatus des Tunnels zu überprüfen.
Im Folgenden ist eine Beispielabfrage als Referenz dargestellt.
AzureDiagnostics
| where Category == "TunnelDiagnosticLog"
//| where remoteIP_s == "<REMOTE IP OF TUNNEL>"
| project TimeGenerated, OperationName, remoteIP_s, instance_s, Resource, ResourceGroup
| sort by TimeGenerated asc
Diese Abfrage für TunnelDiagnosticLog enthält mehrere Spalten.
Name | Beschreibung |
---|---|
TimeGenerated | Zeitstempel der einzelnen Ereignisse in UTC-Zeit. |
OperationName | Das Ereignis, das aufgetreten ist. Dabei kann es sich um TunnelConnected oder TunnelDisconnected handeln. |
remoteIP_s | IP-Adresse des lokalen VPN-Geräts. In der Praxis empfiehlt es sich, nach der IP-Adresse des jeweiligen lokalen Geräts zu filtern, falls mehrere vorhanden sind. |
Instance_s | Die Rolleninstanz des Gateways, die das Ereignis ausgelöst hat. Dabei kann es sich entweder um „GatewayTenantWorker_IN_0“ oder um „GatewayTenantWorker_IN_1“ handeln, also die Namen der beiden Instanzen des Gateways. |
Ressource | Gibt den Namen des VPN-Gateways an. |
ResourceGroup | Gibt die Ressourcengruppe an, in der sich das Gateway befindet. |
Beispielausgabe:
TunnelDiagnosticLog ist sehr nützlich für die Problembehandlung bei Ereignissen in der Vergangenheit, bei denen es um die unerwartete Trennung von VPN-Verbindungen geht. Als Leichtgewicht bietet diese Tabelle die Möglichkeit, große Zeitbereiche über mehrere Tage mit geringem Aufwand zu analysieren. Erst nachdem Sie den Zeitstempel einer Trennung identifiziert haben, können Sie die Tabelle IKEdiagnosticLog genauer analysieren, um ausführliche Informationen zur Ursache der Trennung zu erhalten, sofern diese mit IPsec zusammenhängen.
Einige Tipps zur Problembehandlung:
- Wenn bei einer Gatewayinstanz ein Trennungsereignis und nach einigen Sekunden bei der anderen Gatewayinstanz ein Verbindungsereignis auftritt, liegt ein Gatewayfailover vor. Dieses Verhalten ist normalerweise bei der Wartung einer Gatewayinstanz zu erwarten. Weitere Informationen zu diesem Verhalten finden Sie unter Informationen zur Redundanz von Azure-VPN-Gateways.
- Das gleiche Verhalten lässt sich beobachten, wenn Sie absichtlich eine Gatewayzurücksetzung auf Azure-Seite ausführen, wodurch die aktive Gatewayinstanz neu gestartet wird. Weitere Informationen zu diesem Verhalten finden Sie unter Zurücksetzen eines VPN-Gateways.
- Wenn bei einer Gatewayinstanz ein Trennungsereignis und nach einigen Sekunden bei derselben Gatewayinstanz ein Verbindungsereignis auftritt, liegt möglicherweise eine Netzwerkstörung vor, die ein DPD-Timeout verursacht, oder eine vom lokalen Gerät fälschlicherweise gesendete Trennung.
RouteDiagnosticLog
Mit der Tabelle RouteDiagnosticLog wird die Aktivität für statisch geänderte Routen oder über BGP empfangene Routen nachverfolgt.
Im Folgenden ist eine Beispielabfrage als Referenz dargestellt.
AzureDiagnostics
| where Category == "RouteDiagnosticLog"
| project TimeGenerated, OperationName, Message, Resource, ResourceGroup
Diese Abfrage für RouteDiagnosticLog enthält mehrere Spalten.
Name | Beschreibung |
---|---|
TimeGenerated | Zeitstempel der einzelnen Ereignisse in UTC-Zeit. |
OperationName | Das Ereignis, das aufgetreten ist. Hierbei kann es sich um StaticRouteUpdate, BgpRouteUpdate, BgpConnectedEvent, BgpDisconnectedEvent handeln. |
Meldung | Details zum Vorgang. |
Die Ausgabe enthält nützliche Informationen zu verbundenen/nicht verbundenen BGP-Peers und ausgetauschten Routen.
Beispiel:
IKEDiagnosticLog
Die Tabelle IKEDiagnosticLog enthält eine ausführliche Debugprotokollierung für IKE/IPsec. Es lohnt sich, sich diese Tabelle bei der Problembehandlung anzusehen, wenn Trennungsereignisse vorliegen oder in VPN-Szenarios Verbindungen nicht hergestellt werden.
Im Folgenden ist eine Beispielabfrage als Referenz dargestellt.
AzureDiagnostics
| where Category == "IKEDiagnosticLog"
| extend Message1=Message
| parse Message with * "Remote " RemoteIP ":" * "500: Local " LocalIP ":" * "500: " Message2
| extend Event = iif(Message has "SESSION_ID",Message2,Message1)
| project TimeGenerated, RemoteIP, LocalIP, Event, Level
| sort by TimeGenerated asc
Diese Abfrage für IKEDiagnosticLog enthält mehrere Spalten.
Name | Beschreibung |
---|---|
TimeGenerated | Zeitstempel der einzelnen Ereignisse in UTC-Zeit. |
RemoteIP | IP-Adresse des lokalen VPN-Geräts. In der Praxis empfiehlt es sich, nach der IP-Adresse des jeweiligen lokalen Geräts zu filtern, falls mehrere vorhanden sind. |
LocalIP | IP-Adresse des VPN Gateways, bei dem die Problembehandlung durchgeführt wird. In der Praxis empfiehlt es sich, nach der IP-Adresse des jeweiligen VPN-Gateways zu filtern, falls im Abonnement mehrere enthalten sind. |
Event | Enthält eine Diagnosemeldung, die für die Problembehandlung nützlich ist. Diese beginnt in der Regel mit einem Schlüsselwort und bezieht sich auf die vom Azure-Gateway ausgeführten Aktionen: [SEND] gibt ein Ereignis an, das durch ein vom Azure-Gateway gesendetes IPsec-Paket verursacht wurde. [RECEIVED] gibt ein Ereignis an, das auf ein von einem lokalen Gerät empfangenes Paket verweist. [LOCAL] gibt eine Aktion an, die vom Azure-Gateway lokal durchgeführt wird. |
Die Spalten „RemoteIP“, „LocalIP“ und „Event“ sind in der ursprünglichen Spaltenliste in der AzureDiagnostics-Datenbank übrigens nicht enthalten. Sie wurden der Abfrage durch Analysieren der Ausgabe der Spalte „Message“ hinzugefügt, um die Analyse zu vereinfachen.
Tipps zur Problembehandlung:
Zum Starten einer IPsec-Aushandlung müssen Sie nach der anfänglichen SA_INIT-Meldung suchen. Diese Meldung kann von beiden Seiten des Tunnels gesendet werden. Die Seite, von der das erste Paket gesendet wird, heißt in der IPsec-Terminologie „Initiator“, während die andere Seite als „Antwortdienst“ bezeichnet wird. Die erste SA_INIT-Meldung ist immer eine Meldung, für die rCookie = 0 gilt.
Wenn beim Einrichten des IPsec-Tunnels ein Fehler auftritt, wird der Vorgang von Azure einige Sekunden wiederholt. Daher ist die Problembehandlung bei einem ausgefallenen VPN in der Tabelle „IKEdiagnosticLog“ sehr bequem, da Sie nicht warten müssen, bis Sie das Problem reproduzieren können. Außerdem ist der Fehler theoretisch bei jeder Wiederholung derselbe, sodass Sie sich jederzeit eine Aushandlung, bei der ein Fehler aufgetreten ist, beispielhaft genauer ansehen können.
Die SA_INIT-Meldung enthält die IPsec-Parameter, die der Peer für diese IPsec-Aushandlung verwenden möchte. Im offiziellen Dokument
IPsec-/IKE-Standardparameter sind die vom Azure-Gateway unterstützten IPsec-Parameter mit den Standardeinstellungen aufgeführt.
P2SDiagnosticLog
P2SDiagnosticLog ist die letzte verfügbare Tabelle für die VPN-Diagnose. In dieser Tabelle wird die Aktivität für P2S (Point-to-Site) nachverfolgt (nur IKEv2- und OpenVPN-Protokolle).
Im Folgenden ist eine Beispielabfrage als Referenz dargestellt.
AzureDiagnostics
| where Category == "P2SDiagnosticLog"
| project TimeGenerated, OperationName, Message, Resource, ResourceGroup
Diese Abfrage für P2SDiagnosticLog enthält mehrere Spalten.
Name | Beschreibung |
---|---|
TimeGenerated | Zeitstempel der einzelnen Ereignisse in UTC-Zeit. |
OperationName | Das Ereignis, das aufgetreten ist. Das ist das Ereignis P2SLogEvent. |
Meldung | Details zum Vorgang. |
In der Ausgabe werden alle vom Gateway angewendeten Punkt-zu-Standort-Einstellungen sowie die geltenden IPSec-Richtlinien angezeigt.
Wenn von einem Client eine Punkt-zu-Standort-Verbindung über IKEv2 oder OpenVPN hergestellt wird, werden in der Tabelle die Protokollpaketaktivität, EAP/RADIUS-Konversationen und Ergebnisse (Erfolg/Fehler) nach Benutzer aufgezeichnet.
Nächste Schritte
Informationen zum Konfigurieren von Warnungen für Tunnelressourcenprotokolle finden Sie unter Einrichten von Warnungen für Ressourcenprotokolle von VPN Gateway.
Feedback
https://aka.ms/ContentUserFeedback.
Bald verfügbar: Im Laufe des Jahres 2024 werden wir GitHub-Tickets als Feedbackmechanismus für Inhalte auslaufen lassen und es durch ein neues Feedbacksystem ersetzen. Weitere Informationen finden Sie unter:Einreichen und Feedback anzeigen für