Varför en 23-timmars VPN-påminnelse utlöses för fel session
Ett 23-timmarsmeddelande bör följa en session, inte kontot. Fäst timern vid anslutningen som startade och behandla viloläge och återanslutning som separata fall.
Aviseringen dök upp tjugo minuter efter anslutningen. Räknaren under hade gått sedan morgonen innan, eller sedan kontot senast autentiserade sig, och inget i varningen sade vilket. Det är symptomet: en påminnelse knuten till något annat än anslutningen framför dig.
Lösningen är inte en bättre varning. Det är att avgöra vilken klocka kravet menar, och sedan knyta timern till ett objekt som finns i den klockan.
Vad som utlöstes och vad det räknade
Tre troliga källor ger samma meddelande. En kalenderregel går på fast lokal tid och vet ingenting om tunnlar. En räknare i klienten ackumuleras så länge någon anslutning är uppe och överlever återanslutningar. En gateway-policy låter sessionen löpa ut på serversidan och skickar först en varning.
Bara de två sista handlar om en session, och inte ens de är överens. Klienträknaren mäter vad den lokala processen observerade; gatewayen mäter vad den autentiserade och redovisade. Viloläge, nätverksbyte eller omstart av observatören kan skilja dem åt med timmar, och därför glider varningen och det påtvingade utgångsdatumet isär.
Tre klockor bakom ett krav
Börja med att skriva ner meningen du faktiskt vill ha. Att varna innan gatewayen avslutar den här anslutningen är inte samma krav som att påminna efter ett dygn med ansluten tid. Det är inte heller samma sak som att rapportera att sessionen har varit uppe i 23 timmar. Varje version namnger en annan händelse, och en annan komponent måste svara på den.
Kontrollera sedan om data finns. En lokal starttidsstämpel ger dig sessionens ålder utan beroende av servern. En gateway-policy ger dig återstående livslängd, men bara om gatewayen exponerar den. En användningsrapport ger dig varaktigheten i efterhand, och det kan inte driva en förhandsvarning.
Fäst timern vid sessionen, inte vid kontot
Välj objektet först. Ett konto kan hålla flera enheter och flera samtidiga sessioner, så en påminnelse knuten till användarnamnet kan inte säga vilken anslutning som nådde åldern. Knyt den till profilen plus den aktiveringen, och avbryt aviseringen som väntar när aktiveringen tar slut.
| 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 |
Den tabellen är ett kontrakt för din egen aviserare, inte en beskrivning av callback-API:et för någon klient. Vad det installerade produkten dokumenterar om anslutningsstatus är källan du ska knyta dig till; där den bara exponerar autentiseringshändelser ska du säga det högt och acceptera det grövre beteendet i stället för att sluta dig till en session.
Testa det med en kort tröskel
Felsök aldrig en dygnslång timer med ett dygnslångt väntande. Lägg till en konfigurerbar tröskel, sätt den till trettio sekunder och kör fyra övergångar i ordning: anslut, vänta, koppla från, återanslut. Varje övergång ska ge exakt en tillståndsändring, och återanslutningen ska schemalägga en ny deadline i stället för att ärva den gamla.
# 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 cat
Titta på tidsstämplarna, inte på formuleringen. En avisering som kommer med föregående sessions starttid band fel objekt, och en avisering som kommer två gånger för en deadline betyder att skickat-flaggan aldrig sparades.
Viloläge, återanslutning och förlorad leverans
Viloläge bryter båda de naiva konstruktionerna. En monoton nedräkning stannar medan maskinen sover, en deadline enligt väggklocka fortsätter att flytta sig, och en timer som utlöses under viloläget levereras sent eller inte alls. Bestäm vilket beteende ditt krav behöver, försätt sedan maskinen i viloläge över tröskeln och bekräfta det.
Leveransen förtjänar samma omsorg. Om aviseringen inte kan visas, köa den, och kontrollera igen att målsessionen fortfarande finns innan du till slut visar den; annars varnas användaren för en anslutning som redan är avslutad. Påtvingad frånkoppling och förnyelse av inloggningsuppgifter stannar utanför den här vägen, eftersom en påminnelse som tyst ändrar anslutningens öde är ett policybeslut klätt som en avisering.