Per què un recordatori de VPN de 23 hores s'activa per a la sessió equivocada
Un avís de 23 hores ha de seguir una sessió, no el compte. Fixeu el temporitzador a la connexió que va començar i tracteu la suspensió i la reconnexió com a casos separats.
L'avís va aparèixer vint minuts després de connectar-se. El comptador de sota portava en marxa des del matí anterior, o des de l'última autenticació del compte, i res de l'alerta no deia quina de les dues. Aquest és el símptoma: un recordatori lligat a una cosa diferent de la connexió que teniu al davant.
La solució no és una alerta millor. És decidir quin rellotge vol dir el requisit i, després, lligar el temporitzador a un objecte que existeixi en aquest rellotge.
Què es va activar i què comptava
Tres fonts plausibles produeixen el mateix missatge. Una regla de calendari s'executa a una hora local fixa i no sap res de túnels. Un comptador al client s'acumula mentre qualsevol connexió està activa i sobreviu a les reconnexions. Una política de passarel·la fa caducar la sessió al costat del servidor i empeny un avís primer.
Només les dues últimes tracten d'una sessió, i fins i tot aquestes no coincideixen. El comptador del client mesura què ha observat el procés local; la passarel·la mesura què ha autenticat i comptabilitzat. Una suspensió, un canvi de xarxa o un reinici de l'observador poden separar-los hores, i per això l'avís i la caducitat imposada divergeixen.
Tres rellotges darrere d'un requisit
Comenceu escrivint la frase que realment voleu. Avisar abans que la passarel·la acabi aquesta connexió no és el mateix requisit que recordar-ho després d'un dia de temps connectat. Ni és el mateix que informar que aquesta sessió porta 23 hores engegada. Cada versió anomena un esdeveniment diferent, i un component diferent ha de respondre'n.
Després comproveu si les dades existeixen. Una marca de temps local d'inici us dona l'edat de la sessió sense dependre del servidor. Una política de passarel·la us dona la vida restant, però només si la passarel·la l'exposa. Un informe d'ús us dona la durada un cop passada, i això no pot impulsar un avís previ.
Fixeu el temporitzador a la sessió, no al compte
Trieu primer l'objecte. Un compte pot tenir diversos dispositius i diverses sessions simultànies, de manera que un recordatori lligat al nom d'usuari no pot dir quina connexió ha arribat a l'edat. Lligueu-lo al perfil més aquella activació, i cancel·leu l'avís pendent quan l'activació acabi.
| 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 |
Aquesta taula és un contracte per al vostre propi notificador, no una descripció de l'API de retorn de trucades de cap client. Allò que el producte instal·lat documenti sobre l'estat de la connexió és la font a la qual us heu de lligar; on només exposi esdeveniments d'autenticació, digueu-ho en veu alta i accepteu el comportament més groller en lloc d'inferir una sessió.
Proveu-lo amb un llindar curt
No depureu mai un temporitzador d'un dia amb una espera d'un dia. Afegiu un llindar configurable, poseu-lo a trenta segons i executeu quatre transicions en ordre: connecta, espera, desconnecta, reconnecta. Cada transició ha de produir exactament un canvi d'estat, i la reconnexió ha de programar un termini nou en lloc d'heretar el vell.
# 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 catMireu les marques de temps, no la redacció. Un avís que arriba amb l'hora d'inici de la sessió anterior ha lligat l'objecte equivocat, i un avís que arriba dues vegades per a un termini vol dir que la marca d'enviament no s'ha desat mai.
Suspensió, reconnexió i lliurament perdut
La suspensió trenca tots dos dissenys ingenus. Un compte enrere monòton s'atura mentre la màquina dorm, un termini de rellotge de paret continua avançant, i un temporitzador que es dispara durant la suspensió es lliura tard o no es lliura. Decidiu quin comportament necessita el requisit, després suspengueu la màquina més enllà del llindar i confirmeu-ho.
El lliurament mereix la mateixa cura. Si l'avís no es pot mostrar, poseu-lo en cua i torneu a comprovar que la sessió objectiu encara existeix abans de mostrar-lo finalment; si no, l'usuari rep un avís sobre una connexió que ja s'ha acabat. La desconnexió forçada i la renovació de credencials queden fora d'aquest camí, perquè un recordatori que canvia en silenci el destí de la connexió és una decisió de política vestida d'avís.