A VPN não para de desconectar? Siga esta ordem

Antes de reinstalar o cliente, anote três coisas: quanto tempo o túnel ficou ativo, o que o cliente disse ao cair e se a máquina dormiu ou trocou de rede nesse meio-tempo. Essa nota é a única prova que você terá depois, e uma reinstalação geralmente a apaga. Uma queda em intervalo repetível é um temporizador ou uma expiração de estado; uma queda em um momento aleatório é um problema de caminho. A ordem abaixo evita que você mude três coisas ao mesmo tempo e não aprenda nada.

Primeiro passo: registre o intervalo e o texto do erro

Comece pelo log do próprio cliente, e não pelo painel do provedor. Em um cliente Linux, o log do serviço mais o estado ao vivo do túnel cobrem a maior parte disso:

journalctl -u openvpn-client@client --since '3 hours ago' | tail -60
journalctl -u wg-quick@wg0 --since '3 hours ago' | tail -40
wg show
ip -s link show wg0

Anote os carimbos de data e hora do último handshake bem-sucedido e o momento em que o tráfego parou, não apenas o momento em que o ícone mudou de cor. Um cliente GUI que diz desconectado depois do fato pode estar relatando um estado que o kernel alcançou segundos antes.

Mantenha a redação do erro. Um tempo esgotado, uma recusa de autenticação e um erro de adaptador ou driver apontam para três camadas diferentes, e a maior parte do esforço perdido neste problema vem de tratá-los como um só. Copie a linha literalmente para a sua nota.

Segundo passo: mude uma variável, não o perfil

Mantenha o dispositivo e o perfil fixos e leve a máquina para outra rede de acesso, como um hotspot de celular. Este é o teste mais barato que separa o cliente do caminho. Execute-o por tempo suficiente para cobrir o intervalo de falha original; dois minutos estáveis não provam nada sobre uma queda que ocorre no trigésimo minuto.

Um notebook com porta Ethernet dá uma segunda comparação que tira o Wi-Fi completamente da equação. Se o túnel se mantém nas duas alternativas, a rede de acesso original merece atenção: roaming entre pontos de acesso, um roteador doméstico com a tabela de tradução expirando ou um link upstream que reinicia fluxos longos.

Anote qual variável você mudou. Uma comparação só conta quando todo o resto permaneceu igual, e isso inclui o endpoint do servidor e a hora do dia.

Terceiro passo: relacione o intervalo a uma camada

A duração de uma boa sessão é o número único mais informativo que você tem. Leia-o em relação a esta lista antes de tocar nos temporizadores:

• Queda depois de suspender ou retomar: o estado do túnel sobreviveu à suspensão, mas a interface não. Verifique o comportamento de reconexão do cliente ao retomar e se o serviço reinicia o túnel ou espera tráfego.
• Queda só quando está ocioso: algo no meio deixou o fluxo expirar. É exatamente para esse caso que existem os keepalive.
• Queda em uma idade de sessão fixa: um evento de reautenticação ou de renovação de chave, não uma falha de caminho. Uma recusa explícita no log exatamente nesse intervalo é o sinal.
• Queda durante transferências grandes ou páginas grandes: suspeite do MTU e da fragmentação, não de um temporizador de inatividade.

Para o caso ocioso, as configurações são específicas do protocolo e as duas pontas importam. O keepalive 10 60 do OpenVPN no servidor envia um ping a cada 10 segundos e reinicia o link após 60 segundos sem ele; clientes WireGuard atrás de NAT usam PersistentKeepalive = 25 no bloco de par. OpenVPN também renegocia o canal de dados por temporizador, reneg-sec, que por padrão é 3600 segundos na versão 2.x.

Não copie valores agressivos do guia de outro provedor. Um tempo curto em um link móvel com perdas produz exatamente as desconexões que deveria evitar, e os valores enviados pelo servidor substituem o que você define no perfil do cliente.

Quarto passo: compare uma alternativa suportada

Se o operador publica tanto um perfil UDP quanto um TCP, execute o mesmo dispositivo e a mesma rede contra o outro. Use o arquivo correspondente real em vez de editar o transporte em um perfil copiado. Um perfil TCP estável em um caminho onde o UDP é reiniciado restringe o problema a esse caminho; não prova que o TCP seja o melhor transporte em todos os lugares.

A mesma lógica vale para os endpoints. Experimente outro servidor e mantenha o resultado original ao lado. Se apenas uma saída reinicia sessões, isso é evidência sobre aquele endpoint, não motivo para reconstruir cada adaptador do notebook.

Depois de qualquer mudança, repita o gatilho original e confirme para onde o tráfego realmente vai. Acesso à internet recuperado não é o mesmo resultado que tráfego dentro do túnel, e um cliente que caiu silenciosamente para uma rota direta parece saudável pelo navegador.

Verifique a correção e mantenha o rollback

Uma correção é verificada reproduzindo o gatilho original, não por uma conexão bem-sucedida. Deixe o túnel ocioso além do intervalo de falha antigo, suspenda e retome uma vez, e depois verifique a idade do handshake e o endereço de saída:

wg show wg0 latest-handshakes
curl -m 5 -sS https://ifconfig.me
cp client.ovpn client.ovpn.bak   # before editing timers

Mantenha o perfil anterior e os valores de temporizador anteriores até o novo comportamento sobreviver a um dia inteiro de trabalho. Se as quedas voltarem, restaure o backup e depois reaplique as mudanças uma a uma, para que a segunda tentativa comece de um estado conhecido.

Se o log continuar limpo e o túnel ainda cair em um intervalo repetível, o próximo destino é o lado do servidor para aquela sessão. Leve o identificador de sessão do cliente e o horário exato da queda, porque é esse par que torna um log de servidor pesquisável. As opções de link do protocolo estão documentadas no manual do OpenVPN 2.6 quando você precisa do significado exato de um valor.