Reiniciar OpenVPN cada día? Escolla o fallo, non o reloxo

Herdamos unha tarefa cron que reinicia OpenVPN todos os días ás 04:10 e que leva un ano mantendo as cousas estables. Tamén desconecta un túnel san a unha hora fixa e non fai nada pola caída que ocorre de verdade á hora de xantar. Un reinicio por calendario é unha decisión de mantemento. A recuperación é un deseño distinto, cun disparador concreto.

Tres formas de fallo necesitan tres propietarios distintos. Escolla primeiro o fallo e o mecanismo virá despois.

Tres fallos, tres propietarios

Un túnel pode estar activo mentres o seu par desapareceu: o proceso execútase, a interface existe e nada útil a atravesa. Un proceso pode estar morto mentres o par está ben, e entón só o que o iniciou pode devolvelo. Unha aplicación detrás do túnel pode estar rota mentres tanto o túnel como o par están sans, e reiniciar entón o cliente amplía a caída sen tocar a causa. Separar eses tres casos é toda a decisión.

Cada un ten o seu sinal e o seu propietario. A vitalidade pertence ao protocolo VPN, o ciclo de vida do proceso pertence ao xestor de servizos e a saúde da aplicación pertence á monitorización cun mandato estreito.

Que pode e que non pode facer unha opción de vitalidade

keepalive é un auxiliar que se expande nun par ping e ping-restart, como describe a referencia de opcións de ligazón, e os tempos de espera que produce non son idénticos no servidor e no cliente. Os valores que empuxa un servidor tamén poden anular o que un cliente configurou localmente, e por iso un tempo de espera que parece correcto nun ficheiro local pode non ser o que está en vigor.

Iso convérteo na ferramenta axeitada para un par perdido e na ferramenta equivocada para un proceso morto, xa que un proceso rematado non pode executar os seus propios temporizadores. Tampouco di nada sobre se responde unha aplicación detrás do túnel, porque o intercambio ocorre entre os dous extremos do VPN. Copiar un par de tempos de espera doutra instalación sen comprobar o rol, as interrupcións previstas e o comportamento de reautenticación é como un túnel estable comeza a oscilar.

Que posúe o xestor de servizos

Se o daemon sae, o xestor que o iniciou decide que pasa despois. Unha política de reinicio ligada ao fallo, cun atraso e un límite de taxa de arranque, xestiona un bucle de caídas sen convertelo nunha fork bomb. Eses axustes responden aos resultados do proceso e aos tempos de espera, e non detectan un proceso que está vivo pero é inútil. Iso non é un oco para tapar cunha política máis ampla; é a fronteira entre o ciclo de vida e a vitalidade.

A propiedade importa tanto coma os axustes. Unha conexión iniciada por un xestor de rede de escritorio debería conservar o arranxo de recuperación dese xestor, e engadir unha unidade de servizo competidora para a mesma interface dá dous propietarios a un só túnel. Escolla un e deixe escrito cal é.

Cando é lexítimo un reinicio programado

Un reinicio temporizado pode ser unha acción de mantemento razoable: ten un propietario, unha xanela, unha instancia con nome e unha vía de acceso independente. O que non pode ser é unha política xeral de fiabilidade que ademais desconecte a todos a unha hora fixa.

Se o reinicio existe para sortear unha fuga coñecida ou un estado atascado, dígao na descrición da unidade, porque se non a persoa seguinte manterao para sempre.

Probe os casos que importan: o par desaparece mentres o proceso segue activo, o proceso remata, un reintento necesita credenciais novas e o túnel volve mentres a aplicación segue rota. Observe que compoñente reacciona e que estado deixa atrás.

A pregunta correcta non é con que frecuencia reiniciar, senón que debería notar o fallo primeiro.