Perché un promemoria VPN di 23 ore scatta per la sessione sbagliata
Un avviso di 23 ore deve seguire una sessione, non l'account. Ancora il timer alla connessione iniziata e tratta sospensione e riconnessione come casi separati.
L'avviso è apparso venti minuti dopo la connessione. Il contatore sotto aveva funzionato dalla mattina precedente, o dall'ultima autenticazione dell'account, e nulla nell'allarme diceva quale. È il sintomo: un promemoria legato a qualcosa di diverso dalla connessione davanti a voi.
La correzione non è un avviso migliore. È decidere quale orologio intende il requisito, poi legare il timer a un oggetto che esiste in quell'orologio.
Che cosa è scattato, e che cosa contava
Tre fonti plausibili producono lo stesso messaggio. Una regola di calendario gira a un'ora locale fissa e non sa nulla dei tunnel. Un contatore nel client si accumula finché una connessione è attiva e sopravvive alle riconnessioni. Una politica del gateway fa scadere la sessione lato server e spinge prima un avviso.
Solo le ultime due riguardano una sessione, e nemmeno loro concordano. Il contatore del client misura ciò che ha osservato il processo locale; il gateway misura ciò che ha autenticato e contabilizzato. Una sospensione, un cambio di rete o un riavvio dell'osservatore possono separarli di ore, ed è per questo che l'avviso e la scadenza imposta divergono.
Tre orologi dietro un solo requisito
Cominciate scrivendo la frase che volete davvero. Avvisare prima che il gateway termini questa connessione non è lo stesso requisito che ricordare dopo un giorno di tempo connesso. Non è nemmeno lo stesso che segnalare che questa sessione è attiva da 23 ore. Ogni versione nomina un evento diverso, e un componente diverso deve rispondere.
Poi verificate se i dati esistono. Un timestamp locale di inizio vi dà l'età della sessione senza dipendere dal server. Una politica del gateway vi dà la vita residua, ma solo se il gateway la espone. Un report di utilizzo vi dà la durata a posteriori, e questo non può guidare un avviso anticipato.
Lega il timer alla sessione, non all'account
Scegliete prima l'oggetto. Un account può contenere più dispositivi e più sessioni simultanee, quindi un promemoria imperniato sul nome utente non può dire quale connessione ha raggiunto l'età. Imperniatelo sul profilo più quell'attivazione, e annullate l'avviso in sospeso quando l'attivazione finisce.
| Evidence you can read | What it establishes | Where it misleads |
|---|---|---|
| Connection state changes to active | A session started now | Does not carry the gateway's own session identifier |
| Duration reported at disconnect | Total service time for that session | Arrives too late for any advance notice |
| Interim usage update | Time accounted up to that update | Staleness equals the update interval |
| Local timestamp taken at activation | Age of your observation | Resets whenever the observer restarts |
Quella tabella è un contratto per il vostro notificatore, non una descrizione dell'API di callback di alcun client. Qualunque cosa documenti il prodotto installato sullo stato della connessione è la fonte a cui legarsi; dove espone solo eventi di autenticazione, ditelo ad alta voce e accettate il comportamento più grossolano invece di dedurre una sessione.
Provalo con una soglia breve
Non fate mai debug di un timer di un giorno con un'attesa di un giorno. Aggiungete una soglia configurabile, impostatala a trenta secondi ed eseguite quattro transizioni in ordine: connetti, attendi, disconnetti, riconnetti. Ogni transizione deve produrre esattamente un cambio di stato, e la riconnessione deve programmare una nuova scadenza invece di ereditare la vecchia.
# current connection state and profile identity
nmcli -f GENERAL.STATE,GENERAL.CONNECTION connection show work
# the notifier unit you wrote: does it restart the deadline or resume it?
journalctl --user -u vpn-timer.service --since "-5 min" -o catGuardate i timestamp, non la formulazione. Un avviso che arriva con l'ora di inizio della sessione precedente ha legato l'oggetto sbagliato, e un avviso che arriva due volte per una scadenza significa che il flag di invio non è mai stato salvato.
Sospensione, riconnessione e consegna mancata
La sospensione rompe entrambi i progetti ingenui. Un conto alla rovescia monotono si ferma mentre la macchina dorme, una scadenza a orologio da parete continua a muoversi, e un timer che scatta durante la sospensione viene consegnato tardi o per niente. Decidete quale comportamento serve al vostro requisito, poi sospendete la macchina oltre la soglia e confermatelo.
La consegna merita la stessa cura. Se l'avviso non può essere mostrato, mettetelo in coda e ricontrollate che la sessione di destinazione esista ancora prima di mostrarlo infine; altrimenti l'utente viene avvisato di una connessione già terminata. La disconnessione forzata e il rinnovo delle credenziali restano fuori da questo percorso, perché un promemoria che cambia in silenzio il destino della connessione è una decisione politica vestita da notifica.