> For the complete documentation index, see [llms.txt](https://docs.plenit.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.plenit.com/docs-pt/productos/servers/how-to/vpn-logs-and-troubleshooting.md).
# Como gerir os logs da tua VPN e diagnosticar incidentes
A consola de resolução de problemas deixa-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 consegues
>
> Localizar o ponto exato da falha (a ligação inicial ou a passagem de dados) e a ação que a corrige, sem depender do 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 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 em **Gerar logs**.
3. Na consola podes **ver** os eventos da troca, **procurar** termos, **copiar** fragmentos e **descarregar** o ficheiro `.log` para o rever localmente.
Termos de pesquisa recomendados: `error`, `failed`, `proposal`, `AUTH`, `TS_`, `CHILD_SA`, `responding`.
{/\* 📸 CAPTURA 1 · consola Resolução de problemas / Logs com o botão Gerar logs e o buscador \*/}
> #### 📘 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 o possas comparar 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 o problema e gera os logs logo depois.
### As duas fases da ligação
Um túnel site-to-site é levantado em duas fases. Saber em qual falha leva-te diretamente à causa.
#### Fase 1 — Ligação inicial (IKE)
Os dois extremos são validados e acordam como vão comunicar. Quando corre bem, no log aparece `IKE_SA ... established`. Se falha, o habitual é o outro extremo não responder (conectividade ou portas fechadas), que não coincidam definições básicas (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 falha, o habitual é as sub-redes não coincidirem em ambos os lados, um firewall ou uma política bloquear o tráfego, ou faltarem rotas para a rede remota.
> #### 📘 Regra rápida
>
> Se vires `IKE_SA ... established` mas não `CHILD_SA ... established`, o problema está em redes, rotas ou 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** aparecer, o túnel está bem; se mesmo assim não houver tráfego, olha para rotas e políticas, não para o túnel.
4. `peer not responding` → verifica o 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.
### Confirma 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:
```bash
ping
nc -vzu 500
nc -vzu 4500
```
No Windows, conectividade básica a partir do PowerShell (as portas UDP 500/4500 devem estar abertas em firewall e NAT de ორივos os lados):
```powershell
Test-NetConnection
```
Para a Fase 2, verifica que chegas à sub-rede remota e que existe rota para ela:
```bash
ping
ip route
```
```powershell
route print
```
### Quando escalar para Partner Success
Se, depois destes passos, continuares bloqueado, a equipa de Partner Success dá-te uma ajuda. Para resolver isso o mais depressa possível, envia:
* **Do log**: o primeiro erro que aparece, 20-30 linhas antes e depois para ver o contexto, e os timestamps tal como aparecem.
* **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 entre os dois, e a hora exata do teste.
Como os logs rodam por tamanho, reproduz a falha e gera os logs logo depois: assim o ficheiro contém exatamente o que é preciso ver.
### Conclusão
Com a consola de resolução de problemas 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 a passagem de dados. A partir daí, a tabela e os comandos levam-te à causa.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://docs.plenit.com/docs-pt/productos/servers/how-to/vpn-logs-and-troubleshooting.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
