Kvifor ei 23-timars VPN-påminning blir utløyst for feil økt

Varselet dukka opp tjue minutt etter tilkoplinga. Teljaren under hadde gått sidan morgonen i førevegen, eller sidan kontoen sist autentiserte seg, og ingenting i åtvaringa sa kven. Det er symptomet: ei påminning knytt til noko anna enn tilkoplinga framfor deg.

Rettinga er ikkje eit betre varsel. Det er å avgjere kva klokke kravet meiner, og deretter binde timeren til eit objekt som finst i den klokka.

Kva som vart utløyst, og kva det talde

Tre sannsynlege kjelder gjev den same meldinga. Ei kalenderregel går på fast lokal tid og veit ingenting om tunnelar. Ein teljar i klienten hopar seg opp medan kva tilkopling som helst er oppe, og overlever attoppkoplingar. Ein gateway-policy lèt økta gå ut på tenarsida og sender fyrst ei åtvaring.

Berre dei to siste handlar om ei økt, og sjølv dei er usamde. Klientteljaren måler det den lokale prosessen observerte; gatewayen måler det han autentiserte og rekneskapsførte. Dvale, nettverksbyte eller omstart av observatøren kan skilje dei med timar, og difor driv varselet og den påtvungne utløpsdatoen frå kvarandre.

Tre klokker bak eitt krav

Byrja med å skrive ned setninga du faktisk vil ha. Å åtvare før gatewayen avsluttar denne tilkoplinga er ikkje det same kravet som å minne om det etter eit døgn med tilkopla tid. Det er heller ikkje det same som å rapportere at denne økta har vore oppe i 23 timar. Kvar versjon nemner ei anna hending, og ein annan komponent må svare på henne.

Sjekk så om dataa finst. Eit lokalt starttidstempel gjev deg alderen på økta utan avhengnad av tenaren. Ein gateway-policy gjev deg attverande levetid, men berre om gatewayen syner henne. Ein bruksrapport gjev deg varigheita i ettertid, og det kan ikkje drive eit førehandsvar.

Fest timeren til økta, ikkje til kontoen

Vel objektet fyrst. Ein konto kan halde fleire einingar og fleire samtidige økter, så ei påminning knytt til brukarnamnet kan ikkje seie kva tilkopling som nådde alderen. Bind henne til profilen pluss den aktiveringa, og avbryt varselet som ventar når aktiveringa sluttar.

Den tabellen er ein kontrakt for din eigen varslar, ikkje ei skildring av callback-API-et til nokon klient. Det installerte produktet dokumenterer om tilkoplingstilstand, er kjelda du skal binde deg til; der det berre syner autentiseringshendingar, seier du det høgt og godtek den grovare åtferda i staden for å utleie ei økt.

Test det med ein kort terskel

Feilsøk aldri ein døgnlang timer med ein døgnlang venting. Legg til ein konfigurerbar terskel, set han til tretti sekund, og køyr fire overgangar i rekkjefølgje: kople til, vent, kople frå, kople til på nytt. Kvar overgang skal gje nøyaktig éi tilstandsendring, og attoppkoplinga skal planleggje ein ny frist i staden for å arve den gamle.

# 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

Sjå på tidstempla, ikkje på formuleringa. Eit varsel som kjem med starttida til førre økta, batt feil objekt, og eit varsel som kjem to gonger for ein frist, tyder at sendt-flaggja aldri vart lagra.

Dvale, attoppkopling og tapt levering

Dvale bryt båe dei naive utformingane. Ei monoton nedteljing stoggar medan maskinen søv, ein frist etter veggklokka held fram med å flytte seg, og ein timer som løyser ut under dvale, blir levert seint eller ikkje i det heile. Avgjer kva åtferd kravet ditt treng, set så maskinen i dvale over terskelen og stadfest det.

Levering fortener same omsuta. Om varselet ikkje kan visast, legg det i kø, og sjekk på nytt at måløkta framleis finst før du til slutt viser det; elles blir brukaren åtvara om ei tilkopling som alt er avslutta. Påtvungen fråkopling og fornying av legitimasjon held seg utanfor denne vegen, fordi ei påminning som stille endrar lagnaden til tilkoplinga, er eit policyvedtak kledd ut som eit varsel.