VPN presa depois de reiniciar o router: três coisas que mudaram

O router termina de arrancar, o portátil volta a associar-se ao mesmo SSID, e a VPN fica em ligado sem nada se mexer. O perfil guardado está intacto. O que expirou por baixo foi o caminho, e o cliente ainda mantém o estado que construiu para o antigo.

Três condições decidem a correção. Verifique-as por ordem, porque as seguintes são esforço perdido se a primeira já explica o bloqueio.

Primeira condição: o endereço local mudou

Um reinício pode atribuir à máquina um endereço diferente. Uma VPN configurada com um ponto final local fixo passa então a usar uma ligação que já não existe. O mesmo se aplica a um cliente que ligou o seu socket ao endereço antigo. A interface do túnel pode continuar ativa enquanto cada pacote que produz vai para um sítio inútil.

Compare o endereço que o cliente usa com o endereço que a interface tem agora. Uma rota predefinida que aponta para um gateway que também mudou é a mesma classe de problema com outro nome.

ip -4 addr show
ip route show default
ip route get 203.0.113.10

Segunda condição: o mapeamento traduzido desapareceu

Os routers domésticos traduzem os fluxos de saída, e esses mapeamentos vivem na memória. Um reinício apaga todos eles. Isso é inofensivo para uma ligação nova e fatal para um túnel que acredita que o seu fluxo existente ainda é válido. Então o outro lado não vê nada, pelo que o cliente nunca recebe um erro sobre o qual possa agir.

É aqui que um túnel sem keepalives encrava em silêncio em vez de falhar ruidosamente. As limitações documentadas do WireGuard descrevem a mesma forma de falha. Um estado de ponto final errado produz pacotes descartados em vez de um diagnóstico.

Um keepalive persistente de 25 segundos é a mitigação habitual, porque renova o mapeamento antes de um tempo limite de inatividade poder expirar. Não repara um mapeamento que já desapareceu. Combine o keepalive com lógica de reconexão em vez de o tratar como uma correção.

Terceira condição: o endereço público mudou

Se o endereço externo do próprio router mudou, tudo do outro lado que filtra por endereço de origem passa a ver um par diferente. O túnel pode subir e o servidor pode continuar a descartar o tráfego, o que parece um cliente avariado e na realidade é uma política do outro extremo.

Registe o endereço externo antes e depois do reinício. Quando os dois diferem, a questão passa do cliente para quem mantém a lista de autorizados, e redefinir as credenciais no portátil não pode ajudar.

Recupere pela ordem correta

Conclua primeiro qualquer início de sessão obrigatório no portal cativo, depois deixe o cliente reconectar-se pelo seu procedimento suportado em vez de matar o processo. Observe se tanto a identidade como o tráfego de dados regressam, porque são duas fases diferentes da mesma ligação.

Uma página em cache não prova nada, e uma aplicação de conversação que se reconectou sozinha também não. Teste o ponto final que realmente lhe importa com um pedido novo. Mantenha a política de tráfego direto durante a interrupção, porque uma tentativa de reconexão não é um bloqueio.

Quando isto se repete após cada reinício, o registo importa mais do que a nova tentativa. Registe o endereço local, o gateway, o endereço externo e o estado do cliente antes e depois, e compare as duas colunas. Isso transforma uma queixa vaga num erro de ciclo de vida que alguém pode corrigir, e evita que os certificados sejam substituídos pela terceira vez por causa de um tempo limite do mapeamento.