La VPN cade quando lo schermo si spegne: quale ciclo di vita?

Il trasferimento si ferma nel momento in cui lo schermo si oscura, e il badge segue qualche secondo dopo. Tre cose diverse producono quell’immagine: il processo client viene limitato, il percorso resta inattivo e perde la sua mappatura, oppure l’applicazione perde una sessione che il tunnel non ha mai notato. Ognuna ha le sue prove, e ogni correzione appartiene a uno strato diverso. L’ordine sotto le separa con un solo test controllato invece di una rassegna di tutte le impostazioni.

Tre guasti che sembrano identici

Un processo in background limitato smette di inviare keepalive, e l’altra estremità alla fine dichiara morto il tunnel. Una mappatura inattiva sul percorso può scadere mentre il dispositivo dorme, così il traffico di ritorno non raggiunge mai un client ancora perfettamente vivo. Un’applicazione può perdere la propria connessione mentre il tunnel resta in piedi, il che produce una finestra di errore con un badge VPN sano dietro. Dal punto di vista dell’utente, tutti e tre si leggono come la VPN caduta allo spegnimento dello schermo.

La distinzione conta perché i rimedi si contraddicono in pratica. Esenzione del client dalle restrizioni energetiche corregge il primo caso e non fa nulla per una mappatura scaduta. Allungare i keepalive corregge il secondo e spreca batteria nel terzo, dove nulla di legato alla rete era sbagliato fin dall’inizio.

Confronta attivo e inattivo sotto controllo

Mantieni tutto costante: stesso dispositivo, stessa rete, stesso endpoint, stessa applicazione. Blocca lo schermo per un breve intervallo fisso e annota tre osservazioni: se il client segnala una disconnessione, se una richiesta nuova funziona allo sblocco e se il trasferimento esistente è ripreso. Poi ripeti con un keepalive o una richiesta periodica in corso e confronta le due esecuzioni. Una variabile cambiata tra due esecuzioni vale più di una settimana di resoconti aneddotici.

Il momento appartiene al registro. Una caduta dopo novanta secondi sa di mappatura o di intervallo keepalive, mentre una caduta nell’istante del blocco indica una sospensione del processo. Annota sia l’innesco sia l’intervallo, perché il tentativo successivo ha bisogno di qualcosa con cui confrontarsi.

Leggi la politica in background della piattaforma

Su Android il ciclo di vita del servizio VPN fa parte della piattaforma, e always-on e block-without-VPN sono interruttori separati con effetti separati. Un client che non è always-on può essere fermato quando il sistema recupera risorse, e nessuna impostazione nell’app cambia questo. iOS applica i propri limiti in background al fornitore del tunnel, e il comportamento documentato differisce da un demone desktop che semplicemente continua a funzionare. Leggi la documentazione della piattaforma per il componente in questione, non una guida generica all’ottimizzazione della batteria.

I dispositivi gestiti aggiungono un altro strato. Una politica può sovrascrivere un’impostazione personale, quindi una modifica che sembra funzionare torna indietro al successivo aggiornamento della politica. Usa il processo di eccezione supportato dall’organizzazione se il requisito è reale, e annota perché l’eccezione esiste.

Cosa fa il dispositivo dopo il risveglio

La riconnessione automatica non è la stessa cosa del bloccare il traffico durante il vuoto. Controlla entrambe: se il tunnel torna, e se un’applicazione che ha provato a inviare durante il vuoto è uscita senza protezione. Un client che si riconnette in due secondi ma lascia sfuggire una query DNS nel primo ha la politica di guasto sbagliata per un dispositivo di lavoro. Prova con richieste innocue e una destinazione che controlli.

Il recupero dell’applicazione è la terza domanda. Un tunnel che torna non ripara una sessione SSH scaduta, e gli utenti spesso segnalano quella perdita di sessione come il guasto della VPN. Tieni insieme nel rapporto l’innesco, la build del client e il momento esatto, perché quella combinazione separa un ciclo di vita prevedibile di spegnimento schermo da un server che fallisce indipendentemente dal dispositivo.