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

Varselet kom fram tjue minutter etter at forbindelsen var opprettet. Telleren under hadde gått helt siden forrige morgen, eller siden kontoen sist ble autentisert, og ingenting i varselet fortalte hvilken. Dette er symptomet: en påminnelse som er knyttet til noe annet enn forbindelsen du har foran deg.

Løsningen er ikke et bedre varsel. Den er å avgjøre hvilken klokke kravet sikter til, og så feste timeren til et objekt som finnes i den klokken.

Hva som ble utløst, og hva det telte

Tre mulige kilder gir samme melding. En kalenderregel kjører på et fast lokalt klokkeslett og vet ingenting om tunneler. En teller i klienten vokser så lenge en forbindelse er oppe, og tåler gjentatte tilkoblinger. En gateway-regel avslutter økten på tjenersiden og sender et varsel i forkant.

Bare de to siste gjelder en økt, og de er heller ikke enige. Klienttelleren måler det den lokale prosessen har sett; gatewayen måler det den har autentisert og gjort opp. Dvale, nettbytte eller omstart av overvåkeren kan skille dem med flere timer, og derfor glir varselet og den tvungne utløpsdatoen fra hverandre.

Tre klokker bak ett krav

Start med å skrive ned setningen du egentlig vil ha. Å varsle før gatewayen avslutter denne forbindelsen er ikke samme krav som å minne om det etter et døgn med tilkoblet tid. Det er heller ikke det samme som å rapportere at økten har vart i 23 timer. Hver variant nevner en annen hendelse, og en annen komponent må svare på den.

Sjekk så om dataene finnes. Et lokalt starttidspunkt gir øktens alder uten å være avhengig av tjeneren. En gateway-regel gir gjenstående levetid, men bare hvis gatewayen gjør den tilgjengelig. En bruksrapport gir varigheten i ettertid, og det kan ikke styre et forhåndsvarsel.

Fest timeren til økten, ikke til kontoen

Velg objektet først. En konto kan romme flere enheter og flere samtidige økter, så en påminnelse som er låst til brukernavnet, kan ikke si hvilken forbindelse som nådde alderen. Lås den til profilen og den aktiveringen, og avbryt varselet som venter når aktiveringen er over.

Tabellen er en kontrakt for din egen varsler, ikke en beskrivelse av callback-API-et til en hvilken som helst klient. Det installerte produktet dokumenterer om forbindelsestilstand, er kilden du skal feste deg til; der det bare viser autentiseringshendelser, si det rett ut og godta den grovere oppførselen i stedet for å slutte deg til en økt.

Test det med en kort terskel

Aldri feilsøk en timer på et døgn med å vente et døgn. Legg inn en justerbar terskel, sett den til tretti sekunder, og kjør fire overganger i rekkefølge: koble til, vent, koble fra, koble til igjen. Hver overgang skal gi nøyaktig én tilstandsendring, og den nye tilkoblingen skal planlegge en ny frist framfor å 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 og ikke på ordlyden. Et varsel som kommer med starttiden til forrige økt, festet til feil objekt, og et varsel som kommer to ganger for samme frist, betyr at flagget for sendt aldri ble lagret.

Dvale, gjenoppkobling og tapt levering

Dvale bryter begge de enkle utformingene. En monoton nedtelling stopper mens maskinen sover, en frist etter veggklokken fortsetter å bevege seg, og en timer som utløses under dvale, blir levert for sent eller ikke i det hele tatt. Bestem hvilken oppførsel kravet ditt trenger, sett deretter maskinen i dvale over terskelen og bekreft det.

Levering fortjener samme omtanke. 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 blir brukeren varslet om en forbindelse som allerede er avsluttet. Tvungen frakobling og fornyelse av påloggingsinformasjon holdes utenfor denne veien, fordi en påminnelse som i stillhet endrer forbindelsens skjebne, er et regelvedtak kledd som et varsel.