Gestão de Logs de VPN e Troubleshooting

Com a nova consola de troubleshooting podes gerar, consultar e descarregar logs do túnel VPN diretamente a partir do painel e diagnosticar incidentes sem depender do suporte na maioria dos casos.

1. Introdução

Neste tutorial aprenderá a:

• Gerar logs do túnel a partir do painel.

• Procurar, copiar e descarregar o .log.

• Identificar em que fase falha a VPN (Fase 1 IKE vs Fase 2 IPsec/CHILD_SA).

• Aplicar um guia rápido “mensagem → causa provável → ação”.

• Saber quando escalar e que informação enviar para acelerar a resolução.

   

2. Pré-requisitos

• Acesso à plataforma com permissões sobre a subscrição de rede.

• Um túnel VPN criado (esteja ou não operacional).

• (Opcional) Acesso a logs do equipamento remoto para correlacionar se precisares de ir mais além.

   

3. Como gerar e consultar logs a partir do painel

1. Aceda à sua subscrição com VPN e entre em Troubleshooting / Logs.

2. Clique em Gerar logs.

3. Na consola poderá:

• Ver os eventos da troca de dados.

• Procurar termos (recomendado: error, failed, proposal, AUTH, TS_, CHILD_SA, responding).

• Copiar fragmentos relevantes (para suporte ou para sua análise).

• Descarregar o ficheiro .log para revê-lo localmente.

   

Duas notas importantes para evitar confusões

• Fuso horário: os logs mostram a data e hora convertidas para o seu fuso horário, para que os eventos coincidam com a hora real em que fez o teste. Assim pode comparar facilmente esses timestamps com os registos do equipamento remoto e confirmar que estão a olhar para o mesmo momento da falha.

• Rotação de logs: o histórico é gerido por tamanho, não por “últimos X dias”.
  Se precisar de capturar uma falha concreta: reproduza o problema e gere logs logo de seguida.

   

4. Troubleshooting Fase 1 vs Fase 2

Para entender como pode falhar uma VPN site-to-site tem de compreender estes dois passos:

Fase 1 — Ligação inicial (IKE)

Aqui as duas extremidades põem-se de acordo para poderem “falar”: validam-se entre si e acordam como se vão ligar.
Se falha esta fase, o mais típico é:

• A outra extremidade não responde (conectividade ou portas fechadas).

• Não coincidem alguns ajustes básicos (por exemplo, tipo de cifragem).

• A chave (PSK) ou a identificação não coincide.

Nos logs, quando isto corre bem costuma aparecer: IKE_SA ... established.

Fase 2 — Passagem de dados (IPsec)

Uma vez que a ligação inicial está OK, cria-se o túnel por onde irá o tráfego real entre redes.
Se falha esta fase, o mais típico é:

• As redes/sub-redes configuradas não coincidem em ambos os lados.

• Existe uma firewall ou uma política a bloquear o tráfego.

• Faltam rotas para chegar à rede remota.

Nos logs, quando isto corre bem costuma aparecer: CHILD_SA ... established.

Regra rápida

• Se vê IKE_SA ... established mas não vê CHILD_SA ... established → o problema costuma estar em redes/rotas/firewall (fase 2).

• Se não chega a IKE_SA ... established → o problema está na ligação inicial (fase 1).

   

5. Guia rápido de interpretação de logs

6. Checklist de diagnóstico passo a passo

Gere logs e procure: error, failed, proposal, AUTH, TS_.

• Veja se aparece IKE_SA ... established:

  • Não aparece → está perante um problema de ligação inicial (Fase 1).

  • Sim, aparece → passe ao ponto seguinte.

• Verifique se aparece CHILD_SA ... established:

  • Não aparece → costuma ser uma questão de redes/rotas/firewall (Fase 2).

  • Sim, aparece → o túnel está bem; se não houver tráfego, costuma ser rotas ou políticas (não o túnel).

• Se vê peer not responding → reveja UDP 500/4500 e firewall/NAT.

• Se vê no proposal chosen → existem ajustes que não coincidem (cifragens/grupos/tempos).

• Se vê AUTHENTICATION_FAILED → reveja a chave (PSK) ou certificados/IDs.

• Se vê TS_UNACCEPTABLE → reveja se as sub-redes coincidem exatamente em ambos os lados.

   

7. Como podemos ajudar a partir de Partner Success e que informação nos ajudará a dar-te suporte mais rápido

Se depois de realizar estes passos continuar a ter dificuldades, teremos todo o gosto em ajudar a partir de Partner Success.

Para agilizar o suporte e podermos encontrar a solução o quanto antes, é muito útil que nos envie o seguinte:

Do log:

• O primeiro erro que aparece.

• 20–30 linhas antes e depois (para ver o contexto).

• Os timestamps (data e hora) tal como aparecem.

Do túnel/configuração:

• Versão de IKE (v1/v2/Auto).

• IP ou FQDN do peer remoto.

• Sub-redes locais e remotas (CIDR).

• Se existe NAT ou firewall pelo meio.

• A hora exata em que fez o teste.

Como os logs rodam por tamanho, tente reproduzir a falha e gerar logs logo de seguida, para que o log contenha exatamente o que precisamos de ver.

8. Conclusão

Como pode ver neste tutorial, a consola de troubleshooting pode poupar muitas dores de cabeça e dar um diagnóstico claro em poucos minutos.