VPN morta após a suspensão: túnel perdido ou aplicação obsoleta?

A tampa abre, o ícone sem fio volta e a VPN continua a mostrar-se ligada. A primeira página interna fica então pendurada até expirar o tempo, e um novo separador faz o mesmo. Três coisas diferentes podem produzir essa imagem e exigem três reparações diferentes: um túnel que não sobreviveu à suspensão, um perfil que ninguém pediu para reativar, ou uma aplicação que ainda mantém uma sessão que morreu há horas. Compará-las é mais rápido do que reinstalar o que quer que seja.

Três coisas podem estar partidas após acordar

O primeiro candidato é o próprio túnel. A interface pode continuar a existir com um endereço enquanto a associação com o par desapareceu, por isso uma luz indicadora não é prova de um caminho funcional. Um handshake mais antigo do que a suspensão é o indício, e basta um comando para o ver.

O segundo é a ativação. Muitos clientes reconectam-se sozinhos; outros não, e um perfil que ninguém pede para voltar fica ali com aspeto de configurado. Essa falha é silenciosa por desenho, porque nada deu erro.

O terceiro é a aplicação. Um separador do navegador, uma sessão SSH ou uma ligação a uma base de dados podem sobreviver a uma mudança de rede como descritor de ficheiro enquanto o transporte por baixo está morto. Então uma sessão nova funciona na perfeição, o que lhe diz que o túnel estava bem o tempo todo.

Compare as três antes de mudar o que quer que seja, porque as reparações não se sobrepõem. Reiniciar um cliente que nunca foi convidado a arrancar outra vez desperdiça a prova de que precisava. Anote a que candidato corresponde o sintoma antes de tocar numa configuração. Essa única frase costuma decidir o resto da investigação.

Primeiro: o túnel voltou?

Olhe para a interface e para o estado do par em vez do texto de estado do cliente. Uma interface com endereço e sem handshake recente é um túnel que só existe no nome.

ip -brief addr show
wg show
ip route show table all | head -20

Se a interface faltar por completo, o túnel não sobreviveu e a pergunta passa a ser quem o devia ter trazido de volta. Se estiver presente mas o handshake for antigo, a associação com o par tem de ser restabelecida, e o cliente pode estar à espera de tráfego que a dispare.

Verifique também as rotas e a configuração de DNS. Um túnel pode voltar sem as suas rotas, o que produz o estado confuso em que a interface está ativa e os nomes internos ainda são resolvidos pelo servidor errado.

Segundo: algo lhe pediu para voltar?

É aqui que a comparação se justifica. Um perfil de extensão OpenVPN e uma ligação nativa WireGuard são tratados de forma diferente pelo NetworkManager, e a referência das definições de ligação diz claramente que connection.autoconnect não ativa perfis de VPN; o mecanismo para levantar uma VPN com uma ligação é connection.secondaries.

nmcli connection show --active
nmcli -f connection.autoconnect,connection.secondaries connection show "Work VPN"
journalctl -u NetworkManager -b --no-pager | tail -40

Se a reconexão manual resolve o problema todas as vezes, é a assinatura de uma ativação em falta e não de um túnel partido. O registo mostrará normalmente a interface a cair e nada a trazê-la de volta.

Resista ao impulso de acrescentar um hook de suspensão de imediato. Um hook que dispara antes de a rede recuperar corre contra o próprio processo que tenta ajudar, e transforma um problema reproduzível num intermitente.

Terceiro: a aplicação mantém estado antigo?

Abra uma sessão completamente nova para o mesmo destino antes de tocar na VPN. Se a sessão nova funcionar e a antiga não, o túnel está bem e a aplicação mantém uma ligação morta.

Esta é a mais barata das três verificações e a que mais se salta, porque a janela que falha está mesmo no ecrã. Feche-a, volte a abri-la e anote se o problema sobrevive. Se a sessão nova funcionar, pare por completo a investigação do túnel. Se também falhar, a aplicação é um sintoma e não uma causa.

Algumas aplicações recuperam sozinhas após um tempo de espera, por isso o sintoma pode parecer corrigir-se sozinho ao fim de alguns minutos. Esse comportamento aponta para a aplicação e não para o túnel, e vale a pena registá-lo à parte. Um colega que diz que se corrigiu sozinho está a descrever este padrão, não uma sorte.

Torne a comparação reproduzível

Mantenha as variáveis pequenas: uma rede de acesso, uma duração de suspensão e o mesmo primeiro pedido de cada vez. Depois registe dois resultados: se a reconexão manual o repara e se outra suspensão traz a falha de volta.

É essa última observação que separa os três candidatos com mais fiabilidade. Uma sessão nova a funcionar depois de uma antiga falhada não é um problema de túnel, e nenhuma reinstalação do cliente o mudará.

O keepalive persistente do WireGuard só entra nesta imagem como keepalive de mapeamento NAT. Envia pacotes para manter um mapeamento aberto; não impede a máquina de suspender e não pode continuar a enviar enquanto o processo está suspenso.

Registe no ticket o que encontrou: qual das três coisas estava partida, o que a reparou e como o reproduziu. A próxima pessoa que abrir uma tampa numa segunda-feira agradecerá, e a resposta não terá de ser redescoberta de raiz.