Corrigir quedas de VPN em inatividade: uma lista de verificação para a poupança de energia Wi-Fi

O seu túnel morre depois de o portátil ficar um tempo sem ser tocado, e volta no momento em que toca no trackpad. Esse padrão indica que a ligação sem fios está a entrar em poupança de energia, e não que o gateway VPN esteja a rejeitar as suas credenciais. Uma manhã movimentada no mesmo perfil é a prova: o túnel sobrevive enquanto o tráfego flui e cai quando o rádio fica em silêncio. Percorra as verificações abaixo por ordem, pare na primeira que falhar e só então mude uma definição.

Verificação um: a queda segue a inatividade?

Comece por provar a correlação em vez de a assumir. Anote a hora de relógio do último pacote enviado, a hora a que o cliente reportou o túnel em baixo e se o ecrã se desligou entretanto. Se o intervalo for o mesmo todas as vezes, tem um problema no caminho de inatividade; se as quedas surgirem ao acaso durante o uso ativo, salte para a verificação cinco.

Um teste barato que não custa nada anular: envie um ping constante de ritmo baixo para o seu gateway durante vinte minutos e deixe a máquina sozinha. Se o túnel aguentar o tempo todo, o tráfego pequeno constante está a mascarar o sintoma em vez de o corrigir, o que continua a ser evidência útil. Guardo a saída desse ping num terminal de rascunho e depois comparo-a com o registo do cliente, porque os dois relógios raramente concordam.

Verificação dois: é apenas tráfego VPN?

Antes de culpar o túnel, descubra se a própria ligação ainda é utilizável. Enquanto o túnel está morto mas o ecrã ainda desligado, tente alcançar o endereço do ponto de acesso e um anfitrião público por IP. Se o ping normal também falhar, o rádio ou o ponto de acesso largaram-no, e o cliente VPN é apenas espetador.

Se o tráfego normal flui enquanto o túnel está silencioso, a ligação está saudável e o problema está nos temporizadores do próprio túnel ou na forma como o cliente gere uma retoma. São duas correções diferentes, por isso não salte este passo. Num portátil com Wi-Fi e Ethernet ao mesmo tempo, desligue o cabo e repita o teste de inatividade: uma queda de inatividade que desaparece em Ethernet por cabo é uma evidência forte para a camada sem fios.

Verificação três: leia o estado de poupança de energia

A maioria dos ambientes de trabalho dá-lhe uma caixa de seleção, mas a caixa não é o estado em que o controlador está. Leia primeiro o relatório do próprio controlador e depois decida. No Linux com mac80211 a interface responde diretamente:

iw dev wlan0 get power_save          # on or off, per interface
sudo iw dev wlan0 set power_save off # diagnostic only, lost on reconnect

O segundo comando é um teste, não uma correção. Não sobrevive a uma desconexão, suspensão ou reinício, o que o torna uma forma limpa de verificar a hipótese sem deixar alterações permanentes.

No Windows powercfg /q SCHEME_CURRENT imprime o esquema ativo, e a subárvore do adaptador sem fios mostra se o adaptador pode receber ordem para poupar energia; a mesma escolha também está no Gestor de Dispositivos no separador de gestão de energia do adaptador. No macOS a poupança de energia 802.11 por interface não lhe é exposta, por isso veja em vez disso pmset -g para o comportamento de suspensão e espera. Aí a falha costuma revelar-se o caminho de suspensão e despertar e não o comportamento de inatividade do rádio.

Verificação quatro: mude uma coisa e teste de novo

Mude exatamente uma variável por execução e repita a mesma carga. Se o túnel agora aguentar uma hora de inatividade com a poupança de energia desligada, aprendeu algo real. Se continuar a cair, reverta antes de testar a ideia seguinte, senão fica com três definições sobrepostas e sem ideia de qual importa.

Manter a ligação viva é a outra variável independente e é constantemente confundida com poupança de energia. O PersistentKeepalive = 25 do WireGuard mantém um mapeamento NAT quente;OpenVPN em ambas as pontas keepalive e ping-restart utiliza. Ambos geram tráfego num túnel que de outra forma estaria silencioso, por isso uma manutenção de ligação que parece corrigir a queda pode estar a esconder um problema de rádio em vez de o resolver. Teste-os em separado, um de cada vez:

[Peer]
PublicKey = ...
Endpoint = vpn.example.net:51820
PersistentKeepalive = 25

Verificação cinco: quando o rádio é inocente

Se as quedas de inatividade continuarem com a poupança de energia desligada e a manutenção de ligação ativa, olhe para fora do portátil. Os pontos de acesso e os routers domésticos deixam expirar entradas NAT ou de sessão inativas segundo o seu próprio calendário, e um servidor VPN pode largar uma sessão sem tráfego.O roaming entre pontos de acesso que partilham o mesmo SSID também pode reiniciar a ligação sem que o cliente o diga claramente.

Depois compare com um segundo dispositivo na mesma rede que faça o mesmo teste de inatividade. Dois dispositivos a cair no mesmo intervalo são uma história de caminho ou de servidor; um só a cair é uma história de controlador ou de energia local. Essa comparação custa dez minutos e poupa-lhe reescrever a configuração errada.

Antes de o tornar permanente

Decida o que está disposto a manter. Um script por perfil que desliga a poupança de energia apenas nas redes onde viu a queda é defensável. Um ajuste global que desliga tudo a troco de bateria em todas as redes normalmente não é.

• Anote o valor original de poupança de energia ao lado do script para que possa ser reposto.
• Repita o teste de inatividade após cada atualização de controlador ou cliente; os valores predefinidos mudam.
• Mantenha o registo do ping e o registo do cliente juntos quando relatar o problema.
• Se o segundo passo falhou, pare de alterar definições de VPN e trate-o como uma falha local da ligação.

Se fizer apenas uma coisa, faça a verificação dois. É ela que decide se o resto desta lista se aplica a si, e é o passo que as pessoas saltam depois de já terem decidido que a resposta é a poupança de energia.