Arranxar as caídas de VPN en repouso: unha lista de comprobación para o aforro de enerxía do Wi-Fi

O seu túnel morre despois de que o portátil quede un intre sen tocar, e volve no momento en que toca o panel táctil. Ese patrón apunta a que a ligazón sen fíos entra en aforro de enerxía, non a que a pasarela VPN rexeite as súas credenciais. Unha mañá atarefada co mesmo perfil é a pista: o túnel sobrevive mentres flúe o tráfico e falla cando a radio queda en silencio. Percorra as comprobacións seguintes por orde, detéñase na primeira que falle e só entón cambie un axuste.

Comprobación un: a caída segue o repouso?

Empece demostrando a correlación en lugar de supoñela. Anote a hora de reloxo do último paquete enviado, a hora en que o cliente informou de que o túnel estaba caído e se a pantalla se apagou mentres tanto. Se o intervalo é o mesmo cada vez, ten un problema na ruta de repouso; se as caídas chegan ao azar durante o uso activo, salte á quinta comprobación.

Unha proba barata que non custa nada desfacer: envía un ping constante de ritmo baixo á súa pasarela durante vinte minutos e deixa a máquina soa. Se o túnel aguanta toda a proba, o tráfico pequeno constante está a enmascarar o síntoma en lugar de arranxalo, o que segue sendo unha evidencia útil. Garda a saída dese ping nun terminal de borrador e despois compáraa co rexistro do cliente, porque os dous reloxos raramente coinciden.

Comprobación dous: é só tráfico VPN?

Antes de culpar o túnel, averigüe se a propia ligazón aínda é utilizábel. Mentres o túnel está morto pero a pantalla aínda apagada, intente acadar o enderezo do punto de acceso e un servidor público por IP. Se o ping normal tamén falla, a radio ou o punto de acceso deixárono fóra e o cliente VPN é un simple espectador.

Se o tráfico normal flúe mentres o túnel cala, a ligazón está san e o problema está nos temporizadores do propio túnel ou en como o cliente xestiona unha reanudación. Son dúas correccións distintas, así que non salte este paso. Nun portátil con Wi-Fi e Ethernet á vez, desconecte o cable e repita a proba de repouso: unha caída de repouso que desaparece con Ethernet por cable é unha evidencia forte para a capa sen fíos.

Comprobación tres: lea o estado de aforro de enerxía

A maioría dos escritorios danlle unha caixa, pero a caixa non é o estado no que está o controlador. Lea primeiro o informe do propio controlador e despois decida. En Linux con mac80211 a interface responde directamente:

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 é unha proba, non unha corrección. Non sobrevive a unha desconexión, unha suspensión nin un reinicio, o que o converte nunha forma limpa de comprobar a hipótese sen deixar cambios permanentes.

En Windows powercfg /q SCHEME_CURRENT imprime o esquema activo, e a subárbore do adaptador sen fíos mostra se se lle pode ordenar ao adaptador que aforre enerxía; a mesma opción tamén está no Administrador de dispositivos, na pestana de administración de enerxía do adaptador. En macOS o aforro de enerxía 802.11 por interface non se lle expón, así que mire no seu lugar pmset -g para o comportamento de repouso e espera. Alí o fallo adoita resultar ser a ruta de repouso e espertar, non o comportamento en repouso da radio.

Comprobación catro: cambie unha cousa e volva probar

Cambie exactamente unha variable por execución e repita a mesma carga. Se o túnel agora aguanta unha hora de repouso co aforro de enerxía desactivado, aprendeu algo real. Se segue caendo, reverta antes de probar a idea seguinte, ou acabará con tres axustes superpostos e sen idea de cal importa.

Manter a conexión viva é a outra variable independente e confúndese constantemente co aforro de enerxía. O PersistentKeepalive = 25 de WireGuard mantén quente unha asignación NAT;OpenVPN usa keepalive e ping-restart nos dous extremos. Ambos xeran tráfico nun túnel que doutro xeito estaría silencioso, así que un mantemento de conexión que parece arranxar a caída pode estar ocultando un problema de radio en lugar de resolvelo. Próbeos por separado, un a unha:

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

Comprobación cinco: cando a radio é inocente

Se as caídas en repouso continúan co aforro de enerxía desactivado e o mantemento de conexión activado, mire fóra do portátil. Os puntos de acceso e os routers domésticos caducan as entradas NAT ou de sesión en repouso segundo o seu propio calendario, e un servidor VPN pode deixar caer unha sesión sen tráfico.A itinerancia entre puntos de acceso que comparten un mesmo SSID tamén pode reiniciar a ligazón sen que o cliente o diga con claridade.

Despois compare cun segundo dispositivo na mesma rede que faga a mesma proba de repouso. Dous dispositivos que caen no mesmo intervalo son unha historia de ruta ou de servidor; un só que cae é unha historia de controlador ou de enerxía local. Esa comparación custa dez minutos e aforra reescribir a configuración equivocada.

Antes de facelo permanente

Decida que está disposto a manter. Un script por perfil que desactiva o aforro de enerxía só nas redes onde viu a caída é defendible. Un retoque global que o desactiva todo a cambio de batería en todas as redes normalmente non o é.

• Anote o valor orixinal de aforro de enerxía xunto ao script para que se poida restaurar.
• Volva facer a proba de repouso despois de cada actualización de controlador ou cliente; os valores por defecto cambian.
• Manteña o rexistro de ping e o rexistro do cliente xuntos cando informe do problema.
• Se o segundo paso fallou, deixe de cambiar axustes de VPN e tráteo como unha falla local da ligazón.

Se só fai unha cousa, faga a comprobación dous. É a que decide se o resto desta lista lle afecta, e é o paso que a xente salta cando xa decidiu que a resposta é o aforro de enerxía.