Quedas intermitentes de VPN: o que registar em cada ocorrência
Uma queda intermitente é um problema de dados antes de ser um problema de configuração. Registre cinco campos em cada incidente e compare as etapas antes de mudar ajustes.
As quedas intermitentes são um problema de recolha de dados antes de serem um problema de configuração. Registre os mesmos campos em cada ocorrência, ou os incidentes não podem ser comparados. Mudar três ajustes depois de cada evento destrói a única prova que tinha.
O procedimento abaixo leva cerca de dois minutos por incidente e produz uma linha por evento. Pressupõe acesso só de leitura num dispositivo que você administra.
Fixe os campos antes da primeira falha
Prepare a lista de campos antes que algo se estrague, porque um modelo inventado a meio de um incidente falha sempre uma coluna. Cinco campos bastam para começar: a hora local com o respetivo desvio, o gatilho, a etapa que falhou, o texto exato do erro e se uma nova tentativa teve êxito.
O gatilho merece o seu próprio vocabulário: inatividade, retoma após suspensão, mudança de rede, pico de carga, renovação de credenciais ou desconhecido. Deixe desconhecido marcado como desconhecido em vez de o preencher mais tarde de memória. O campo da etapa é o mais valioso, porque registra onde a cadeia parou e não o que o utilizador sentiu. O texto do erro deve ser copiado à letra, porque uma paráfrase perde a distinção entre dois códigos semelhantes.
Deixe as lacunas como lacunas. Um modelo que obriga a responder convida a inventar, e um contexto inventado é pior do que um espaço vazio.
| Field | Example | Why it earns its place |
|---|---|---|
| Time with offset | 2026-11-03T09:14+08:00 | Orders events across sources in different zones |
| Trigger | resume from sleep | Separates a cause from a coincidence |
| Stage | handshake ok, no route | Names the boundary that failed |
Registre os mesmos cinco factos na falha
Execute os mesmos comandos pela mesma ordem todas as vezes. Dois minutos de saída valem mais do que uma fotografia do ícone na bandeja, e a sequência importa quando as marcas temporais não coincidem mais tarde.
date -Is journalctl -u wg-quick@wg0 --since "-2 min" --no-pager wg show wg0 latest-handshakes transfer ip route get 203.0.113.10 ping -c 3 -W 2 192.0.2.1
A primeira linha marca a observação com um desvio, e é a única forma de conciliar três fontes registadas em zonas diferentes. O extrato do registo cobre o ciclo de vida do serviço, e a linha do handshake diz se o par respondeu. A consulta de rota nomeia a interface que um destino concreto usaria, e isso não é o mesmo facto que a existência da interface. Um ping ao endereço do túnel mostra se algo atravessa a ligação, não se o outro lado está acessível.
Escreva uma linha por incidente num registo contínuo, só com esses campos e nada mais. Depois de cinco ou seis entradas, ordene pelo gatilho e depois pela etapa. Os padrões aparecem como pares repetidos, e um par que nunca se repete é provavelmente coincidência.
Localize a etapa que falhou
A conetividade local, o estado do par, as rotas e a resolução de nomes falham em sítios diferentes, e cada um deixa o seu próprio rasto. Se a interface existe mas nenhuma rota aponta para ela, a falha é de política local. Se a marca temporal do handshake deixa de avançar enquanto a interface se mantém ativa, a falha está mais acima.
A resolução de nomes pertence ao mesmo registo. Um resolvedor que na segunda-feira seguia o túnel e na terça a rede local produz falhas que parecem aleatórias na camada de aplicação.
Para acesso autorizado ao servidor, correlacione a mesma tentativa e não uma reconexão próxima. Preserve as marcas temporais originais e anote qualquer desvio à parte, porque convertê-las no local apaga a prova da conversão. Uma tentativa, um conjunto de marcas temporais, uma conclusão.
Compare uma condição de cada vez
Uma comparação controlada muda uma condição significativa e mantém a execução falhada ao lado da bem-sucedida. Mova o dispositivo para outra rede, ou desative uma exclusão, e não mude mais nada no mesmo passo.
Mantenha a execução falhada no registo. Apagá-la a favor da que funciona descarta a única prova do limite que tenta localizar.
Partilhe um extrato, não o perfil
Antes de enviar qualquer coisa, remova palavras-passe, tokens, chaves privadas, identidades alheias e cargas úteis. Um perfil completo é um segredo de configuração e não um resumo de ligação, e não pertence a um ticket.
Envie o extrato com os cinco campos e diga qual etapa pensa que falhou. Isso permite ao administrador examinar o limite que nomeou em vez de percorrer capturas de ecrã de um ícone desligado. Se o limite continuar pouco claro, o passo seguinte é outro registo controlado, não outra mudança de ajustes.