A VPN cai quando a tela desliga: qual ciclo de vida?

A transferência para no momento em que a tela escurece, e o selo aparece alguns segundos depois. Três coisas diferentes produzem essa imagem: o processo do cliente é restringido, o caminho fica ocioso e perde seu mapeamento, ou o aplicativo perde uma sessão que o túnel nunca percebeu. Cada uma tem suas próprias evidências, e cada correção pertence a uma camada diferente. A ordem abaixo separa os casos com um único teste controlado em vez de uma varredura de todas as configurações.

Três falhas que parecem idênticas

Um processo em segundo plano restrito para de enviar keepalives, e o outro lado acaba declarando o túnel morto. Um mapeamento ocioso no caminho pode expirar enquanto o dispositivo dorme, então o tráfego de retorno nunca chega a um cliente ainda perfeitamente vivo. Um aplicativo pode perder sua própria conexão enquanto o túnel permanece de pé, o que produz uma caixa de erro com um selo de VPN saudável atrás. Do ponto de vista do usuário, os três são lidos como a VPN caindo ao desligar a tela.

A distinção importa porque os remédios se contradizem na prática. Isentar o cliente das restrições de energia corrige o primeiro caso e não faz nada por um mapeamento expirado. Aumentar os keepalives corrige o segundo e desperdiça bateria no terceiro, onde nada relacionado à rede estava errado desde o início.

Compare ativo e ocioso sob controle

Mantenha tudo constante: mesmo dispositivo, mesma rede, mesmo endpoint, mesmo aplicativo. Bloqueie a tela por um intervalo curto e fixo e anote três observações: se o cliente relata uma desconexão, se uma nova solicitação funciona ao desbloquear e se a transferência existente foi retomada. Depois repita com um keepalive ou uma solicitação periódica em execução e compare as duas execuções. Uma variável alterada entre duas execuções vale mais que uma semana de relatos anedóticos.

O momento pertence ao registro. Uma queda após noventa segundos cheira a mapeamento ou a intervalo de keepalive, enquanto uma queda no instante do bloqueio aponta para suspensão do processo. Anote tanto o gatilho quanto o intervalo, porque a próxima tentativa precisa de algo com que comparar.

Leia a política de segundo plano da plataforma

No Android, o ciclo de vida do serviço de VPN faz parte da plataforma, e always-on e block-without-VPN são chaves separadas com efeitos separados. Um cliente que não é always-on pode ser interrompido quando o sistema recupera recursos, e nenhuma configuração dentro do aplicativo muda isso. O iOS aplica seus próprios limites de segundo plano ao provedor de túnel, e o comportamento documentado difere de um daemon de desktop que simplesmente continua rodando. Leia a documentação da plataforma para o componente em questão, não um guia genérico de otimização de bateria.

Dispositivos gerenciados adicionam outra camada. Uma política pode sobrepor uma configuração pessoal, então uma mudança que parece funcionar reverte na próxima atualização da política. Use o processo de exceção suportado pela organização se o requisito for real, e anote por que a exceção existe.

O que o dispositivo faz depois de acordar

A reconexão automática não é o mesmo que bloquear o tráfego durante a lacuna. Verifique as duas coisas: se o túnel volta e se um aplicativo que tentou enviar durante a lacuna saiu sem proteção. Um cliente que se reconecta em dois segundos mas deixa vazar uma consulta DNS no primeiro tem a política de falha errada para um dispositivo de trabalho. Teste com solicitações inofensivas e um destino que você controla.

A recuperação do aplicativo é a terceira pergunta. Um túnel que volta não conserta uma sessão SSH que expirou, e os usuários costumam relatar essa perda de sessão como a falha da VPN. Mantenha juntos no relatório o gatilho, a compilação do cliente e o momento exato, porque essa combinação separa um ciclo de vida previsível de desligamento de tela de um servidor que falha independentemente do dispositivo.