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:

Nome Descrição
GatewayDiagnosticLog Contém logs de diagnóstico para eventos de configuração do gateway, alterações primárias e eventos de manutenção.
TunnelDiagnosticLog Contém eventos de alteração de estado de túnel. Eventos de conexão/desconexão de túnel têm um motivo resumido para a alteração de estado, se aplicável.
RouteDiagnosticLog Registra em log as alterações em rotas estáticas e eventos de BGP que ocorrem no gateway.
IKEDiagnosticLog Registra em log eventos e mensagens de controle IKE no gateway.
P2SDiagnosticLog Registra eventos e mensagens de controle de ponto a site no gateway.

*para gateways baseados em política, somente GatewayDiagnosticLog e RouteDiagnosticLog estão disponíveis.

Observe que várias colunas estão disponíveis nessas tabelas. Neste artigo, estamos apresentando apenas as mais relevantes para um consumo mais fácil do log.

Configurar registro em log

Siga este procedimento para saber como configurar eventos de log de diagnóstico do Gateway de VPN do Azure usando o Azure Log Analytics:

  1. Criar um workspace do Log Analytics usando este artigo.

  2. Localize o Gateway de VPN na folha Monitor > Configurações de diagnóstico.

Screenshot of the Diagnostic settings blade.

  1. Selecione o gateway e clique em "Adicionar Configuração de diagnóstico".

Screenshot of the Add diagnostic setting interface.

  1. Preencha o nome da configuração de diagnóstico, selecione todas as categorias de log e escolha o Workspace do Log Analytics.

Detailed screenshot of the Add diagnostic setting properties.

Observação

Talvez demore algumas horas para os dados aparecerem inicialmente.

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 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. 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 seguinte exemplo mostra a atividade registrada quando uma nova configuração foi aplicada:

Example of a Set Gateway Operation seen in GatewayDiagnosticLog.

Observe que uma SetGatewayConfiguration será registrada em log sempre que alguma configuração for modificada em um Gateway de VPN ou em um Gateway de Rede Local. A referência cruzada dos resultados da tabela GatewayDiagnosticLog com os da tabela TunnelDiagnosticLog pode nos ajudar a determinar se uma falha de conectividade do túnel começou ao mesmo tempo em que uma configuração foi alterada ou em que uma manutenção ocorreu. Nesse caso, temos um excelente ponteiro para a possível causa raiz.

TunnelDiagnosticLog

A tabela TunnelDiagnosticLog é muito útil para inspecionar o histórico do status 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 no TunnelDiagnosticLog 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. Pode ser TunnelConnected ou TunnelDisconnected.
remoteIP_s o endereço IP do dispositivo VPN local. Em cenários do mundo real, é útil filtrar segundo o 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:

Example of a Tunnel Connected Event seen in TunnelDiagnosticLog.

O TunnelDiagnosticLog é muito ú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ê vê um evento de desconexão em uma instância de gateway seguido de um evento de conexão em uma instância de gateway diferente em alguns segundos, trata-se de um failover de gateway. Geralmente, esse é um comportamento esperado 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, que causa uma reinicialização da instância de gateway ativa. 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á estar observando 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 no RouteDiagnosticLog 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. Pode ser StaticRouteUpdate, BgpRouteUpdate, BgpConnectedEvent, BgpDisconnectedEvent.
Message o detalhe de qual operação está ocorrendo.

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

Exemplo:

Example of BGP route exchange activity seen in RouteDiagnosticLog.

IKEDiagnosticLog

A tabela IKEDiagnosticLog oferece registro em log de depuração detalhado para IKE/IPSec. É muito útil de revisar ao solucionar problemas de desconexões ou cenários de falha na conexão 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 no IKEDiagnosticLog mostrará 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 do mundo real, é útil filtrar segundo o endereço IP do dispositivo local relevante caso haja mais de um.
LocalIP o endereço IP do Gateway de VPN no qual estamos solucionando problemas. Em cenários do mundo real, é útil filtrar segundo o endereço IP do gateway de VPN relevante caso haja 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 que 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 "Message" para simplificar a 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 continuará tentando em intervalos de poucos segundos. Por esse motivo, a solução de problemas de "VPN inoperante" é muito conveniente no IKEdiagnosticLog, uma vez que você não precisa esperar por 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 mostrará todas as configurações de ponto a site que o gateway aplicou, bem como as diretivas IPsec em vigor.

Example of Point to Site connection seen in P2SDiagnosticLog.

Além disso, sempre que um cliente se conectar via IKEv2 ou OpenVPN ponto a site, a tabela registrará em log a atividade do pacote, as conversas de EAP/RADIUS e os resultados de êxito/falha segundo o usuário.

Example of EAP authentication seen in P2SDiagnosticLog.

Próximas etapas

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