> 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-2/how-to/vpn-logs-and-troubleshooting.md).
# 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 \*/}
> #### 📘 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:
```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 na firewall e NAT de ambos os lados):
```powershell
Test-NetConnection
```
Para a Fase 2, verifica que chegas à sub-rede remota e que existe rota até ela:
```bash
ping
ip route
```
```powershell
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.
---
# 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-2/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.
