Partilhar via

Resolver problemas de Gateway de VPN do Azure com registos de diagnóstico

  • Artigo

Este artigo ajuda a entender os diferentes logs disponíveis para o diagnóstico do Gateway VPN e como usá-los para solucionar problemas de gateway VPN de forma eficaz.

Se o seu problema do Azure não for resolvido neste artigo, visite os fóruns do Azure em Microsoft Q & A e Stack Overflow. Você pode postar seu problema nesses fóruns ou postar para @AzureSupport no Twitter. Você também pode enviar uma solicitação de suporte do Azure. Para enviar uma solicitação de suporte, na página de suporte do Azure, selecione Obter suporte.

Os seguintes logs estão disponíveis no Azure:

  • GatewayDiagnosticLog
  • TunnelDiagnosticLog
  • RouteDiagnosticLog
  • IKEDiagnosticLog
  • P2SDiagnosticLog

Para gateways baseados em políticas, apenas GatewayDiagnosticLog e RouteDiagnosticLog estão disponíveis.

Para todos os logs do Gateway VPN, consulte Referência de dados de monitoramento do Gateway VPN do Azure

Para configurar eventos de log de diagnóstico do Gateway de VPN do Azure usando o Azure Log Analytics, consulte Criar configurações de diagnóstico no Azure Monitor.

GatewayDiagnosticLog

As alterações de configuração são auditadas na tabela GatewayDiagnosticLog . Pode levar alguns minutos até que as alterações executadas sejam refletidas nos logs.

Aqui você tem uma consulta de exemplo como referência.

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

Esta consulta em GatewayDiagnosticLog mostra várias colunas.

Name Descrição
TimeGenerated o carimbo de data/hora de cada evento, no fuso horário UTC.
Nome da operação o evento que aconteceu. Pode ser SetGatewayConfiguration , SetConnectionConfiguration, HostMaintenanceEvent, GatewayTenantPrimaryChanged, MigrateCustomerSubscription, GatewayResourceMove, ValidateGatewayConfiguration.
Mensagem o detalhe de qual operação está acontecendo e lista os resultados bem-sucedidos/falhados.

O exemplo a seguir mostra a atividade registrada quando uma nova configuração foi aplicada:

Exemplo de uma operação set Gateway vista em GatewayDiagnosticLog.

Observe que um SetGatewayConfiguration é registrado sempre que uma configuração é modificada em um Gateway VPN ou em um Gateway de Rede Local.

Comparar os resultados da tabela GatewayDiagnosticLog com os resultados da tabela TunnelDiagnosticLog pode ajudar a determinar se ocorreu uma falha de conectividade de túnel durante uma alteração de configuração ou atividade de manutenção. Em caso afirmativo, fornece uma indicação significativa sobre a potencial causa raiz.

TunnelDiagnosticLog

A tabela TunnelDiagnosticLog é útil para inspecionar os status históricos de conectividade do túnel.

Aqui você tem uma consulta de exemplo como referência.

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

Esta consulta no TunnelDiagnosticLog mostra várias colunas.

Name Descrição
TimeGenerated o carimbo de data/hora de cada evento, no fuso horário UTC.
Nome da operação o evento que aconteceu. Pode ser TunnelConnected ou TunnelDisconnected.
remoteIP_s o endereço IP do dispositivo VPN local. Em cenários do mundo real, é útil filtrar pelo endereço IP do dispositivo local relevante, caso haja mais de um.
Instance_s A instância de função de gateway que disparou o evento. Pode ser GatewayTenantWorker_IN_0 ou GatewayTenantWorker_IN_1, que são os nomes das duas instâncias do gateway.
Recurso indica o nome do gateway VPN.
ResourceGroup Indica o grupo de recursos onde o gateway está.

Saída de exemplo:

Exemplo de um evento conectado ao túnel visto no TunnelDiagnosticLog.

O TunnelDiagnosticLog é útil para solucionar problemas de eventos anteriores sobre desconexões VPN inesperadas. Sua natureza leve oferece a possibilidade de analisar grandes intervalos de tempo ao longo de vários dias com pouco esforço. Somente depois de identificar o carimbo de data/hora de uma desconexão, você pode alternar para a análise mais detalhada da tabela IKEdiagnosticLog para aprofundar o raciocínio das desconexões devem estar relacionadas ao IPsec.

Algumas dicas de solução de problemas:

  • Se você observar um evento de desconexão em uma instância de gateway, seguido por um evento de conexão em uma instância de gateway diferente em poucos segundos, isso indica um failover de gateway. Esse evento normalmente ocorre devido à manutenção em uma instância de gateway. Para saber mais sobre esse comportamento, consulte Sobre a redundância de gateway de VPN do Azure.
  • O mesmo comportamento é observado se você executar intencionalmente uma Redefinição de Gateway no lado do Azure - o que causa uma reinicialização da instância de gateway ativa. Para saber mais sobre esse comportamento, consulte Redefinir um gateway de VPN.
  • Se você vir um evento de desconexão em uma instância de gateway, seguido por um evento de conexão na mesma instância de gateway em alguns segundos, você pode estar vendo uma falha de rede causando um tempo limite de DPD ou uma desconexão enviada erroneamente pelo dispositivo local.

RouteDiagnosticLog

A tabela RouteDiagnosticLog rastreia a atividade para rotas modificadas estaticamente ou rotas recebidas via BGP.

Aqui você tem uma consulta de exemplo como referência.

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

Esta consulta no RouteDiagnosticLog mostra várias colunas.

Name Descrição
TimeGenerated o carimbo de data/hora de cada evento, no fuso horário UTC.
Nome da operação o evento que aconteceu. Pode ser StaticRouteUpdate , BgpRouteUpdate, BgpConnectedEvent, BgpDisconnectedEvent.
Mensagem o detalhe de que operação está acontecendo.

A saída mostra informações úteis sobre pares BGP conectados/desconectados e rotas trocadas.

Exemplo:

Exemplo de atividade de troca de rota BGP visto no RouteDiagnosticLog.

IKEDiagnosticLog

A tabela IKEDiagnosticLog oferece log de depuração detalhado para IKE/IPsec. Isso é útil para revisar ao solucionar problemas de desconexões ou falha ao conectar cenários de VPN.

Aqui você tem uma consulta de exemplo como referência.

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

Esta consulta no IKEDiagnosticLog mostra várias colunas.

Name Descrição
TimeGenerated o carimbo de data/hora de cada evento, no fuso horário UTC.
RemoteIP o endereço IP do dispositivo VPN local. Em cenários do mundo real, é útil filtrar pelo endereço IP do dispositivo local relevante, caso haja mais de um.
LocalIP o endereço IP do Gateway de VPN que estamos solucionando. Em cenários do mundo real, é útil filtrar pelo endereço IP do gateway VPN relevante caso haja mais de um em sua assinatura.
Evento contém uma mensagem de diagnóstico útil para a resolução de problemas. Eles geralmente começam com uma palavra-chave e se referem às ações executadas pelo Gateway do Azure: [SEND] indica um evento causado por um pacote IPSec enviado pelo Gateway do Azure. [RECEBIDO] Indica um evento em consequência de um pacote recebido do dispositivo local. [LOCAL] indica uma ação executada localmente pelo Gateway do Azure.

Observe como as colunas RemoteIP, LocalIP e Event não estão presentes na lista de colunas original no banco de dados AzureDiagnostics, mas são adicionadas à consulta analisando a saída da coluna "Mensagem" para simplificar sua análise.

Dicas de solução de problemas:

  • Para identificar o início de uma negociação IPSec, você precisa encontrar a mensagem SA_INIT inicial. Essa mensagem pode ser enviada por ambos os lados do túnel. Quem envia o primeiro pacote é chamado de "iniciador" na terminologia IPsec, enquanto o outro lado se torna o "responder". A primeira mensagem SA_INIT é sempre aquela em que rCookie = 0.

  • Se o túnel IPsec não for estabelecido, o Azure continuará tentando novamente a cada poucos segundos. Por esse motivo, a solução de problemas de "VPN inativa" é conveniente no IKEdiagnosticLog, pois você não precisa esperar por um tempo específico para reproduzir o problema. Além disso, a falha será, em teoria, sempre a mesma sempre que tentarmos, para que você possa apenas ampliar uma "amostra" de negociação falhando a qualquer momento.

  • O SA_INIT contém os parâmetros IPSec que o par deseja usar para essa negociação IPsec. O documento oficial
    Os parâmetros IPsec/IKE padrão listam os parâmetros IPsec suportados pelo Gateway do Azure com as configurações padrão.

P2SDiagnosticLog

A última tabela disponível para diagnóstico de VPN é P2SDiagnosticLog. Esta tabela rastreia a atividade para Ponto a Site (apenas protocolos IKEv2 e OpenVPN).

Aqui você tem uma consulta de exemplo como referência.

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

Esta consulta no P2SDiagnosticLog mostrará várias colunas.

Name Descrição
TimeGenerated o carimbo de data/hora de cada evento, no fuso horário UTC.
Nome da operação o evento que aconteceu. Será P2SLogEvent.
Mensagem o detalhe de que operação está acontecendo.

A saída mostra todas as configurações Ponto a Site que o gateway aplicou e as políticas IPsec em vigor.

Exemplo de conexão Ponto a Site visto em P2SDiagnosticLog.

Além disso, quando um cliente estabelece uma conexão usando a autenticação OpenVPN e Microsoft Entra ID para ponto a site, a tabela registra a atividade do pacote da seguinte maneira:

[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

No log ponto-a-site, o nome de usuário é parcialmente obscurecido. O primeiro octeto do IP do usuário cliente é substituído por um 0arquivo .

Passos Seguintes

Para configurar alertas em logs de recursos de túnel, consulte Configurar alertas em logs de recursos do Gateway VPN.