Reinicieu OpenVPN cada dia? Trieu la fallada, no el rellotge

Heredeu una tasca cron que reinicia OpenVPN cada dia a les 04:10 i que fa un any que manté les coses estables. També desconnecta un túnel sa a una hora fixa i no fa res per la interrupció que passa de debò a l’hora de dinar. Un reinici per calendari és una decisió de manteniment. La recuperació és un disseny diferent, amb un desencadenant concret.

Tres formes de fallada necessiten tres propietaris diferents. Trieu primer la fallada i el mecanisme vindrà després.

Tres fallades, tres propietaris

Un túnel pot estar actiu mentre el seu par ha desaparegut: el procés s’executa, la interfície existeix i no hi passa res d’útil. Un procés pot estar mort mentre el par està bé, i aleshores només el que el va iniciar el pot tornar a aixecar. Una aplicació darrere del túnel pot estar espatllada mentre tant el túnel com el par estan sans, i reiniciar el client aleshores amplia la interrupció sense tocar la causa. Separar aquests tres casos és tota la decisió.

Cadascun té el seu senyal i el seu propietari. La vitalitat pertany al protocol VPN, el cicle de vida del procés pertany al gestor de serveis i la salut de l’aplicació pertany al monitoratge amb un mandat estret.

Què pot i què no pot fer una opció de vitalitat

keepalive és un auxiliar que s’expandeix en una parella ping i ping-restart, tal com descriu la referència d’opcions d’enllaç, i els temps d’espera que genera no són idèntics al servidor i al client. Els valors que empeny un servidor també poden substituir el que un client ha configurat localment, i per això un temps d’espera que sembla correcte en un fitxer local pot no ser el que està en vigor.

Això el converteix en l’eina adequada per a un par perdut i en l’eina inadequada per a un procés mort, ja que un procés que ha sortit no pot executar els seus propis temporitzadors. També no diu res sobre si una aplicació darrere del túnel respon, perquè l’intercanvi passa entre els dos extrems del VPN. Copiar una parella de temps d’espera d’un altre desplegament sense comprovar el rol, les interrupcions previstes i el comportament de reautenticació és com un túnel estable comença a tremolar.

Què posseeix el gestor de serveis

Si el dimoni surt, el gestor que el va iniciar decideix què passa després. Una política de reinici lligada a la fallada, amb un retard i un límit de velocitat d’arrencada, gestiona un bucle de fallida sense convertir-lo en una fork bomb. Aquests paràmetres responen als resultats del procés i als temps d’espera, i no detecten un procés que és viu però inútil. Això no és un buit per tapar amb una política més àmplia; és la frontera entre el cicle de vida i la vitalitat.

La propietat importa tant com la configuració. Una connexió iniciada per un gestor de xarxa d’escriptori hauria de conservar l’arranjament de recuperació d’aquell gestor, i afegir una unitat de servei competidora per a la mateixa interfície dona dos propietaris a un sol túnel. Trieu-ne un i deixeu escrit quin és.

Quan un reinici programat és legítim

Un reinici temporitzat pot ser una acció de manteniment raonable: té un propietari, una finestra, una instància amb nom i una via d’accés independent. El que no pot ser és una política general de fiabilitat que, a més, desconnecti tothom a una hora fixa.

Si el reinici existeix per esquivar una fuita coneguda o un estat encallat, digueu-ho a la descripció de la unitat, perquè si no la persona següent el mantindrà per sempre.

Proveu els casos que importen: el par desapareix mentre el procés segueix actiu, el procés surt, un reintent necessita credencials noves i el túnel torna mentre l’aplicació segueix espatllada. Observeu quin component reacciona i quin estat deixa darrere.

La pregunta correcta no és amb quina freqüència reiniciar, sinó què hauria de notar la fallada primer.