keepalive no OpenVPN ou reinício no systemd: qual recupera?

Três coisas diferentes podem correr mal com um túnel, e exigem três reações diferentes. O par deixa de responder, o processo do daemon morre ou a aplicação por trás do túnel deixa de servir. Uma configuração que reinicia o serviço em qualquer delas não é supervisão cuidadosa; é uma ação grosseira aplicada a falhas não relacionadas. Comparar o que cada mecanismo pode realmente observar torna óbvia a divisão do trabalho.

Três falhas que parecem uma

O silêncio do par significa que o outro extremo deixou de enviar, e o OpenVPN pode detetá-lo sozinho porque possui o batimento. A morte do processo significa que o daemon saiu, o que o gestor de serviços nota e o OpenVPN não consegue. A falha da aplicação significa que o túnel está bem e algo por trás não, e nenhum dos outros dois mecanismos tem forma de o saber. Cada uma exige uma reação diferente, e nenhuma é o mesmo que notar que o túnel está ativo.

São sinais diferentes de camadas diferentes, e cada um tem um dono que pode agir sobre ele sem adivinhar. Misturá-los produz um sistema que reinicia perante sintomas que não consegue interpretar.

Escreva os três casos antes de alterar qualquer temporizador. A lista em si costuma mostrar que se pede a um mecanismo que cubra os três.

Para que o keepalive se expande realmente

A diretiva keepalive é uma abreviatura, e a expansão varia consoante o modo. Num servidor, keepalive 10 60 torna-se um ping local a cada dez segundos, um limite de reinício local de 120 segundos e valores 10 e 60 enviados aos clientes. O limite do servidor é deliberadamente duplicado para que um cliente tenha oportunidade de reiniciar antes de o servidor desistir. Leia a forma expandida na configuração em execução, não a abreviatura no perfil.

Essa duplicação é a razão pela qual qualquer descrição que afirme que ambos os extremos reiniciam após sessenta segundos está errada. Também explica por que os dois extremos não oscilam em uníssono quando um caminho se degrada.

O batimento é tráfego de pares do OpenVPN, não uma sonda ICMP a algum anfitrião público. Uma resposta prova apenas que o extremo distante do túnel está vivo. Não diz nada sobre a base de dados ou o serviço web de que o utilizador realmente precisa.

O que o Restart=on-failure não vigia

Leia a unidade instalada antes de acrescentar uma substituição. O Restart=on-failure responde a condições documentadas de falha do processo, o que não é o mesmo que vigiar o estado da ligação. Não dispara porque começou uma reconexão interna, e uma saída limpa tem semântica diferente de uma queda.

Essa distinção importa porque um reinício interno mantém o mesmo processo vivo. A unidade não vê nada, o túnel recupera sozinho, e esse é o resultado correto.

Defina RestartSec e os limites de arranque deliberadamente, ou um ciclo de quedas martelará a passagem e enterrará o erro real sob mensagens de reinício. Um limite de reinício que dispara deixa a unidade em falha, o que é visível, enquanto um ciclo ilimitado não é.

ping-restart e ping-exit não são intercambiáveis

ping-restart desencadeia o reinício interno do OpenVPN e mantém o processo. ping-exit termina o processo no mesmo tipo de limite, o que entrega a decisão ao gestor de serviços. São mutuamente exclusivos, e escolher o segundo muda quem é dono da recuperação. A diferença é quem decide tentar de novo e quanto estado sobrevive à tentativa.

Se escolher sair no limite, a unidade precisa de uma política de reinício e de um tratamento do estado de saída que correspondam, ou uma falha de vitalidade parecerá uma paragem permanente. As opções de persistência também podem preservar interfaces e rotas durante um reinício interno, mas não durante uma saída do processo.

Escolha um ciclo de vida por implementação e escreva porquê. Um perfil que transporta ambas as diretivas é um perfil que não decidiu.

Teste cada falha como o seu próprio caso

Simule um par silencioso, um daemon morto e uma aplicação indisponível numa janela aprovada, e depois verifique que recuperação disparou. Um par silencioso deveria produzir uma reconexão interna, um processo morto um reinício da unidade, e uma falha da aplicação nenhuma das duas. Quando dois casos produzem a mesma ação, a propriedade ainda está misturada.

A recuperação repetida também não é uma reparação. Credenciais rejeitadas ou dois clientes que partilham um nome efetivo continuarão a substituir-se, e temporizadores mais rápidos só tornam essa oscilação mais rápida.