De ce o reamintire VPN de 23 de ore se declanșează pentru sesiunea greșită
O notificare de 23 de ore ar trebui să urmeze o singură sesiune, nu contul. Fixați temporizatorul la conexiunea care a început și tratați suspendarea și reconectarea ca fiind cazuri separate.
Notificarea a apărut douăzeci de minute după conectare. Contorul de sub ea funcționa de dimineața precedentă, sau de la ultima autentificare a contului, și nimic din alertă nu spunea care. Acesta este simptomul: o reamintire legată de altceva decât conexiunea din fața ta.
Soluția nu este o alertă mai bună. Este să decizi ce ceas are în vedere cerința, apoi să legi temporizatorul de un obiect care există în acel ceas.
Ce s-a declanșat și ce număra
Trei surse plauzibile produc același mesaj. O regulă de calendar rulează la o oră locală fixă și nu știe nimic despre tuneluri. Un contor din client se acumulează cât timp orice conexiune este activă și supraviețuiește reconectărilor. O politică de gateway expiră sesiunea pe partea serverului și trimite mai întâi un avertisment.
Doar ultimele două privesc o sesiune, și nici ele nu sunt de acord. Contorul clientului măsoară ce a observat procesul local; gateway-ul măsoară ce a autentificat și a contabilizat. O suspendare, o schimbare de rețea sau o repornire a observatorului le pot separa cu ore, și de aceea avertismentul și expirarea impusă se îndepărtează.
Trei ceasuri în spatele unei cerințe
Începe prin a scrie propoziția pe care o vrei cu adevărat. A avertiza înainte ca gateway-ul să încheie această conexiune nu este aceeași cerință ca a reaminti după o zi de timp conectat. Nu este nici același lucru cu a raporta că această sesiune durează de 23 de ore. Fiecare versiune numește un alt eveniment, și o altă componentă trebuie să răspundă la el.
Apoi verifică dacă datele există. Un marcaj de timp local de început îți dă vârsta sesiunii fără dependență de server. O politică de gateway îți dă durata de viață rămasă, dar numai dacă gateway-ul o expune. Un raport de utilizare îți dă durata după fapt, iar asta nu poate conduce o notificare anticipată.
Leagă temporizatorul de sesiune, nu de cont
Alege mai întâi obiectul. Un cont poate ține mai multe dispozitive și mai multe sesiuni simultane, așa că o reamintire legată de numele de utilizator nu poate spune care conexiune a atins vârsta. Leag-o de profil plus acea activare, și anulează notificarea în așteptare când activarea se termină.
| 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 |
Tabelul acela este un contract pentru propriul tău notificator, nu o descriere a API-ului de apel invers al vreunui client. Orice documentează produsul instalat despre starea conexiunii este sursa de care trebuie să te legi; acolo unde expune doar evenimente de autentificare, spune-o cu voce tare și acceptă comportamentul mai grosier în loc să deduci o sesiune.
Testează-l cu un prag scurt
Nu depana niciodată un temporizator de o zi cu o așteptare de o zi. Adaugă un prag configurabil, setează-l la treizeci de secunde și rulează patru tranziții în ordine: conectare, așteptare, deconectare, reconectare. Fiecare tranziție trebuie să producă exact o schimbare de stare, iar reconectarea trebuie să programeze un termen nou în loc să-l moștenească pe cel vechi.
# 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
Uită-te la marcajele de timp, nu la formulare. O notificare care sosește cu ora de început a sesiunii anterioare a legat obiectul greșit, iar o notificare care sosește de două ori pentru un termen înseamnă că indicatorul de trimitere nu a fost niciodată salvat.
Suspendare, reconectare și livrare pierdută
Suspendarea rupe ambele modele naive. O numărătoare inversă monotonă se oprește cât timp mașina doarme, un termen după ceasul de perete continuă să se miște, iar un temporizator care se declanșează în timpul suspendării este livrat târziu sau deloc. Decide ce comportament cere cerința ta, apoi suspendă mașina peste prag și confirmă.
Livrarea merită aceeași grijă. Dacă notificarea nu poate fi afișată, pune-o în coadă și verifică din nou că sesiunea țintă mai există înainte de a o afișa în cele din urmă; altfel utilizatorul este avertizat despre o conexiune care s-a încheiat deja. Deconectarea forțată și reînnoirea acreditărilor rămân în afara acestei căi, pentru că o reamintire care schimbă în tăcere soarta conexiunii este o decizie de politică îmbrăcată într-o notificare.