Como gerir os logs da tua VPN e diagnosticar incidentes

A consola de troubleshooting permite-te gerar, consultar e descarregar os logs do túnel VPN a partir do painel, e diagnosticar a maioria dos incidentes por tua conta.

A chave está em ler o log para saber em que fase falha a ligação.

👍 O que obténs

Localizar o ponto exato da falha (a ligação inicial ou o passo de dados) e a ação que a corrige, sem depender de suporte na maioria dos casos.

Antes de começar

• Ter acesso ao painel com permissões sobre a subscrição de rede.
• Ter um túnel VPN criado, esteja ou não operacional.
• Opcionalmente, acesso aos logs do equipamento remoto para correlacionar se precisares de ir mais além.

Passo 1. Gera e consulta os logs

1. Entra na tua subscrição com VPN e abre Resolução de problemas / Logs.
2. Clica Gerar logs.
3. Na consola podes ver os eventos da troca, pesquisar termos, copiar excertos e descarregar o ficheiro .log para o reveres localmente.

Termos de pesquisa recomendados: error, failed, proposal, AUTH, TS_, CHILD_SA, responding.

{/* 📸 CAPTURA 1 · consola de Resolução de problemas / Logs com o botão Gerar logs e o buscador */}

Consola de troubleshooting com a geração e pesquisa de logs

📘 Dois detalhes para não te confundires

• Fuso horário: os logs mostram a hora convertida para o teu fuso horário, para que o timestamp coincida com o momento real do teste e possas compará-lo com o log do equipamento remoto.
• Rotação por tamanho: o histórico é gerido por tamanho, não por dias. Se estiveres a perseguir uma falha concreta, reproduz-a e gera os logs logo a seguir.

As duas fases da ligação

Um túnel site-to-site estabelece-se em duas fases. Saber em qual falha leva-te diretamente à causa.

Fase 1 — Ligação inicial (IKE)

As duas extremidades validam-se e acordam a forma de comunicar. Quando corre bem, no log aparece IKE_SA ... established. Se falhar, o típico é que a outra extremidade não responda (conectividade ou portas fechadas), que as definições básicas não coincidam (por exemplo, a encriptação) ou que a chave (PSK) ou a identidade não correspondam.

Fase 2 — Passagem de dados (IPsec / CHILD_SA)

Com a ligação inicial pronta, cria-se o túnel por onde passa o tráfego real. Quando corre bem, aparece CHILD_SA ... established. Se falhar, o típico é que as sub-redes não coincidam em ambos os lados, que uma firewall ou uma política bloqueie o tráfego, ou que faltem rotas para a rede remota.

📘 Regra rápida

Se vires IKE_SA ... established mas não CHILD_SA ... established, o problema está nas redes, nas rotas ou na firewall (Fase 2). Se não chegares a IKE_SA ... established, está na ligação inicial (Fase 1).

Interpreta as mensagens do log

Checklist de diagnóstico

1. Gera logs e procura error, failed, proposal, AUTH, TS_.
2. Aparece IKE_SA ... established? Se não, estás perante um problema de Fase 1 (podes ver initiating IKE_SA sem passar daí). Se sim, continua.
3. Aparece CHILD_SA ... established? Se vires failed to establish CHILD_SA, costuma ser redes, rotas ou firewall (Fase 2). Se sim aparece, o túnel está bem; se mesmo assim não houver tráfego, vê as rotas e políticas, não o túnel.
4. peer not responding → verifica UDP 500/4500 e firewall/NAT.
5. no proposal chosen → há definições que não coincidem (encriptações, grupos, tempos).
6. AUTHENTICATION_FAILED → verifica a chave (PSK) ou certificados e IDs.
7. TS_UNACCEPTABLE → verifica que as sub-redes coincidem exatamente em ambos os lados.

Verifica do lado do cliente

Os logs dizem-te a fase; estes comandos confirmam-te a causa a partir de um servidor da tua rede.

Para a Fase 1, verifica a conectividade com o peer e que as portas IPsec estão abertas. Em Linux:

ping <IP-PEER>
nc -vzu <IP-PEER> 500
nc -vzu <IP-PEER> 4500

No Windows, conectividade básica a partir do PowerShell (as portas UDP 500/4500 devem estar abertas na firewall e NAT de ambos os lados):

Test-NetConnection <IP-PEER>

Para a Fase 2, verifica que chegas à sub-rede remota e que existe rota até ela:

ping <IP-NA-SUB-REDE-REMOTA>
ip route

route print

Quando escalar para o Partner Success

Se, depois destes passos, continuares bloqueado, a equipa de Partner Success dá-te uma ajuda. Para resolver o mais depressa possível, envia:

• Do log: o primeiro erro que aparece, 20-30 linhas antes e depois para veres o contexto, e os timestamps tal como surgem.
• Do túnel: versão de IKE (v1/v2/Auto), IP ou FQDN do peer, sub-redes local e remota em CIDR, se há NAT ou firewall pelo meio, e a hora exata do teste.

Como os logs rodam por tamanho, reproduz a falha e gera os logs logo a seguir: assim o ficheiro contém exatamente o que é preciso ver.

Conclusão

Com a consola de troubleshooting passas de "a VPN não funciona" para "falha na Fase 2 por sub-redes que não coincidem" em questão de minutos. O método é sempre o mesmo: localiza se chegas a IKE_SA established e a CHILD_SA established, e isso diz-te se estás a olhar para a ligação inicial ou para o passo de dados. A partir daí, a tabela e os comandos levam-te à causa.