Waarom een VPN-herinnering van 23 uur voor de verkeerde sessie afgaat
Een melding van 23 uur moet één sessie volgen, niet het account. Koppel de timer aan de verbinding die begon en behandel slaap en herverbinden als afzonderlijke gevallen.
De melding verscheen twintig minuten na het verbinden. De teller eronder liep sinds de vorige ochtend, of sinds het account zich voor het laatst authenticeerde, en niets in de waarschuwing zei welke. Dat is het symptoom: een herinnering die aan iets anders vastzit dan aan de verbinding voor je.
De oplossing is geen betere waarschuwing. Het is beslissen welke klok de eis bedoelt, en dan de timer vastmaken aan een object dat in die klok bestaat.
Wat er afging, en wat het telde
Drie plausibele bronnen produceren hetzelfde bericht. Een kalenderregel loopt op een vaste lokale tijd en weet niets van tunnels. Een teller in de client loopt op zolang een verbinding actief is en overleeft herverbindingen. Een gatewaybeleid laat de sessie aan de serverkant verlopen en stuurt eerst een waarschuwing.
Alleen de laatste twee gaan over een sessie, en zelfs die zijn het niet eens. De clientteller meet wat het lokale proces zag; de gateway meet wat zij authenticeerde en verrekende. Slaap, een netwerkwijziging of een herstart van de waarnemer kunnen de twee uren uit elkaar trekken, en daarom lopen de waarschuwing en de afgedwongen afloop uiteen.
Drie klokken achter één eis
Begin met het opschrijven van de zin die je echt wilt. Waarschuwen voordat de gateway deze verbinding beëindigt is niet dezelfde eis als herinneren na een dag verbonden tijd. Het is ook niet hetzelfde als melden dat deze sessie al 23 uur loopt. Elke versie noemt een andere gebeurtenis, en een andere component moet daarop antwoorden.
Controleer dan of de gegevens bestaan. Een lokaal starttijdstempel geeft je de leeftijd van de sessie zonder afhankelijkheid van de server. Een gatewaybeleid geeft je de resterende levensduur, maar alleen als de gateway die blootlegt. Een gebruiksrapport geeft je de duur achteraf, en dat kan geen voorafmelding aansturen.
Koppel de timer aan de sessie, niet aan het account
Kies eerst het object. Een account kan meerdere apparaten en meerdere gelijktijdige sessies bevatten, dus een herinnering die op de gebruikersnaam is gesleuteld, kan niet zeggen welke verbinding de leeftijd bereikte. Sleutel hem op het profiel plus die activering, en annuleer de wachtende melding wanneer de activering eindigt.
| 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 |
Die tabel is een contract voor je eigen notifier, geen beschrijving van de callback-API van welke client dan ook. Wat het geïnstalleerde product ook documenteert over de verbindingsstatus, dat is de bron waaraan je moet vastmaken; waar het alleen authenticatiegebeurtenissen blootlegt, zeg dat hardop en accepteer het grovere gedrag in plaats van een sessie af te leiden.
Test het met een korte drempel
Debug nooit een etmaal durende timer met een etmaal wachten. Voeg een configureerbare drempel toe, zet die op dertig seconden en voer vier overgangen in volgorde uit: verbinden, wachten, verbreken, opnieuw verbinden. Elke overgang moet precies één toestandsverandering opleveren, en de herverbinding moet een nieuwe deadline plannen in plaats van de oude te erven.
# 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 catLet op de tijdstempels, niet op de formulering. Een melding die aankomt met de starttijd van de vorige sessie heeft het verkeerde object vastgemaakt, en een melding die twee keer aankomt voor één deadline betekent dat de verzonden-vlag nooit is opgeslagen.
Slaap, herverbinden en gemiste bezorging
Slaap breekt beide naïeve ontwerpen. Een monotone aftelling stopt terwijl de machine slaapt, een deadline op de wandklok blijft doorlopen, en een timer die tijdens de slaap afgaat, wordt te laat of helemaal niet bezorgd. Beslis welk gedrag je eis nodig heeft, breng de machine dan over de drempel in slaap en bevestig het.
Bezorging verdient dezelfde zorg. Als de melding niet kan worden getoond, zet hem dan in de wachtrij, en controleer opnieuw of de doelsessie nog bestaat voordat je hem eindelijk toont; anders wordt de gebruiker gewaarschuwd voor een verbinding die al is beëindigd. Gedwongen verbreking en vernieuwing van inloggegevens blijven buiten dit pad, want een herinnering die stilletjes het lot van de verbinding verandert, is een beleidsbeslissing in de kleren van een melding.