O VPN desconecta sem parar: teste o rádio antes do servidor

Uma desconexão de VPN pode começar muito antes de qualquer tráfego chegar ao servidor. A perda do Wi-Fi, uma passagem do Wi-Fi para a rede móvel, o congestionamento no ponto de acesso local e um telefone que adormece podem interromper o caminho externo enquanto o software do túnel relata uma falha limpa. Avance do dispositivo para fora: primeiro o enlace, depois os eventos do próprio cliente, depois uma comparação controlada e só então o servidor. Essa ordem evita que você troque nós de saída por um problema que mora na sala.

Olhe o enlace, não o ícone de sinal

Procure transições do enlace em vez de barras. Um dispositivo pode mostrar sinal forte enquanto o ponto de acesso está saturado, enquanto uma passagem de roaming está em curso ou enquanto uma política de economia de energia desliga o rádio com a tela apagada.

Registre o estado da interface, o gateway atual e o horário de cada mudança. Depois verifique se a desconexão coincide com a transição. Uma queda que ocorre sempre que o telefone se move entre salas é um problema de enlace até que se prove o contrário, não importa qual servidor o aplicativo mostre.

Leia os eventos de reconexão do cliente

A maioria dos clientes registra um motivo da desconexão e um carimbo de tempo para a próxima tentativa. Um túnel que renegocia em poucos segundos e depois funciona é um evento diferente de um que fica fora do ar até você ligá-lo manualmente.

Reconexões curtas repetidas apontam para o caminho externo, porque o cliente continua alcançando o servidor e perdendo a sessão. Um túnel que fica fora do ar aponta para autenticação, uma mudança de endpoint ou uma política, porque o cliente não chega longe o bastante para perder algo. Leia os dois padrões separadamente antes de tocar na configuração.

Compare um segundo endpoint com cuidado

Um segundo endpoint é uma comparação útil e não é, por si só, um experimento controlado. Ele muda a rota, a infraestrutura e muitas vezes o país, então uma diferença entre dois endpoints não prova que o primeiro servidor tenha defeito.

Mantenha o dispositivo, a rede de acesso e a carga de trabalho fixos e anote o que mais mudou quando você trocou. Se os dois endpoints falham no mesmo momento no mesmo lugar, o caminho local é o fator comum. Se apenas um falha, o servidor ou a rota até ele passa a ser a pista. Anote os fatores de confusão para que a conclusão não ultrapasse as evidências.

Correlacione com o servidor que você administra

Se você administra o endpoint, faça o horário da tentativa coincidir com os registros de escuta e de associação. Vários clientes sem relação que falham no mesmo gateway são uma evidência diferente de um único telefone que cai sempre que se move.

Uma resposta de um par não estabelece saúde contínua do aplicativo. Após a recuperação, teste o recurso de que você realmente precisa, porque um aperto de mão bem-sucedido e um servidor alcançável podem coexistir com um caminho de aplicativo quebrado.

Escreva o relatório que o delimita

Separe quatro afirmações: perda do enlace local, alcance externo, negociação do túnel e o próprio estado do aplicativo. Cada uma tem sua evidência, e um relatório que as mantém distintas diz à próxima pessoa onde olhar.

Anote também os limites da comparação. Se uma política impediu um teste de caminho direto, diga isso em vez de apresentar a comparação de endpoints como prova. O rótulo de país no aplicativo não identifica a rota completa, e um servidor geograficamente próximo ainda pode ser alcançado por um caminho congestionado.

A página de limitações conhecidas do projeto WireGuard é um lembrete útil de que um protocolo pode estar correto e ainda assim deixar o comportamento do enlace para o sistema operacional. Termine repetindo o mesmo teste após a próxima desconexão, porque um único evento é um dado e um padrão é um diagnóstico.