Cómo medir el tiempo de actividad del cliente OpenVPN con los ganchos up y down

Un panel pide una cifra de cuánto tiempo lleva conectado y OpenVPN no la ofrece. El cliente sabe cuándo subió su túnel, pero solo si algo registra ese momento antes de que se pierda el estado de la sesión. El lugar admitido es el gancho up, y el valor que merece guardarse es un segundo epoch en bruto en lugar de una cadena formateada. Todo lo demás es aritmética, más unas cuantas reglas de orden que deciden si la cifra sigue siendo honesta.

Confirme que los ganchos se ejecutan de verdad

Demuestre que el gancho se dispara antes de diseñar nada a su alrededor. Una configuración mínima de cliente necesita script-security 2 más rutas explícitas up y down; sin la línea de seguridad, OpenVPN se niega a ejecutar el script y lo dice sin rodeos. Añada up-restart y down-pre a la vez para que las rutas de reinicio y desmontaje se comporten de forma predecible.

Haga que la primera versión del gancho añada su entorno a un archivo y no haga nada más. Eso le dice los nombres de variables que su compilación exporta realmente, como dev y script_type, en lugar de los que recuerda de otra versión. Ejecute una conexión y una desconexión, y luego lea el archivo. Si no aparece nada, deténgase aquí, porque un diseño de marca de tiempo sobre un gancho que nunca se ejecuta parecerá un fallo de monitorización durante semanas.

Compruebe con qué usuario se ejecuta el gancho. Con user y group establecidos, OpenVPN cede privilegios antes de ejecutar scripts, así que un directorio en el que root puede escribir puede estar cerrado para el gancho. Elija la ruta desde el punto de vista del servicio y no desde el de su shell.

Registre un solo valor epoch y bórrelo a propósito

El gancho up necesita una línea, date +%s > /run/openvpn-client.started, con la ruta ajustada por instancia. Un valor epoch evita más adelante preguntas de idioma, zona horaria y formato, y es el mismo número que un agente de monitorización puede comparar con su propio reloj.

Borrar importa tanto como escribir. El gancho down debe vaciar o eliminar el archivo, y down-pre hace que eso ocurra antes de que se cierre la interfaz, lo que elimina la ventana en la que el archivo describe un túnel que ya se fue. up-restart después refresca la marca en un reinicio interno en lugar de dejar el valor original en su sitio. Sin ese par, un reinicio por tiempo de espera de ping produce una cifra que sigue subiendo mientras el túnel se restablece.

Elija una ubicación con la vida útil correcta. Un archivo bajo /run desaparece al reiniciar, lo que coincide con la realidad, mientras que un archivo bajo /tmp puede limpiarse de forma impredecible y uno en el directorio de configuración sobrevive de un modo que engaña. Fije permisos para que solo el usuario del servicio y el lector de monitorización puedan leerlo.

Calcule el tiempo de actividad sin confiar en las líneas del registro

Lea el segundo guardado, lea el segundo actual, reste. Cuando el archivo falta o está vacío, la respuesta honesta es que no hay ningún túnel activo, no que el tiempo de actividad sea cero, porque esos dos estados deberían generar alertas distintas. Mantenga los segundos en bruto en la carga de monitorización y formatee días y horas en la capa de presentación. Un formateador que redondea dentro del exportador tira precisión que alguien querrá durante un incidente.

Analizar las marcas de tiempo del registro es el atajo tentador, y falla de tres maneras: el formato sigue las opciones que haya establecidas, la rotación elimina el historial y las reconexiones aparecen como sesiones separadas en lugar de un solo túnel continuo. El gancho registra el evento una vez, en el momento en que ocurre.

Cuando la comprobación se ejecuta en otro host, envíe la marca de tiempo en lugar de la duración para que el lector aplique su propio reloj. Entonces un resultado negativo pequeño se lee como desfase de reloj y no como un gancho roto.

Cubra reconexiones, reinicios y varias instancias

Dos túneles en un mismo host necesitan dos archivos, con clave por el nombre de instancia que el servicio ya usa. Una ruta compartida hace que la conexión más reciente sobrescriba la hora de inicio de cada perfil, y el síntoma es una cifra que salta hacia atrás cuando arranca un segundo túnel.

El comportamiento de reconexión merece su propia prueba, porque es donde un diseño plausible informa en silencio de lo incorrecto. Fuerce un reinicio soltando el par o enviando una señal al proceso, y luego compare el estado de la interfaz con el archivo. La marca de tiempo debería avanzar en el momento en que vuelve el túnel.

En el lado del servidor, el archivo de estado lleva un valor connected-since por cliente, que responde a otra pregunta: cuándo vio el servidor a ese par por última vez. Úselo para la comprobación cruzada y no como sustituto, ya que desaparece con la sesión que describe. Ninguna de las dos mediciones dice nada sobre la salud de la aplicación detrás del túnel.

Ejecute las tres comprobaciones que atrapan errores de orden

Pruebe una conexión normal, una reconexión forzada y una parada limpia, leyendo la lista de interfaces y el archivo juntos después de cada una. Una marca que sigue presente tras una parada limpia, o un archivo que afirma un túnel que la lista de interfaces no contiene, apunta directamente al orden de los ganchos. Ejecute las comprobaciones como el usuario del servicio y con las rutas del servicio, porque un shell de root puede ver otro archivo y dar una respuesta equivocada con seguridad. Luego deje un sondeador lento leyendo el archivo y confirme que nunca escribe en él.

Una encuesta cada sesenta segundos cubre las alertas, y ningún gancho debería depender de que ese sondeador esté vivo. Mantenga separadas esas dos responsabilidades y la cifra seguirá siendo fiable cuando cualquiera de los lados se vuelva a desplegar.