Felsöka Azure VPN Gateway med hjälp av diagnostikloggar

Den här artikeln hjälper dig att förstå de olika loggar som är tillgängliga för VPN Gateway-diagnostik och hur du använder dem för att effektivt felsöka PROBLEM med VPN-gateway.

Om ditt Azure-problem inte åtgärdas i den här artikeln går du till Azure-forumen på Microsoft Q &A och Stack Overflow. Du kan publicera ditt problem i dessa forum eller publicera till @AzureSupport på Twitter. Du kan också skicka en Azure Support begäran. Om du vill skicka en supportbegäran går du till sidan Azure Support och väljer Hämta support.

Följande loggar är tillgängliga i Azure:

• GatewayDiagnosticLog
• TunnelDiagnosticLog
• RouteDiagnosticLog
• IKEDiagnosticLog
• P2SDiagnosticLog

För principbaserade gatewayer är endast GatewayDiagnosticLog och RouteDiagnosticLog tillgängliga.

Information om alla VPN Gateway-loggar finns i Azure VPN Gateway monitoring data reference (Övervakningsdatareferens för Azure VPN Gateway)

Information om hur du konfigurerar diagnostiklogghändelser från Azure VPN Gateway med Azure Log Analytics finns i Skapa diagnostikinställningar i Azure Monitor.

GatewayDiagnosticLog

Konfigurationsändringar granskas i tabellen GatewayDiagnosticLog . Det kan ta några minuter innan ändringar som du kör återspeglas i loggarna.

Här har du en exempelfråga som referens.

AzureDiagnostics  
| where Category == "GatewayDiagnosticLog"  
| project TimeGenerated, OperationName, Message, Resource, ResourceGroup  
| sort by TimeGenerated asc

Den här frågan i GatewayDiagnosticLog visar flera kolumner.

Namn	Beskrivning
TimeGenerated	tidsstämpeln för varje händelse i UTC-tidszonen.
OperationName	händelsen som inträffade. Det kan vara antingen SetGatewayConfiguration, SetConnectionConfiguration, HostMaintenanceEvent, GatewayTenantPrimaryChanged, MigrateCustomerSubscription, GatewayResourceMove, ValidateGatewayConfiguration.
Meddelande	information om vilken åtgärd som händer och visar en lista över lyckade/misslyckade resultat.

I följande exempel visas aktiviteten som loggades när en ny konfiguration tillämpades:

Observera att en SetGatewayConfiguration loggas varje gång en konfiguration ändras både på en VPN Gateway eller en lokal nätverksgateway.

Om du jämför resultaten från tabellen GatewayDiagnosticLog med resultatet av tabellen TunnelDiagnosticLog kan du avgöra om ett tunnelanslutningsfel inträffade under en konfigurationsändring eller underhållsaktivitet. I så fall ger det en betydande indikation på den potentiella rotorsaken.

TunnelDiagnosticLog

Tabellen TunnelDiagnosticLog är användbar för att inspektera tunnelns historiska anslutningsstatus.

Här har du en exempelfråga som referens.

AzureDiagnostics
| where Category == "TunnelDiagnosticLog"
//| where remoteIP_s == "<REMOTE IP OF TUNNEL>"
| project TimeGenerated, OperationName, remoteIP_s, instance_s, Resource, ResourceGroup
| sort by TimeGenerated asc

Den här frågan i TunnelDiagnosticLog visar flera kolumner.

Namn	Beskrivning
TimeGenerated	tidsstämpeln för varje händelse i UTC-tidszonen.
OperationName	händelsen som inträffade. Det kan vara antingen TunnelConnected eller TunnelDisconnected.
remoteIP_s	IP-adressen för den lokala VPN-enheten. I verkliga scenarier är det användbart att filtrera efter IP-adressen för den relevanta lokala enheten ska det finnas fler än en.
Instance_s	gatewayrollinstansen som utlöste händelsen. Det kan vara antingen GatewayTenantWorker_IN_0 eller GatewayTenantWorker_IN_1, som är namnen på de två instanserna av gatewayen.
Resurs	anger namnet på VPN-gatewayen.
ResourceGroup	anger resursgruppen där gatewayen finns.

Exempel på utdata>

TunnelDiagnosticLog är användbar för att felsöka tidigare händelser om oväntade VPN-frånkopplingar. Dess lätta natur ger möjlighet att analysera stora tidsintervall under flera dagar med liten ansträngning. Först när du har identifierat tidsstämpeln för en frånkoppling kan du växla till den mer detaljerade analysen av tabellen IKEdiagnosticLog för att gå djupare in i resonemanget för frånkopplingarna ska dessa vara IPsec-relaterade.

Några felsökningstips:

• Om du ser en frånkopplingshändelse på en gatewayinstans, följt av en anslutningshändelse på en annan gatewayinstans inom några sekunder, indikerar det en gateway-redundans. En sådan händelse uppstår vanligtvis på grund av underhåll på en gatewayinstans. Mer information om det här beteendet finns i Om redundans för Azure VPN Gateway.
• Samma beteende observeras om du avsiktligt kör en gatewayåterställning på Azure-sidan , vilket orsakar en omstart av den aktiva gatewayinstansen. Mer information om det här beteendet finns i Återställa en VPN Gateway.
• Om du ser en frånkopplingshändelse på en gatewayinstans, följt av en anslutningshändelse på samma gatewayinstans på några sekunder, kanske du tittar på ett nätverksfel som orsakar en DPD-timeout eller en frånkoppling som felaktigt skickas av den lokala enheten.

RouteDiagnosticLog

Tabellen RouteDiagnosticLog spårar aktiviteten för statiskt ändrade vägar eller vägar som tagits emot via BGP.

Här har du en exempelfråga som referens.

AzureDiagnostics
| where Category == "RouteDiagnosticLog"
| project TimeGenerated, OperationName, Message, Resource, ResourceGroup

Den här frågan i RouteDiagnosticLog visar flera kolumner.

Namn	Beskrivning
TimeGenerated	tidsstämpeln för varje händelse i UTC-tidszonen.
OperationName	händelsen som inträffade. Kan vara något av StaticRouteUpdate, BgpRouteUpdate, BgpConnectedEvent, BgpDisconnectedEvent.
Meddelande	detaljerna i vilken åtgärd som sker.

Utdata visar användbar information om anslutna/frånkopplade BGP-peer-datorer och vägar som utbyts.

Exempel:

IKEDiagnosticLog

Tabellen IKEDiagnosticLog erbjuder utförlig felsökningsloggning för IKE/IPsec. Det här är användbart när du felsöker frånkopplingar eller misslyckas med att ansluta VPN-scenarier.

Här har du en exempelfråga som referens.

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

Den här frågan i IKEDiagnosticLog visar flera kolumner.

Namn	Beskrivning
TimeGenerated	tidsstämpeln för varje händelse i UTC-tidszonen.
RemoteIP	IP-adressen för den lokala VPN-enheten. I verkliga scenarier är det användbart att filtrera efter IP-adressen för den relevanta lokala enheten ska det finnas fler än en.
LokalIP	IP-adressen för vpn-gatewayen som vi felsöker. I verkliga scenarier är det användbart att filtrera efter IP-adressen för den relevanta VPN-gatewayen ska det finnas fler än en i din prenumeration.
Händelse	innehåller ett diagnostikmeddelande som är användbart för felsökning. De börjar vanligtvis med ett nyckelord och refererar till de åtgärder som utförs av Azure Gateway: [SEND] anger en händelse som orsakas av ett IPSec-paket som skickas av Azure Gateway. [MOTTAGET] anger en händelse till följd av ett paket som tagits emot från en lokal enhet. [LOKAL] anger en åtgärd som vidtas lokalt av Azure Gateway.

Observera hur kolumnerna RemoteIP, LocalIP och Event inte finns i den ursprungliga kolumnlistan i AzureDiagnostics-databasen, men läggs till i frågan genom att parsa utdata från kolumnen "Meddelande" för att förenkla analysen.

Felsökningstips:

• För att identifiera starten av en IPSec-förhandling måste du hitta det första SA_INIT meddelandet. Ett sådant meddelande kan skickas på båda sidor av tunneln. Den som skickar det första paketet kallas "initierare" i IPsec-terminologi, medan den andra sidan blir "responder". Det första SA_INIT meddelandet är alltid det där rCookie = 0.

• Om IPsec-tunneln inte kan upprättas fortsätter Azure att försöka igen med några sekunders mellanrum. Därför är det praktiskt att felsöka "VPN down"-problem på IKEdiagnosticLog eftersom du inte behöver vänta en viss tid för att återskapa problemet. Dessutom kommer misslyckandet i teorin alltid att vara detsamma varje gång vi försöker så att du bara kan zooma in i en "exempel" misslyckad förhandling när som helst.

• Den SA_INIT innehåller DE IPSec-parametrar som peer vill använda för denna IPsec-förhandling. Det officiella dokumentet
  Standardparametrar för IPsec/IKE visar de IPsec-parametrar som stöds av Azure Gateway med standardinställningar.

P2SDiagnosticLog

Den senast tillgängliga tabellen för VPN-diagnostik är P2SDiagnosticLog. Den här tabellen spårar aktiviteten för punkt-till-plats (endast IKEv2- och OpenVPN-protokoll).

Här har du en exempelfråga som referens.

AzureDiagnostics  
| where Category == "P2SDiagnosticLog"  
| project TimeGenerated, OperationName, Message, Resource, ResourceGroup

Den här frågan på P2SDiagnosticLog visar flera kolumner.

Namn	Beskrivning
TimeGenerated	tidsstämpeln för varje händelse i UTC-tidszonen.
OperationName	händelsen som inträffade. Kommer att vara P2SLogEvent.
Meddelande	detaljerna i vilken åtgärd som sker.

Utdata visar alla punkt-till-plats-inställningar som gatewayen har tillämpat och IPsec-principerna på plats.

När en klient upprättar en anslutning med OpenVPN- och Microsoft Entra-ID-autentisering för punkt-till-plats registrerar tabellen dessutom paketaktiviteten på följande sätt:

[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

Kommentar

I punkt-till-plats-loggen är användarnamnet delvis dolt. Den första oktetten för klientanvändarens IP-adress ersätts med en 0.

Nästa steg

Information om hur du konfigurerar aviseringar i tunnelresursloggar finns i Konfigurera aviseringar i VPN Gateway-resursloggar.