Solucionar problemas do Gateway de VPN do Azure usando logs de diagnóstico

Este artigo ajuda a entender os diferentes logs disponíveis para diagnóstico do Gateway de VPN e como usá-los para solucionar problemas do Gateway de VPN com eficiência.

Caso o seu problema do Azure não seja abordado neste artigo, visite os fóruns do Azure no Microsoft Q&A e no Stack Overflow. Você pode postar seu problema nesses fóruns ou enviar 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 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ítica, apenas GatewayDiagnosticLog e RouteDiagnosticLog estão disponíveis.

Para todos os logs do Gateway de VPN, confira a referência de dados de monitoramento do Gateway de VPN do Azure

Para configurar eventos de log de diagnóstico do Gateway de VPN do Azure usando o Azure Log Analytics, confira 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 para que as alterações executadas sejam refletidas nos logs.

Aqui, você tem um exemplo de consulta como referência.

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

Essa consulta no GatewayDiagnosticLog mostra várias colunas.

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

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

Exemplo de uma operação de definição de gateway vista em GatewayDiagnosticLog.

Observe que um SetGatewayConfiguration é registrado sempre que uma configuração é modificada em um Gateway de 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. Nesse caso, isso fornece uma indicação significativa para a possível causa raiz.

TunnelDiagnosticLog

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

Aqui, você tem um exemplo de consulta 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

Essa consulta em TunnelDiagnosticLog mostra várias colunas.

Nome Descrição
TimeGenerated o carimbo de data/hora de cada evento, no fuso horário UTC.
OperationName o evento que ocorreu. Pode ser TunnelConnected ou TunnelDisconnected.
remoteIP_s o endereço IP do dispositivo VPN local. Em cenários reais, é útil filtrar pelo endereço IP do dispositivo local relevante, caso haja mais de um.
Instance_s a instância de função do 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 de VPN.
ResourceGroup indica o grupo de recursos em que o gateway se encontra.

Saída de exemplo:

Exemplo de um Evento de Túnel Conectado visto em TunnelDiagnosticLog.

O TunnelDiagnosticLog é útil para solucionar problemas de eventos anteriores sobre desconexões de VPN inesperadas. Sua natureza leve oferece a possibilidade de analisar intervalos de tempo grandes ao longo de vários dias com pouco esforço. Somente após identificar o carimbo de data/hora de uma desconexão, você pode passar para a análise mais detalhada da tabela IKEdiagnosticLog para obter detalhes sobre as motivações das desconexões caso elas sejam 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 alguns segundos, ele indicará um failover de gateway. Esse evento normalmente surge devido à manutenção em uma instância de gateway. Para saber mais sobre esse comportamento, confira Sobre a redundância do Gateway de VPN do Azure.
  • O mesmo comportamento será observado se você executar intencionalmente uma Redefinição de Gateway no lado do Azure, o que causará uma reinicialização da instância do gateway ativo. Para saber mais sobre esse comportamento, confira Redefinir um Gateway de VPN.
  • Se você vir um evento de desconexão em uma instância de gateway seguido de um evento de conexão na mesma instância em alguns segundos, poderá observar uma falha de rede que causa um tempo limite de DPD ou uma desconexão enviada erroneamente pelo dispositivo local.

RouteDiagnosticLog

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

Aqui, você tem um exemplo de consulta como referência.

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

Essa consulta em RouteDiagnosticLog mostra várias colunas.

Nome Descrição
TimeGenerated o carimbo de data/hora de cada evento, no fuso horário UTC.
OperationName o evento que ocorreu. Pode ser StaticRouteUpdate, BgpRouteUpdate, BgpConnectedEvent, BgpDisconnectedEvent.
Message o detalhe de qual operação está ocorrendo.

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

Exemplo:

Exemplo de atividade de troca de rota BGP vista em RouteDiagnosticLog.

IKEDiagnosticLog

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

Aqui, você tem um exemplo de consulta 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

Essa consulta em IKEDiagnosticLog mostra várias colunas.

Nome 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 reais, é ú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 problemas. Em cenários reais, é útil filtrar pelo endereço IP do gateway de VPN relevante, se houver mais de um em sua assinatura.
Evento contém uma mensagem de diagnóstico útil para solucionar problemas. Normalmente, elas 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. [RECEIVED] indica um evento em consequência de um pacote recebido do dispositivo local. [LOCAL] indica uma ação realizada 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 do AzureDiagnostics, mas são adicionadas à consulta analisando a saída da coluna "Message" 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 inicial SA_INIT. Essa mensagem pode ser enviada por qualquer lado do túnel. Quem envia o primeiro pacote é chamado de "iniciador" na terminologia do IPsec, enquanto o outro lado é o "respondente". A primeira mensagem SA_INIT é sempre aquela em que rCookie = 0.

  • Se o túnel IPsec não for estabelecido, o Azure continua repetindo a cada poucos segundos. Por esse motivo, solucionar problemas de "VPN inativa" é conveniente no IKEdiagnosticLog porque você não precisa esperar um tempo específico para reproduzir o problema. Além disso, em teoria, a falha sempre será a mesma sempre que tentarmos, de modo que você pode ampliar uma negociação com falha de "exemplo" a qualquer momento.

  • SA_INIT contém os parâmetros de IPSec que o par deseja usar para essa negociação de IPSec. O documento oficial
    Parâmetros padrão de IPSec/IKE lista os parâmetros de IPsec com suporte do 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 de Ponto para Site (somente protocolos IKEv2 e OpenVPN).

Aqui, você tem um exemplo de consulta como referência.

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

Essa consulta no P2SDiagnosticLog mostrará várias colunas.

Nome Descrição
TimeGenerated o carimbo de data/hora de cada evento, no fuso horário UTC.
OperationName o evento que ocorreu. Será P2SLogEvent.
Message o detalhe de qual operação está ocorrendo.

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 vista em P2SDiagnosticLog.

Além disso, quando um cliente estabelece uma conexão usando a autenticação do Microsoft Entra ID e OpenVPN 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

Observação

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

Próximas etapas

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