A VPN cae ao apagar a pantalla: que ciclo de vida?

A transferencia detense no momento en que a pantalla escurece, e a insignia chega uns segundos despois. Tres cousas distintas producen esa imaxe: o proceso cliente queda restrinxido, a ruta queda inactiva e perde a súa asignación, ou a aplicación perde unha sesión que o túnel nunca notou. Cada unha ten as súas probas, e cada arranxo pertence a unha capa distinta. A orde seguinte sepáraas cunha soa proba controlada en lugar dunha revisión de todos os axustes.

Tres fallos que parecen idénticos

Un proceso en segundo plano restrinxido deixa de enviar keepalives, e o outro extremo acaba declarando morto o túnel. Unha asignación inactiva na ruta pode caducar mentres o dispositivo dorme, así que o tráfico de volta nunca chega a un cliente que segue perfectamente vivo. Unha aplicación pode perder a súa propia conexión mentres o túnel segue en pé, o que produce un diálogo de erro cunha insignia de VPN sa detrás. Desde o asento do usuario, as tres lense como a VPN que caeu ao apagar a pantalla.

A distinción importa porque os remedios se contradín na práctica. Eximir o cliente das restricións de enerxía arranxa o primeiro caso e non fai nada por unha asignación que caducou. Alongar os keepalives arranxa o segundo e desperdicia batería no terceiro, onde nada relacionado coa rede estaba mal desde o principio.

Compare activo e inactivo baixo control

Manteña todo constante: mesmo dispositivo, mesma rede, mesmo extremo, mesma aplicación. Bloquee a pantalla durante un intervalo curto e fixo e anote tres observacións: se o cliente informa dunha desconexión, se unha petición nova funciona ao desbloquear e se se retomou a transferencia existente. Logo repita cun keepalive ou unha petición periódica en marcha e compare as dúas execucións. Unha variable cambiada entre dúas execucións vale máis que unha semana de informes anecdóticos.

O momento pertence ao rexistro. Unha caída aos noventa segundos cheira a asignación ou a intervalo de keepalive, mentres que unha caída no momento do bloqueo apunta á suspensión do proceso. Anote tanto o desencadeante como o intervalo, porque o seguinte intento necesita algo co que comparar.

Lea a política de segundo plano da plataforma

En Android, o ciclo de vida do servizo VPN forma parte da plataforma, e always-on e block-without-VPN son interruptores separados con efectos separados. Un cliente que non é always-on pode deterse cando o sistema recupera recursos, e ningún axuste dentro da aplicación cambia iso. iOS aplica os seus propios límites en segundo plano ao provedor do túnel, e o comportamento documentado difire dun daemon de escritorio que simplemente segue executándose. Lea a documentación da plataforma para o compoñente en cuestión, non unha guía xenérica de optimización de batería.

Os dispositivos xestionados engaden outra capa. Unha política pode anular un axuste persoal, así que un cambio que parece funcionar reverte na seguinte actualización da política. Use o proceso de excepción admitido pola organización se o requisito é real, e anote por que existe a excepción.

Que fai o dispositivo despois de espertar

A reconexión automática non é o mesmo que bloquear o tráfico durante o oco. Comprobe ambas as cousas: se o túnel volve e se unha aplicación que intentou enviar durante o oco saíu sen protección. Un cliente que se reconecta en dous segundos pero deixa escapar unha consulta DNS no primeiro ten a política de fallo equivocada para un dispositivo de traballo. Probe con peticións inocuas e un destino que vostede controle.

A recuperación da aplicación é a terceira pregunta. Un túnel que volve non repara unha sesión SSH que caducou, e os usuarios adoitan informar desa perda de sesión como o fallo da VPN. Manteña xuntos no informe o desencadeante, a compilación do cliente e o momento exacto, porque esa combinación separa un ciclo de vida previsible de apagado de pantalla dun servidor que falla con independencia do dispositivo.