Problembehandlung bei Azure VPN Gateway mithilfe von Diagnoseprotokollen

  • Artikel

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:

  1. Erstellen Sie anhand der Informationen in diesem Artikel einen Log Analytics-Arbeitsbereich.

  2. Suchen Sie Ihr VPN Gateway auf dem Blatt „Überwachung“ > „Diagnoseeinstellungen“.

Screenshot of the Diagnostic settings blade.

  1. Wählen Sie das Gateway aus, und klicken Sie auf „Diagnoseeinstellung hinzufügen“.

Screenshot of the Add diagnostic setting interface.

  1. Geben Sie den Namen der Diagnoseeinstellung ein, wählen Sie alle Protokollkategorien aus, und wählen Sie den Log Analytics-Arbeitsbereich aus.

Detailed screenshot of the Add diagnostic setting properties.

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:

Example of a Set Gateway Operation seen in GatewayDiagnosticLog.

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:

Example of a Tunnel Connected Event seen in TunnelDiagnosticLog.

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:

Example of BGP route exchange activity seen in RouteDiagnosticLog.

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.

Example of Point to Site connection seen in P2SDiagnosticLog.

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.

Example of EAP authentication seen in P2SDiagnosticLog.

Nächste Schritte

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