Reiniciar o OpenVPN todos os dias? Escolha a falha, não o relógio

Você herda uma tarefa cron que reinicia o OpenVPN todos os dias às 04:10, e ela mantém as coisas estáveis há um ano. Ela também desconecta um túnel saudável num horário fixo e não faz nada pela queda que de fato acontece na hora do almoço. Um reinício por calendário é uma decisão de manutenção. A recuperação é um projeto diferente, com um gatilho específico.

Três formas de falha precisam de três donos diferentes. Escolha a falha primeiro, e o mecanismo virá em seguida.

Três falhas, três donos

Um túnel pode estar ativo enquanto seu par sumiu: o processo roda, a interface existe e nada útil a atravessa. Um processo pode estar morto enquanto o par está bem, e nesse caso só o que o iniciou pode trazê-lo de volta. Uma aplicação atrás do túnel pode estar quebrada enquanto o túnel e o par estão saudáveis, e reiniciar o cliente então amplia a queda sem tocar na causa. Separar esses três casos é toda a decisão.

Cada um tem seu próprio sinal e seu próprio dono. A vivacidade pertence ao protocolo VPN, o ciclo de vida do processo pertence ao gestor de serviços, e a saúde da aplicação pertence ao monitoramento com um mandato estreito.

O que uma opção de vivacidade pode e não pode fazer

keepalive é um auxiliar que se expande num par ping e ping-restart, como descreve a referência de opções de enlace, e os tempos limite que produz não são idênticos no servidor e no cliente. Valores enviados por um servidor também podem sobrescrever o que um cliente configurou localmente, e é por isso que um tempo limite que parece certo num arquivo local pode não ser o que está em vigor.

Isso o torna a ferramenta certa para um par perdido e a ferramenta errada para um processo morto, já que um processo encerrado não consegue rodar seus próprios temporizadores. Ele também não diz nada sobre se uma aplicação atrás do túnel responde, porque a troca acontece entre os dois pontos de extremidade da VPN. Copiar um par de tempos limite de outra implantação sem verificar papel, interrupções esperadas e comportamento de reautenticação é como um túnel estável começa a oscilar.

O que o gestor de serviços possui

Se o daemon sair, o gestor que o iniciou decide o que acontece depois. Uma política de reinício baseada em falha, com atraso e limite de taxa de inicialização, trata um ciclo de queda sem transformá-lo numa fork bomb. Esses ajustes respondem a resultados do processo e a tempos limite, e não detectam um processo vivo mas inútil. Isso não é uma lacuna a tapar com uma política mais ampla; é a fronteira entre ciclo de vida e vivacidade.

A propriedade importa tanto quanto os ajustes. Uma conexão iniciada por um gestor de rede da área de trabalho deve manter o arranjo de recuperação desse gestor, e adicionar uma unidade de serviço concorrente para a mesma interface dá a um único túnel dois donos. Escolha um e escreva qual é.

Quando um reinício agendado é legítimo

Um reinício em horário fixo pode ser uma ação de manutenção razoável: tem dono, janela, instância nomeada e um caminho de acesso independente. O que ele não pode ser é uma política geral de confiabilidade que também desconecta todo mundo num horário fixo.

Se o reinício existe para contornar um vazamento conhecido ou um estado travado, diga isso na descrição da unidade, porque senão a próxima pessoa o mantém para sempre.

Teste os casos que importam: o par desaparece enquanto o processo continua ativo, o processo sai, uma nova tentativa exige credenciais novas, e o túnel volta enquanto a aplicação continua quebrada. Observe qual componente reage e que estado ele deixa para trás.

A pergunta certa não é com que frequência reiniciar, mas o que deveria notar a falha primeiro.