Por qué un recordatorio de VPN de 23 horas se dispara para la sesión equivocada
Un aviso de 23 horas debe seguir a una sesión, no a la cuenta. Ancle el temporizador a la conexión que empezó y trate la suspensión y la reconexión como casos separados.
El aviso apareció veinte minutos después de conectar. El contador de debajo llevaba funcionando desde la mañana anterior, o desde la última autenticación de la cuenta, y nada en la alerta decía cuál. Ese es el síntoma: un recordatorio atado a algo distinto de la conexión que tiene delante.
La solución no es una alerta mejor. Es decidir qué reloj quiere decir el requisito y después atar el temporizador a un objeto que exista en ese reloj.
Qué se disparó y qué contaba
Tres fuentes plausibles producen el mismo mensaje. Una regla de calendario se ejecuta a una hora local fija y no sabe nada de túneles. Un contador en el cliente se acumula mientras cualquier conexión está activa y sobrevive a las reconexiones. Una política de puerta de enlace caduca la sesión en el lado del servidor y envía primero un aviso.
Solo las dos últimas tratan de una sesión, y ni siquiera esas coinciden. El contador del cliente mide lo que observó el proceso local; la puerta de enlace mide lo que autenticó y contabilizó. Una suspensión, un cambio de red o un reinicio del observador pueden separarlos por horas, y por eso el aviso y la caducidad forzada se alejan.
Tres relojes detrás de un requisito
Empiece por escribir la frase que realmente quiere. Avisar antes de que la puerta de enlace termine esta conexión no es el mismo requisito que recordar tras un día de tiempo conectado. Tampoco es lo mismo que informar de que esta sesión lleva 23 horas en pie. Cada versión nombra un suceso distinto, y un componente distinto tiene que responder.
Luego compruebe si los datos existen. Una marca de tiempo local de inicio le da la edad de la sesión sin depender del servidor. Una política de puerta de enlace le da la vida restante, pero solo si la puerta de enlace la expone. Un informe de uso le da la duración a posteriori, y eso no puede impulsar un aviso previo.
Ate el temporizador a la sesión, no a la cuenta
Elija primero el objeto. Una cuenta puede tener varios dispositivos y varias sesiones simultáneas, así que un recordatorio ligado al nombre de usuario no puede decir qué conexión alcanzó la edad. Átelo al perfil más esa activación, y cancele el aviso pendiente cuando la activación termine.
| 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 |
Esa tabla es un contrato para su propio notificador, no una descripción de la API de devolución de llamada de ningún cliente. Lo que el producto instalado documente sobre el estado de la conexión es la fuente a la que atarse; donde solo exponga eventos de autenticación, dígalo en voz alta y acepte el comportamiento más grueso en lugar de inferir una sesión.
Pruébelo con un umbral corto
Nunca depure un temporizador de un día con una espera de un día. Añada un umbral configurable, póngalo en treinta segundos y ejecute cuatro transiciones en orden: conectar, esperar, desconectar, reconectar. Cada transición debe producir exactamente un cambio de estado, y la reconexión debe programar un plazo nuevo en vez de heredar el viejo.
# 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 catMire las marcas de tiempo, no la redacción. Un aviso que llega con la hora de inicio de la sesión anterior ató el objeto equivocado, y un aviso que llega dos veces para un plazo significa que la marca de envío nunca se guardó.
Suspensión, reconexión y entrega perdida
La suspensión rompe los dos diseños ingenuos. Una cuenta atrás monótona se detiene mientras la máquina duerme, un plazo de reloj de pared sigue avanzando, y un temporizador que se dispara durante la suspensión se entrega tarde o no se entrega. Decida qué comportamiento necesita su requisito, luego suspenda la máquina más allá del umbral y confírmelo.
La entrega merece el mismo cuidado. Si el aviso no se puede mostrar, póngalo en cola y vuelva a comprobar que la sesión objetivo sigue existiendo antes de mostrarlo por fin; si no, se avisa al usuario de una conexión que ya terminó. La desconexión forzada y la renovación de credenciales quedan fuera de este camino, porque un recordatorio que cambia en silencio el destino de la conexión es una decisión de política vestida de aviso.