Keepalive não é uma reconexão: escolha pelo tipo de falha que você tem

Keepalives e reconexões são configurados no mesmo fôlego mas resolvem problemas diferentes, e é por isso que ajustar um raramente corrige o outro. Um keepalive envia tráfego pequeno para manter uma entrada de estado viva ou para notar que um peer parou de responder. Uma reconexão derruba o que está quebrado e reconstrói a relação, incluindo chaves, endereços e rotas. Escolha o mecanismo que corresponde à falha, não aquele cujo botão você já conhece. Duas perguntas decidem: o caminho está morto, ou algo entre os peers está esquecendo dele?

Quando o mapeamento é o problema

Um túnel que morre só depois de minutos de silêncio costuma perder uma entrada de tradução e não um peer. O PersistentKeepalive do WireGuard existe para estado de NAT e firewall, e as notas do próprio projeto descrevem-no exatamente assim, não como uma verificação de saúde. Um intervalo de algumas dezenas de segundos mantém a entrada quente, enquanto um pacote por segundo é uma decisão de bateria e não de confiabilidade. OpenVPN chega ao mesmo ponto através de ping e ping-restart , que notam o silêncio primeiro e depois agem sobre ele.

Essas configurações também não são intercambiáveis entre protocolos. Uma política de peer morto do IKEv2, um temporizador ping do OpenVPN e um keepalive do WireGuard respondem à mesma pergunta com três sintaxes e três padrões diferentes, então copiar um número entre eles é adivinhação vestida de ajuste.

Quando a relação se foi

Se o peer muda de endereço, a credencial expira ou o extremo remoto reinicia, pacotes pequenos não são o reparo. A reconexão tem de reconstruir o estado : obter um endereço, reinstalar as rotas, renegociar as chaves e, em algumas implantações, reautenticar um usuário.

Os clientes que se reconectam sem supervisão guardam um certificado ou um segredo armazenado. Um cliente que perguntaria a um humano falha exatamente quando ninguém está presente, e esse é o cenário em que a reconexão importava. É uma decisão de projeto tomada meses antes, não uma configuração que você muda durante uma queda.

O que nenhum dos dois prova

Um túnel pode estar reconectado, com chaves e rotas, enquanto o serviço por trás está fora do ar, e um keepalive pode manter um mapeamento aberto para uma sessão cujo servidor sumiu há horas. Os dois mecanismos podem relatar sucesso enquanto o que você realmente quer proteger está indisponível.

Por isso o teste termina num pedido real. Envie algo pelo túnel depois do intervalo que lhe importa e então provoque separadamente a falha para a qual você projetou: um período de inatividade para o caso do mapeamento, um reinício ou uma mudança de endereço para o caso da reconexão.

Bloquear o tráfego direto é uma decisão à parte

Um ciclo de reconexão pode estar perfeitamente saudável enquanto uma aplicação usa discretamente a rota comum, e isso é um vazamento, não uma falha. Se o requisito é que nada saia fora do túnel, diga isso explicitamente na configuração do cliente e prove-o baixando o túnel e observando o que ainda conecta. Nenhum dos dois mecanismos implica esse comportamento, e nenhuma disciplina de repetição o estabelece.

Registe qual mecanismo correu e se um novo pedido funcionou depois. Esses dois factos são o que o próximo engenheiro precisa, e nenhum deles é visível num ícone de estado. Uma linha de log a dizer que o cliente se reconectou não é o mesmo que um pedido que funcionou.

Escreva a política, não apenas o número

Ponha o par numa frase: o intervalo de inatividade, o limiar de vivacidade, o que desencadeia uma reconstrução , e o que o cliente faz enquanto tenta de novo. Sem essa frase, cada incidente futuro reabre a mesma discussão sobre se o keepalive é curto demais ou a reconexão lenta demais.

As notas do WireGuard sobre limitações são um lembrete útil de que o keepalive é uma solução de contorno para middleboxes e não um desenho geral de vivacidade. Leia essa limitação antes de aumentar a frequência em resposta a um problema que ela não consegue resolver.