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:

• GatewayDiagnosticLog
• TunnelDiagnosticLog
• RouteDiagnosticLog
• IKEDiagnosticLog
• P2SDiagnosticLog

Für richtlinienbasierte Gateways sind nur GatewayDiagnosticLog und RouteDiagnosticLog verfügbar.

Informationen zu allen VPN Gateway-Protokollen finden Sie in der Referenz zu Azure VPN Gateway-Überwachungsdaten.

Informationen zum Einrichten von Diagnoseprotokollereignisse von Azure VPN Gateway mithilfe von Azure Log Analytics finden Sie unter Erstellen von Diagnoseeinstellungen in Azure Monitor.

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.

Das folgende Beispiel zeigt die Aktivität, die beim Anwenden einer neuen Konfiguration protokolliert wurde:

Ein SetGatewayConfiguration-Vorgang wird jedes Mal aufgezeichnet, wenn eine Konfiguration für eine VPN Gateway-Instanz oder auf einem lokalen Netzwerkgateway geändert wird.

Wenn Sie die Ergebnisse aus der Tabelle GatewayDiagnosticLog mit den Ergebnissen aus der Tabelle TunnelDiagnosticLog vergleichen, können Sie ermitteln, ob ein Tunnelverbindungsfehler während einer Konfigurationsänderung oder einer Wartungsaktivität aufgetreten ist. Falls ja, gibt es einen signifikanten Hinweis auf die potenzielle Grundursache.

TunnelDiagnosticLog

Die Tabelle TunnelDiagnosticLog ist 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.

Beispielausgabe:

TunnelDiagnosticLog ist 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 einer anderen Gatewayinstanz ein Verbindungsereignis auftritt, liegt ein Gatewayfailover vor. Ein solches Ereignis tritt in der Regel aufgrund einer Wartung einer Gatewayinstanz auf. 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.

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-Szenarien 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.

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 alle paar Sekunden wiederholt. Daher ist die Problembehandlung bei einem ausgefallenen VPN in der Tabelle „IKEdiagnosticLog“ 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.

In der Ausgabe werden alle vom Gateway angewendeten Point-to-Site-Einstellungen sowie die geltenden IPSec-Richtlinien angezeigt.

Wenn ein Client eine Verbindung mit OpenVPN und Microsoft Entra ID-Authentifizierung für Point-to-Site herstellt, zeichnet die Tabelle außerdem die Paketaktivität wie folgt auf:

[MSG] [default] [OVPN_XXXXXXXXXXXXXXXXXXXXXXXXXXX] Connect request received. IP=0.X.X.X:XXX
[MSG] [default] [OVPN_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx] AAD authentication succeeded. Username=***tosouser@contoso.com
[MSG] [default] [OVPN_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx] Connection successful. Username=***tosouser@contoso.com IP=10.0.0.1

Nächste Schritte

Informationen zum Konfigurieren von Warnungen für Tunnelressourcenprotokolle finden Sie unter Einrichten von Warnungen für Ressourcenprotokolle von VPN Gateway.