Come misurare il tempo di attività del client OpenVPN con gli hook up e down

Una dashboard chiede un numero su da quanto tempo la connessione è attiva, e OpenVPN non lo fornisce. Il client sa quando è salito il suo tunnel, ma solo se qualcosa registra quel momento prima che lo stato della sessione vada perso. Il posto supportato è l'hook up, e il valore che vale la pena salvare è un secondo epoch grezzo invece di una stringa formattata. Tutto il resto è aritmetica, più alcune regole di ordinamento che decidono se il numero resta onesto.

Verificate che gli hook vengano davvero eseguiti

Dimostrate che l'hook scatta prima di progettare qualcosa attorno ad esso. Una configurazione client minima richiede script-security 2 più percorsi espliciti up e down; senza la riga di sicurezza OpenVPN si rifiuta di eseguire lo script e lo dice chiaramente. Aggiungete up-restart e down-pre nello stesso momento, così i percorsi di riavvio e di smontaggio si comportano in modo prevedibile.

Fate in modo che la prima versione dell'hook aggiunga il suo ambiente a un file e non faccia altro. Questo vi dice i nomi delle variabili che la vostra build esporta davvero, come dev e script_type, invece di quelli che ricordate da un'altra versione. Eseguite una connessione e una disconnessione, poi leggete il file. Se non compare nulla, fermatevi qui, perché un progetto di timestamp su un hook che non viene mai eseguito sembrerà un guasto del monitoraggio per settimane.

Controllate con quale utente viene eseguito l'hook. Con user e group impostati, OpenVPN rinuncia ai privilegi prima di eseguire gli script, quindi una directory in cui root può scrivere può essere chiusa all'hook. Scegliete il percorso dal punto di vista del servizio, non da quello della vostra shell.

Registrate un solo valore epoch e cancellatelo deliberatamente

L'hook up ha bisogno di una riga, date +%s > /run/openvpn-client.started, con il percorso adattato per ogni istanza. Un valore epoch evita più avanti domande su lingua, fuso orario e formato, ed è lo stesso numero che un agente di monitoraggio può confrontare con il proprio orologio.

Cancellare conta quanto scrivere. L'hook down deve svuotare o rimuovere il file, e down-pre fa sì che accada prima che l'interfaccia si chiuda, il che elimina la finestra in cui il file descrive un tunnel già sparito. up-restart poi aggiorna il timestamp a un riavvio interno invece di lasciare il valore originale al suo posto. Senza quella coppia, un riavvio dopo il timeout del ping produce un numero che continua a salire mentre il tunnel si ristabilisce.

Scegliete una posizione con la giusta durata. Un file sotto /run scompare al riavvio, il che corrisponde alla realtà, mentre un file sotto /tmp può essere ripulito in modo imprevedibile e uno nella directory di configurazione sopravvive in modo ingannevole. Impostate i permessi in modo che solo l'utente del servizio e il lettore del monitoraggio possano leggerlo.

Calcolate il tempo di attività senza fidarvi delle righe di log

Leggete il secondo salvato, leggete il secondo corrente, sottraete. Quando il file è assente o vuoto, la risposta onesta è che nessun tunnel è attivo, non che il tempo di attività è zero, perché quei due stati dovrebbero sollevare avvisi diversi. Tenete i secondi grezzi nel payload di monitoraggio e formattate giorni e ore nel livello di visualizzazione. Un formattatore che arrotonda dentro l'esportatore butta via precisione che qualcuno vorrà durante un incidente.

Analizzare i timestamp del log è la scorciatoia tentante, e fallisce in tre modi: il formato segue qualunque opzione sia impostata, la rotazione elimina la cronologia e le riconnessioni appaiono come sessioni separate invece che un unico tunnel continuo. L'hook registra l'evento una volta, nel momento in cui accade.

Quando il controllo viene eseguito su un altro host, inviate il timestamp invece della durata, così il lettore applica il proprio orologio. Un piccolo risultato negativo si legge allora come scarto di orologio invece che come hook rotto.

Coprite riconnessioni, riavvii e istanze multiple

Due tunnel su un solo host richiedono due file, con chiave il nome dell'istanza che il servizio già usa. Un percorso condiviso significa che la connessione più recente sovrascrive l'ora di inizio di ogni profilo, e il sintomo è un numero che salta all'indietro quando parte un secondo tunnel.

Il comportamento di riconnessione merita un test a sé, perché è lì che un progetto plausibile riporta in silenzio la cosa sbagliata. Forzate un riavvio facendo cadere il peer o inviando un segnale al processo, poi confrontate lo stato dell'interfaccia con il file. Il timestamp dovrebbe avanzare nel momento in cui il tunnel ritorna.

Lato server, il file di stato porta un valore connected-since per client, che risponde a un'altra domanda: quando il server ha visto quel peer l'ultima volta. Usatelo per il controllo incrociato e non come sostituto, dato che scompare con la sessione che descrive. Nessuna delle due misurazioni dice nulla sulla salute dell'applicazione dietro il tunnel.

Eseguite i tre controlli che intercettano gli errori di ordinamento

Provate una connessione normale, una riconnessione forzata e un arresto pulito, leggendo l'elenco delle interfacce e il file insieme dopo ognuno. Un timestamp ancora presente dopo un arresto pulito, o un file che afferma un tunnel che l'elenco delle interfacce non contiene, punta dritto all'ordinamento degli hook. Eseguite i controlli come utente del servizio e con i percorsi del servizio, perché una shell di root può vedere un altro file e dare una risposta sbagliata con sicurezza. Poi lasciate un sondatore lento a leggere il file e confermate che non vi scrive mai.

Un sondaggio ogni sessanta secondi copre gli avvisi, e nessun hook dovrebbe contare sul fatto che quel sondatore sia vivo. Tenete separate queste due responsabilità e il numero resta affidabile quando una delle due parti viene ridistribuita.