O VPN cai no mesmo intervalo? Alinhe o temporizador
Uma queda em intervalo fixo é uma impressão digital. Compare a renovação de chaves do túnel, o temporizador de inatividade do NAT, a concessão DHCP e o limite da conta antes de mudar qualquer coisa.
Um túnel que morre a cada quinze minutos, ou a cada hora no mesmo minuto, diz que algum temporizador expirou, não que a rede está instável. O movimento útil é anotar o intervalo e compará-lo com os quatro temporizadores que produzem esse padrão. Mudar os limites de tempo antes dessa comparação costuma deslocar a falha sem explicá-la, o que torna a ocorrência seguinte mais difícil de ler que a primeira. A medição custa dez minutos e substitui uma semana de suposições.
Transforme o intervalo num número
Reúna cinco ou seis ocorrências e calcule o intervalo entre elas, não o intervalo desde o início do dia. Uma queda às 09:12, 10:12 e 11:12 é um limite horário; uma queda às 09:12, 09:27 e 09:42 é de quinze minutos desde a última conexão bem-sucedida. Arredonde o resultado para o temporizador mais plausível, não para o minuto mais próximo.
Registre dois momentos por evento: quando o tráfego se moveu pela última vez e quando o cliente relatou a desconexão. Eles diferem quando um túnel morre em silêncio e o cliente só percebe no envio seguinte, e é essa diferença que separa um tempo limite de inatividade de uma falha dura. Um cliente que percebe tarde infla a janela de inatividade que você mede.
Observe se a reconexão é automática. Um cliente que se reconecta em segundos mantém o intervalo visível no log e fora do relatório do usuário, e por isso essas falhas costumam ser descritas como ocasionais e não periódicas. Também esconde o evento da pessoa que usa o laptop.
Quatro temporizadores que parecem iguais
Quase toda queda repetida do túnel vem de um destes: renovação de chaves do protocolo, expiração de mapeamento inativo, evento de DHCP ou de interface, ou política de conta. Eles diferem em se havia tráfego e no que o log diz no limite.
As assinaturas abaixo merecem ser aprendidas, porque permitem descartar três explicações com uma única linha de log:
| Timer | Typical trigger | What the log shows at the boundary |
|---|---|---|
| Protocol rekey | Traffic present, fixed interval | Negotiation lines, sometimes a failure |
| NAT or firewall idle | No traffic for minutes | Silence, then a timeout on send |
| DHCP lease or link change | Half the lease, or a radio event | Address or interface churn |
| Account session limit | Wall-clock hours since login | Clean disconnect, server-side reason |
A primeira linha é um mecanismo de segurança fazendo seu trabalho, e a segunda é um dispositivo intermediário que esquece o estado. Confundi-los leva a enfraquecer a renovação ou a perseguir uma regra de firewall que nunca esteve envolvida.
Ocupado contra inativo diz qual metade
Faça uma comparação controlada com tráfego contínuo, como um fluxo longo para um host dentro do túnel, e observe se o intervalo muda. Se a queda desaparece enquanto os dados fluem, o temporizador é baseado em inatividade.
Se sobreviver ao tráfego contínuo, a causa pertence à renovação, à concessão ou à política. Esse único teste elimina metade dos candidatos em cerca de uma hora de observação, e não custa nada além de atenção.
Mantenha a rede de acesso inalterada durante o teste. Alternar entre Wi-Fi e Ethernet no meio da comparação introduz exatamente o evento de interface que você tenta distinguir de um temporizador.
Alinhe a linha de log com o limite
Leia os logs do cliente e do servidor em torno do momento registrado, não o arquivo inteiro. Uma renovação mostra negociação; uma expiração de inatividade não mostra nada até o próximo pacote; uma mudança de concessão mostra trabalho de endereço; um limite de política costuma mostrar uma desconexão administrativa limpa.
Estes comandos extraem a janela relevante de cada fonte:
grep -iE "reneg|TLS Error|Inactivity" /var/log/openvpn.log | tail -20
journalctl -u NetworkManager --since "-90 min" | grep -iE "dhcp|link"
wg showSe as três fontes concordarem com o carimbo de data e hora, você tem o dono do temporizador. Se só o log do cliente tiver algo, provavelmente o servidor não é quem encerra a sessão.
Conserte o estágio, não o ícone
Cada dono tem um reparo suportado. Uma falha de renovação exige propostas compatíveis nas duas pontas. Uma expiração de inatividade exige um keepalive ou uma expectativa de inatividade mais curta, dentro do que o caminho permite. Um evento de concessão exige ajuste da interface ou das configurações de energia. Um limite de conta é uma decisão de política, não um bug.
Desativar a renovação ou a autenticação para manter o ícone verde troca uma queda visível por uma fraqueza invisível, e deixa você sem poder dizer quando o túnel negociou chaves novas pela última vez. Teste novamente a duração original depois e guarde os carimbos de data e hora, para que o próximo evento possa ser comparado a este em vez de começar do zero.