La VPN cade quando lo schermo si spegne: blocco, oscuramento o sospensione?

Quando qualcuno dice che la VPN è morta quando lo schermo si è oscurato, la prima domanda utile è quale dei tre eventi si è verificato davvero: la sessione si è bloccata, il pannello si è spento o l'intera macchina è andata in sospensione. Sono meccanismi separati su timer separati, e solo uno di essi può impedire del tutto che un processo venga schedulato. Percorri i controlli qui sotto in ordine. Fermati al primo che risponde alla domanda, perché ogni controllo successivo risponde a qualcos'altro.

Primo controllo: separa il blocco dall'oscuramento e dalla sospensione

Il blocco cambia chi è autorizzato a usare la sessione; il compositore continua a disegnare, lo stack di rete continua a funzionare e il client VPN non se ne accorge. L'oscuramento dello schermo spegne il pannello dopo un intervallo di inattività e lascia la macchina completamente sveglia. La sospensione ferma le CPU, il che significa che nessun processo in spazio utente viene schedulato, quindi nessun keepalive può scattare, per breve che sia l'intervallo.

È quella tabella il motivo per cui «lo schermo si è oscurato» non è una diagnosi. Un desktop impostato per oscurarsi dopo cinque minuti e sospendersi dopo trenta mostrerà uno schermo scuro al sesto minuto con un tunnel perfettamente sano. Il guasto al trentesimo minuto è un altro evento con un'altra soluzione, ed entrambi sembrano identici dall'altra parte della stanza.

Secondo controllo: metti gli eventi di alimentazione e rete su un'unica linea temporale

Leggi il journal per una finestra limitata invece che per l'intero avvio, e includi sia il gestore di accesso sia il proprietario della connessione:

journalctl -b -u systemd-logind -u NetworkManager --since "45 minutes ago"
systemd-inhibit --list

Il primo comando mostra le richieste di sospensione, la ripresa e le transizioni di rete che le hanno seguite. Il secondo mostra cosa detiene attualmente un blocco inibitore, il che ti dice se qualcosa blocca la sospensione di proposito e quale programma è. Adatta i nomi delle unità se il proprietario della tua connessione non è NetworkManager, e ricorda che leggere l'unità di un altro utente o il journal di sistema dipende dalla politica locale.

Una riga assente non è un risultato negativo. Se il journal dell'unità scelta non è visibile al tuo account, l'assenza di un record di sospensione non dimostra nulla, e concludere «non ha mai dormito» da un filtro vuoto è il modo in cui le persone finiscono per regolare keepalive per una settimana.

Terzo controllo: se si è sospesa, decidi se era voluto

Una volta che una transizione di sospensione è sulla linea temporale, la domanda passa da perché la VPN si è rotta a se la macchina dovesse dormire affatto. Su un portatile la risposta è spesso sì, e l'interruzione del tunnel è un comportamento atteso da cui il client deve riprendersi al risveglio. Su una workstation che deve restare raggiungibile, è la politica di sospensione che va cambiata. Decidere a quale di queste due macchine stai guardando richiede una domanda, e non è una domanda a cui il journal possa rispondere al posto tuo.

Cambiala tramite i controlli che appartengono alla sessione connessa, o tramite un meccanismo supportato dall'amministratore se il requisito riguarda l'intera macchina. Modificare un'impostazione del gestore di visualizzazione mentre sei connesso con un altro account non è la stessa azione e sembrerà aver funzionato fino all'inizio della sessione successiva. Disattivare del tutto la gestione dell'alimentazione è una prima reazione ampia che costa autonomia e nasconde la vera questione di politica.

Quarto controllo: se è rimasta sveglia, guarda la rete e il client

Una macchina sveglia che ha perso il tunnel ha una di tre storie: la rete di accesso è caduta, il client VPN si è fermato o riavviato, oppure il lato server ha lasciato scadere l'associazione mentre il client continuava a credere di essere connesso. Confronta le marche temporali dell'evento di collegamento sottostante con l'evento del tunnel, e sii preciso su quale sia arrivato prima.

Poi prova il percorso di recupero separatamente dalla sessione originale. Una nuova richiesta attraverso il tunnel ripristinato può riuscire mentre la sessione applicativa di lunga durata aperta prima dell'interruzione resta rotta, perché l'applicazione tiene un socket obsoleto o un indirizzo in cache. È un problema dell'applicazione, non la prova che il tunnel non sia tornato.

Cosa contiene un rapporto utile

Scrivi la sequenza con marche temporali e responsabili: quando la sessione si è bloccata, quando lo schermo si è oscurato, se è stata registrata una richiesta di sospensione, quando il collegamento è caduto e tornato, quando il tunnel ha cambiato stato e cosa ha fatto realmente l'applicazione. Ogni voce ha un responsabile, quindi ogni voce può essere affidata alla persona giusta invece di diventare una lamentela generica su Linux.

Se manca una di quelle righe, è la prossima cosa da misurare e non la prossima cosa da cambiare. Una linea temporale con un buco è più istruttiva di un cambio di impostazioni fatto per intuizione.