Como medir o tempo de actividade do cliente OpenVPN cos ganchos up e down

Un panel pide unha cifra de canto tempo leva conectado e OpenVPN non a ofrece. O cliente sabe cando subiu o seu túnel, pero só se algo rexistra ese momento antes de que se perda o estado da sesión. O lugar admitido é o gancho up, e o valor que paga a pena gardar é un segundo epoch en bruto en lugar dunha cadea formatada. Todo o demais é aritmética, máis unhas cantas regras de orde que deciden se a cifra segue sendo honesta.

Confirme que os ganchos se executan de verdade

Demostre que o gancho se dispara antes de deseñar nada ao seu redor. Unha configuración mínima de cliente necesita script-security 2 máis rutas explícitas up e down; sen a liña de seguridade, OpenVPN négase a executar o script e dixo claramente. Engada up-restart e down-pre ao mesmo tempo para que as rutas de reinicio e desmontaxe se comporten de forma previsible.

Faga que a primeira versión do gancho engada o seu contorno a un ficheiro e non faga nada máis. Iso dille os nomes de variables que a súa compilación exporta realmente, como dev e script_type, en lugar dos que recorda doutra versión. Execute unha conexión e unha desconexión, e despois lea o ficheiro. Se non aparece nada, detéñase aquí, porque un deseño de marca de tempo sobre un gancho que nunca se executa parecerá un fallo de monitorización durante semanas.

Comprobe con que usuario se executa o gancho. Con user e group establecidos, OpenVPN cede privilexios antes de executar scripts, así que un directorio no que root pode escribir pode estar pechado para o gancho. Escolla a ruta desde o punto de vista do servizo e non desde o da súa consola.

Rexiste un só valor epoch e bórrao a propósito

O gancho up necesita unha liña, date +%s > /run/openvpn-client.started, coa ruta axustada por instancia. Un valor epoch evita máis adiante preguntas de idioma, fuso horario e formato, e é o mesmo número que un axente de monitorización pode comparar co seu propio reloxo.

Borrar importa tanto como escribir. O gancho down debe baleirar ou eliminar o ficheiro, e down-pre fai que iso ocurra antes de que se peche a interface, o que elimina a xanela na que o ficheiro describe un túnel que xa se foi. up-restart despois refresca a marca nun reinicio interno en lugar de deixar o valor orixinal no seu sitio. Sen ese par, un reinicio por tempo de espera de ping produce unha cifra que segue subindo mentres o túnel se restablece.

Escolla unha localización coa vida útil correcta. Un ficheiro baixo /run desaparece ao reiniciar, o que coincide coa realidade, mentres que un ficheiro baixo /tmp pode limparse de forma imprevisible e un no directorio de configuración sobrevive dun xeito que engana. Fixe permisos para que só o usuario do servizo e o lector de monitorización poidan lelo.

Calcule o tempo de actividade sen confiar nas liñas do rexistro

Lea o segundo gardado, lea o segundo actual, reste. Cando o ficheiro falta ou está baleiro, a resposta honesta é que non hai ningún túnel activo, non que o tempo de actividade sexa cero, porque eses dous estados deberían xerar alertas distintas. Manteña os segundos en bruto na carga de monitorización e formatee días e horas na capa de presentación. Un formateador que redondea dentro do exportador tira precisión que alguén quererá durante un incidente.

Analizar as marcas de tempo do rexistro é o atallo tentador, e falla de tres xeitos: o formato segue as opcións que haxa establecidas, a rotación elimina o historial e as reconexións aparecen como sesións separadas en lugar dun só túnel continuo. O gancho rexistra o evento unha vez, no momento en que ocorre.

Cando a comprobación se executa noutro host, envía a marca de tempo en lugar da duración para que o lector aplique o seu propio reloxo. Entón un resultado negativo pequeno lese como desfase de reloxo e non como un gancho roto.

Cubra reconexións, reinicios e varias instancias

Dous túneles nun mesmo host necesitan dous ficheiros, con clave polo nome de instancia que o servizo xa usa. Unha ruta compartida fai que a conexión máis recente sobrescriba a hora de inicio de cada perfil, e o síntoma é unha cifra que salta cara atrás cando arranca un segundo túnel.

O comportamento de reconexión merece a súa propia proba, porque é onde un deseño verosímil informa en silencio do incorrecto. Force un reinicio deixando caer o par ou enviando un sinal ao proceso, e despois compare o estado da interface co ficheiro. A marca de tempo debería avanzar no momento en que volve o túnel.

No lado do servidor, o ficheiro de estado leva un valor connected-since por cliente, que responde a outra pregunta: cando viu o servidor ese par por última vez. Úseo para a comprobación cruzada e non como substituto, xa que desaparece coa sesión que describe. Ningunha das dúas medicións di nada sobre a saúde da aplicación detrás do túnel.

Execute as tres comprobacións que atrapan erros de orde

Probe unha conexión normal, unha reconexión forzada e unha parada limpa, lendo a lista de interfaces e o ficheiro xuntos despois de cada unha. Unha marca que aínda está despois dunha parada limpa, ou un ficheiro que afirma un túnel que a lista de interfaces non contén, apunta directamente á orde dos ganchos. Execute as comprobacións como o usuario do servizo e coas rutas do servizo, porque unha consola de root pode ver outro ficheiro e dar unha resposta equivocada con seguridade. Logo deixe un sondador lento lendo o ficheiro e confirme que nunca escribe nel.

Unha enquisa cada sesenta segundos cobre as alertas, e ningún gancho debería depender de que ese sondador estea vivo. Manteña separadas esas dúas responsabilidades e a cifra seguirá sendo fiable cando calquera dos lados se volva despregar.