WireGuard falha após a inatividade: teste primeiro a direção

Quatro perguntas precedem qualquer mudança de configuração: o mesmo recurso funciona enquanto o cliente está ativo, quanto durou o período de inatividade, o dispositivo dormiu ou mudou de rede, e a falha aparece apenas no tráfego iniciado pelo outro lado. As respostas separam um mapeamento NAT expirado de um rádio adormecido e de um aplicativo desatualizado. Elas também dizem se um keepalive é sequer relevante. Comece pela direção, porque custa um comando e elimina metade das causas possíveis.

Qual direção falha?

Uma nova requisição de saída do cliente e o tráfego que chega até ele após um período de silêncio testam o equipamento com estado de formas diferentes. Pacotes de saída reconstroem um mapeamento ao partir, enquanto pacotes de entrada precisam que o mapeamento antigo tenha sobrevivido. Essa assimetria é o teste inteiro. Se o cliente consegue sair mas nada entra, o mapeamento provavelmente expirou, e se nenhum dos dois funciona, o túnel ou o acesso de rede do cliente desapareceu.

Anote quanto durou o período de silêncio e se o dispositivo dormiu ou passou para outra rede nesse meio-tempo. Esses dois fatos mudam o diagnóstico antes de qualquer configuração.

wg show wg0 latest-handshakes
wg show wg0 endpoints
wg show wg0 transfer

Execute esses três antes e depois do período de silêncio, porque cada um responde a uma parte diferente da pergunta. Um carimbo de tempo de handshake que não se moveu diz que as partes pararam de falar, enquanto um endpoint que mudou diz que o mapeamento se deslocou em vez de morrer. Os contadores de transferência mostram se algo chegou, e essa é a diferença entre um mapeamento antigo e um aplicativo silencioso. Anote os números nos dois pontos, porque a comparação é a prova.

Sono, rádio e estado do aplicativo

Num telefone ou laptop, um dispositivo adormecido pode ter perdido totalmente o acesso à rede, e um keepalive não consegue restaurar um rádio desligado nem concluir um portal cativo que não foi satisfeito. As plataformas móveis suspendem o trabalho em segundo plano por política, então se o tráfego periódico continua depende da plataforma e do que o aplicativo negociou com ela. Uma conexão em cache é o terceiro caso e o mais enganoso, porque o retorno do túnel não é o mesmo que a reconexão do aplicativo a ele.

Reabra o aplicativo após o período de inatividade em vez de confiar na aba que ficou aberta. Se uma nova requisição funciona onde a sessão antiga falhou, o túnel nunca foi o problema.

O que um keepalive realmente faz

PersistentKeepalive envia periodicamente um pacote vazio autenticado a um par, o que basta para manter um mapeamento NAT vivo entre pares e para manter o endpoint do outro lado atualizado, como descreve o início rápido do WireGuard. Ele não repara um rádio adormecido, uma rota perdida ou um aplicativo que nunca tenta de novo. Escolha o intervalo pelas configurações compatíveis do cliente e não ative um valor agressivo em toda parte só porque uma tela de status fica em silêncio.

A maioria dos períodos de inatividade não são falhas. Um túnel que se reconecta após cinco minutos de silêncio se comporta corretamente, e o problema é apenas o caso em que algo deveria chegar do outro lado.

Espere o intervalo que antes falhava

Faça uma mudança compatível e deixe passar o mesmo período de inatividade antes de testar aquele recurso de novo. Esperar faz parte do teste e não é formalidade. O sucesso imediato após uma reconexão não diz nada sobre um sintoma de inatividade longa, porque a reconexão é exatamente o evento que reinicia o estado. Se o problema também aparece durante o uso ativo, volte às verificações de handshake e de caminho de dados em vez de adicionar mais tráfego periódico.

Mantenha uma mudança por teste e anote a duração de inatividade usada. Sem isso, cada comparação posterior se desvia e ninguém pode dizer qual mudança importou. Registre os quatro fatos juntos: direção, duração, estado de sono e comportamento do aplicativo.