Com mesurar el temps de funcionament del client OpenVPN amb els ganxos up i down

Un quadre de comandament demana una xifra de fa quant temps que hi ha connexió, i OpenVPN no la proporciona. El client sap quan s'ha aixecat el seu túnel, però només si alguna cosa registra aquell moment abans que es perdi l'estat de la sessió. El lloc admès és el ganxo up, i el valor que val la pena desar és un segon epoch cru en lloc d'una cadena formatada. Tot el que ve després és aritmètica, més unes quantes regles d'ordre que decideixen si la xifra continua essent honesta.

Confirmeu que els ganxos s'executen realment

Demostreu que el ganxo s'activa abans de dissenyar res al seu voltant. Una configuració mínima de client necessita script-security 2 i camins explícits up i down; sense la línia de seguretat, OpenVPN es nega a executar l'script i ho diu ben clar. Afegiu up-restart i down-pre alhora perquè els camins de reinici i d'aturada es comportin de manera previsible.

Feu que la primera versió del ganxo afegeixi el seu entorn a un fitxer i no faci res més. Això us diu els noms de les variables que la vostra compilació exporta realment, com ara dev i script_type, en lloc dels que recordeu d'una altra versió. Feu una connexió i una desconnexió, i després llegiu el fitxer. Si no hi apareix res, atureu-vos aquí, perquè un disseny de marca de temps sobre un ganxo que mai s'executa semblarà un error de monitoratge durant setmanes.

Comproveu amb quin usuari s'executa el ganxo. Amb user i group establerts, OpenVPN deixa anar privilegis abans d'executar scripts, de manera que un directori on root pot escriure pot estar tancat per al ganxo. Trieu el camí des del punt de vista del servei, no des de la vostra consola.

Registreu un sol valor epoch i esborreu-lo deliberadament

El ganxo up necessita una línia, date +%s > /run/openvpn-client.started, amb el camí ajustat per a cada instància. Un valor epoch evita més endavant preguntes d'idioma, zona horària i format, i és el mateix nombre que un agent de monitoratge pot comparar amb el seu propi rellotge.

Esborrar és tan important com escriure. El ganxo down ha de buidar o eliminar el fitxer, i down-pre fa que això passi abans que es tanqui la interfície, cosa que elimina la finestra en què el fitxer descriu un túnel que ja no hi és. up-restart després refresca la marca en un reinici intern en lloc de deixar el valor original al seu lloc. Sense aquest parell, un reinici per temps d'espera de ping produeix una xifra que continua pujant mentre el túnel es torna a establir.

Trieu una ubicació amb la vida útil correcta. Un fitxer sota /run desapareix en reiniciar, cosa que coincideix amb la realitat, mentre que un fitxer sota /tmp es pot netejar de manera imprevisible i un al directori de configuració sobreviu d'una manera que enganya. Configureu els permisos perquè només l'usuari del servei i el lector de monitoratge el puguin llegir.

Calculeu el temps de funcionament sense confiar en les línies de registre

Llegiu el segon desat, llegiu el segon actual, resteu. Quan el fitxer és absent o buit, la resposta honesta és que no hi ha cap túnel actiu, no que el temps de funcionament sigui zero, perquè aquests dos estats haurien de generar alertes diferents. Manteniu els segons crus a la càrrega de monitoratge i formateu dies i hores a la capa de presentació. Un formatejador que arrodoneix dins de l'exportador llença precisió que algú voldrà durant un incident.

Analitzar les marques de temps del registre és la drecera temptadora, i falla de tres maneres: el format segueix les opcions que hi hagi establertes, la rotació elimina l'historial i les reconnexions apareixen com a sessions separades en lloc d'un sol túnel continu. El ganxo registra l'esdeveniment una vegada, en el moment en què passa.

Quan la comprovació s'executa en un altre amfitrió, envieu la marca de temps en lloc de la durada perquè el lector apliqui el seu propi rellotge. Aleshores un resultat negatiu petit es llegeix com a desfasament de rellotge i no com un ganxo espatllat.

Cobriu reconnexions, reinicis i diverses instàncies

Dos túnels en un sol amfitrió necessiten dos fitxers, amb clau pel nom d'instància que el servei ja utilitza. Un camí compartit fa que la connexió més recent sobreescrigui l'hora d'inici de cada perfil, i el símptoma és una xifra que salta enrere quan arrenca un segon túnel.

El comportament de reconnexió mereix una prova pròpia, perquè és on un disseny versemblant informa en silenci de la cosa equivocada. Forceu un reinici deixant caure el parell o enviant un senyal al procés, i després compareu l'estat de la interfície amb el fitxer. La marca de temps hauria d'avançar en el moment que torna el túnel.

Al costat del servidor, el fitxer d'estat porta un valor connected-since per client, que respon una pregunta diferent: quan va veure el servidor aquell parell per darrera vegada. Feu-lo servir per a la comprovació creuada i no com a substitut, ja que desapareix amb la sessió que descriu. Cap de les dues mesures diu res sobre la salut de l'aplicació darrere del túnel.

Executeu les tres comprovacions que atrapen errors d'ordre

Proveu una connexió normal, una reconnexió forçada i una aturada neta, llegint la llista d'interfícies i el fitxer junts després de cadascuna. Una marca que encara hi és després d'una aturada neta, o un fitxer que afirma un túnel que la llista d'interfícies no conté, assenyala directament l'ordre dels ganxos. Executeu les comprovacions com a usuari del servei i amb els camins del servei, perquè una consola de root pot veure un fitxer diferent i donar una resposta equivocada amb molta confiança. Després deixeu un sondejador lent llegint el fitxer i confirmeu que mai no hi escriu.

Una enquesta cada seixanta segons cobreix l'alertes, i cap ganxo no hauria de dependre que aquest sondejador sigui viu. Manteniu aquestes dues responsabilitats separades i la xifra continua sent fiable quan qualsevol de les bandes es torna a desplegar.