Hvorfor en 23-timers VPN-påminnelse utløses for feil økt

Varselet dukket opp tjue minutter etter tilkoblingen. Telleren under hadde gått siden morgenen i forveien, eller siden kontoen sist autentiserte seg, og ingenting i advarselen sa hvilken. Det er symptomet: en påminnelse knyttet til noe annet enn tilkoblingen foran deg.

Rettelsen er ikke et bedre varsel. Det er å bestemme hvilken klokke kravet mener, og deretter binde timeren til et objekt som finnes i den klokken.

Hva som ble utløst, og hva det telte

Tre sannsynlige kilder gir den samme meldingen. En kalenderregel kjører på et fast lokalt tidspunkt og vet ingenting om tunneler. En teller i klienten akkumulerer mens en hvilken som helst tilkobling er oppe, og overlever gjenoppkoblinger. En gateway-policy lar økten utløpe på tjenersiden og sender først en advarsel.

Bare de to siste handler om en økt, og selv de er uenige. Klienttelleren måler det den lokale prosessen observerte; gatewayen måler det den autentiserte og regnskapsførte. Dvale, nettverksbytte eller omstart av observatøren kan skille dem med timer, og derfor driver varselet og den håndhevede utløpsdatoen fra hverandre.

Tre klokker bak ett krav

Begynn med å skrive ned setningen du faktisk vil ha. Å varsle før gatewayen avslutter denne tilkoblingen er ikke det samme kravet som å minne om det etter et døgn med tilkoblet tid. Det er heller ikke det samme som å rapportere at denne økten har vært oppe i 23 timer. Hver versjon navngir en annen hendelse, og en annen komponent må svare på den.

Sjekk deretter om dataene finnes. Et lokalt starttidsstempel gir deg øktens alder uten avhengighet til tjeneren. En gateway-policy gir deg gjenstående levetid, men bare hvis gatewayen eksponerer den. En bruksrapport gir deg varigheten i ettertid, og det kan ikke drive et forhåndsvarsel.

Fest timeren til økten, ikke til kontoen

Velg objektet først. En konto kan holde flere enheter og flere samtidige økter, så en påminnelse knyttet til brukernavnet kan ikke si hvilken tilkobling som nådde alderen. Bind den til profilen pluss den aktiveringen, og avbryt varselet som venter når aktiveringen slutter.

Den tabellen er en kontrakt for din egen varsler, ikke en beskrivelse av callback-API-et til noen klient. Det installerte produktet dokumenterer om tilkoblingstilstand, er kilden du skal binde deg til; der det bare eksponerer autentiseringshendelser, si det høyt og godta den grovere oppførselen i stedet for å utlede en økt.

Test det med en kort terskel

Feilsøk aldri en døgnlang timer med en døgnlang venting. Legg til en konfigurerbar terskel, sett den til tretti sekunder, og kjør fire overganger i rekkefølge: koble til, vent, koble fra, koble til på nytt. Hver overgang skal gi nøyaktig én tilstandsendring, og gjenoppkoblingen skal planlegge en ny frist i stedet 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

Se på tidsstemplene, ikke formuleringen. Et varsel som kommer med forrige økts starttid, bandt feil objekt, og et varsel som kommer to ganger for én frist betyr at sendt-flagget aldri ble lagret.

Dvale, gjenoppkobling og tapt levering

Dvale bryter begge de naive designene. En monoton nedtelling stopper mens maskinen sover, en frist etter veggklokke fortsetter å flytte seg, og en timer som utløses under dvale, leveres sent eller ikke i det hele tatt. Bestem hvilken oppførsel kravet ditt trenger, og sett deretter maskinen i dvale over terskelen og bekreft det.

Levering fortjener samme omhu. Hvis varselet ikke kan vises, legg det i kø, og sjekk på nytt at måløkten fortsatt finnes før du til slutt viser det; ellers varsles brukeren om en tilkobling som allerede er avsluttet. Tvungen frakobling og fornyelse av legitimasjon holder seg utenfor denne veien, fordi en påminnelse som stille endrer tilkoblingens skjebne, er en policybeslutning kledd ut som et varsel.