Condividi tramite

Risolvere i problemi di Gateway VPN di Azure usando i log di diagnostica

  • Articolo

Questo articolo illustra i diversi log disponibili per la diagnostica del gateway VPN e come usarli per risolvere in modo efficace i problemi del gateway VPN.

Se il problema relativo ad Azure non è trattato in questo articolo, visitare i forum di Azure su Microsoft Q&A e Stack Overflow. È possibile pubblicare il problema in questi forum o in @AzureSupport su Twitter. È anche possibile inviare una richiesta di supporto tecnico di Azure. Per inviare una richiesta di supporto, selezionare Supporto tecnico nella pagina del supporto di Azure.

In Azure sono disponibili i log seguenti:

  • GatewayDiagnosticLog
  • TunnelDiagnosticLog
  • RouteDiagnosticLog
  • IKEDiagnosticLog
  • P2SDiagnosticLog

Per i gateway basati su criteri, sono disponibili solo GatewayDiagnosticLog e RouteDiagnosticLog.

Per tutti i log del gateway VPN, vedere Informazioni di riferimento sul monitoraggio dei dati del gateway VPN di Azure

Per configurare gli eventi del log di diagnostica dal gateway VPN di Azure con Azure Log Analytics, vedere Creare impostazioni di diagnostica in Monitoraggio di Azure.

GatewayDiagnosticLog

Le modifiche alla configurazione vengono controllate nella tabella GatewayDiagnosticLog. Prima che le modifiche eseguite vengano riflesse nei log potrebbero essere necessari alcuni minuti.

Di seguito è riportata una query di esempio come riferimento.

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

Questa query in GatewayDiagnosticLog mostra più colonne.

Nome Descrizione
TimeGenerated timestamp di ogni evento, nel fuso orario UTC.
OperationName l'evento che si è verificato. Può trattarsi di SetGatewayConfiguration, SetConnectionConfiguration, HostMaintenanceEvent, GatewayTenantPrimaryChanged, MigrateCustomerSubscription, GatewayResourceMove, ValidateGatewayConfiguration.
Messaggio dettaglio dell'operazione in corso, che elenca i risultati con esito positivo/negativo.

L'esempio seguente mostra l'attività registrata quando è stata applicata una nuova configurazione:

Esempio di operazione set gateway visualizzata in GatewayDiagnosticLog.

Si noti che un eventi SetGatewayConfiguration viene registrato ogni volta che una configurazione viene modificata in un gateway VPN o in un gateway di rete locale.

Il confronto tra i risultati della tabella GatewayDiagnosticLog e quelli della tabella TunnelDiagnosticLog consente di determinare se si è verificato un errore di connettività del tunnel durante una modifica della configurazione o un'attività di manutenzione. In tal caso, fornisce un'indicazione significativa verso la potenziale causa radice.

TunnelDiagnosticLog

La tabella TunnelDiagnosticLog è utile per esaminare gli stati cronologici di connettività del tunnel.

Di seguito è riportata una query di esempio come riferimento.

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

Questa query in TunnelDiagnosticLog mostra più colonne.

Nome Descrizione
TimeGenerated timestamp di ogni evento, nel fuso orario UTC.
OperationName l'evento che si è verificato. Può essere TunnelConnected o TunnelDisconnected.
remoteIP_s indirizzo IP del dispositivo VPN locale. Negli scenari reali, è utile filtrare in base all'indirizzo IP del dispositivo locale pertinente, che deve essere presente più di uno.
Instance_s istanza del ruolo del gateway che ha attivato l'evento. Può essere GatewayTenantWorker_IN_0 o GatewayTenantWorker_IN_1, ovvero i nomi delle due istanze del gateway.
Conto risorse indica il nome del gateway VPN.
ResourceGroup indica il gruppo di risorse in cui si trova il gateway.

Output di esempio:

Esempio di evento connesso al tunnel visualizzato in TunnelDiagnosticLog.

TunnelDiagnosticLog è utile per risolvere gli eventi precedenti relativi alle disconnessioni VPN impreviste. La sua natura leggera offre la possibilità di analizzare intervalli di tempo di grandi dimensioni in diversi giorni con poco sforzo. Solo dopo aver identificato il timestamp di una disconnessione, è possibile passare all'analisi più dettagliata della tabella IKEdiagnosticLog per approfondire il ragionamento delle disconnessioni, qualora queste siano correlate a IPsec.

Alcuni suggerimenti per la risoluzione dei problemi:

  • Se si osserva un evento di disconnessione in un'istanza del gateway, seguito da un evento di connessione in un'istanza del gateway diversa entro pochi secondi, ciò indica un failover del gateway. Questo evento si verifica in genere a causa di operazioni di manutenzione in un'istanza del gateway. Per altre informazioni su questo comportamento, vedere Informazioni sulla ridondanza del gateway VPN di Azure.
  • Lo stesso comportamento viene osservato se si esegue intenzionalmente una reimpostazione del gateway sul lato di Azure, causando un riavvio dell'istanza del gateway attiva. Per altre informazioni su questo comportamento, vedere Reimpostare un gateway VPN.
  • Se viene visualizzato un evento di disconnessione in un'istanza del gateway, seguito da un evento di connessione nella stessa istanza del gateway in pochi secondi, potrebbe essersi verificato un errore di rete che causa un timeout DPD o l'errato invio di una disconnessione dal dispositivo locale.

RouteDiagnosticLog

La tabella RouteDiagnosticLog traccia l'attività per route o route modificate in modo statico ricevute tramite BGP.

Di seguito è riportata una query di esempio come riferimento.

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

Questa query in RouteDiagnosticLog mostra più colonne.

Nome Descrizione
TimeGenerated timestamp di ogni evento, nel fuso orario UTC.
OperationName l'evento che si è verificato. Può essere StaticRouteUpdate, BgpRouteUpdate, BgpConnectedEvent o BgpDisconnectedEvent.
Messaggio dettagli dell'operazione in corso.

L'output mostra informazioni utili sui peer BGP connessi/disconnessi e sulle route scambiate.

Esempio:

Esempio di attività di scambio di route BGP visualizzate in RouteDiagnosticLog.

IKEDiagnosticLog

La tabella IKEDiagnosticLog offre la registrazione dettagliata del debug per IKE/IPsec. Ciò è utile per esaminare la risoluzione dei problemi relativi alle disconnessioni o alla mancata connessione di scenari VPN.

Di seguito è riportata una query di esempio come riferimento.

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

Questa query su IKEDiagnosticLog mostra più colonne.

Nome Descrizione
TimeGenerated timestamp di ogni evento, nel fuso orario UTC.
RemoteIP indirizzo IP del dispositivo VPN locale. Negli scenari reali, è utile filtrare in base all'indirizzo IP del dispositivo locale pertinente, che deve essere presente più di uno.
LocalIP indirizzo IP del gateway VPN interessato dal problema che si sta risolvendo. Negli scenari reali, è utile filtrare in base all'indirizzo IP del gateway VPN pertinente; deve esserne presente più di uno nella sottoscrizione.
Evento contiene un messaggio di diagnostica utile per la risoluzione dei problemi. In genere questi iniziano con una parola chiave e fanno riferimento alle azioni eseguite dal gateway di Azure: [SEND] indica un evento causato da un pacchetto IPSec inviato dal gateway di Azure. [RECEIVED] indica un evento conseguente alla ricezione di un pacchetto dal dispositivo locale. [LOCAL] indica un'azione eseguita localmente dal gateway di Azure.

Si noti che le colonne RemoteIP, LocalIP e Event non sono presenti nell'elenco di colonne originale nel database AzureDiagnostics, ma vengono aggiunte alla query analizzando l'output della colonna "Message" per semplificare l'analisi.

Suggerimenti per la risoluzione dei problemi:

  • Per identificare l'inizio di una negoziazione IPSec, è necessario trovare il messaggio SA_INIT iniziale. Tale messaggio può essere inviato da entrambi i lati del tunnel. Chiunque invii il primo pacchetto viene chiamato "iniziatore" nella terminologia IPsec, mentre l'altro lato diventa il "risponditore". Il primo messaggio SA_INIT è sempre quello in cui rCookie = 0.

  • Se non è possibile stabilire il tunnel IPsec, Azure continua a riprovare ogni pochi secondi. Per questo motivo, la risoluzione dei problemi di "down VPN" è utile in IKEdiagnosticLog perché non è necessario attendere un tempo specifico per riprodurre il problema. Inoltre, in teoria si avrà sempre un esito negativo a ogni tentativo, per cui si potrà semplicemente ingrandire una negoziazione "campione" non riuscita in qualsiasi momento.

  • SA_INIT contiene i parametri IPSec che il peer vuole usare per questa negoziazione IPsec. Il documento ufficiale
    Parametri IPsec/IKE predefiniti elenca i parametri IPsec supportati dal gateway di Azure con le impostazioni predefinite.

P2SDiagnosticLog

L'ultima tabella disponibile per la diagnostica VPN è P2SDiagnosticLog. Questa tabella traccia l'attività per Point to Site (solo i protocolli IKEv2 e OpenVPN).

Di seguito è riportata una query di esempio come riferimento.

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

Questa query in P2SDiagnosticLog mostrerà più colonne.

Nome Descrizione
TimeGenerated timestamp di ogni evento, nel fuso orario UTC.
OperationName l'evento che si è verificato. Sarà P2SLogEvent.
Messaggio dettagli dell'operazione in corso.

L'output mostra tutte le impostazioni da punto a sito applicate al gateway e i criteri IPsec.

Esempio di connessione da punto a sito visualizzato in P2SDiagnosticLog.

Inoltre, quando un client stabilisce una connessione usando l'autenticazione OpenVPN e Microsoft Entra ID per punto a sito, la tabella registra l'attività dei pacchetti come indicato di seguito:

[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

Nota

Nel log da punto a sito il nome utente è parzialmente nascosto. Il primo ottetto dell'indirizzo IP utente client viene sostituito con un oggetto 0.

Passaggi successivi

Per configurare gli avvisi nei log delle risorse del tunnel, vedere Configurare gli avvisi nei log delle risorse del gateway VPN.