Freigeben über

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:

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

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 protokolliert wurde:

Beispiel für einen SetGateway-Vorgang in GatewayDiagnosticLog

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.

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:

Beispiel für das Ereignis „Tunnel verbunden“ in „TunnelDiagnosticLog“

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.

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:

Beispiel für BGP-Routenaustauschaktivität 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-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.

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 der VPN Gateway-Instanz, bei der 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.
Ereignis 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 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.

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 Point-to-Site-Einstellungen sowie die geltenden IPSec-Richtlinien angezeigt.

Beispiel einer Punkt-zu-Standort-Verbindung in „P2SDiagnosticLog“

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

Hinweis

Im Point-to-Site-Protokoll wird der Benutzername teilweise unkenntlich gemacht. Das erste Oktett der Clientbenutzer-IP wird durch 0 ersetzt.

Nächste Schritte

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