O que persist-tun e persist-key realmente sobrevivem no OpenVPN

Parar o serviço remove a interface mesmo com persist-tun definido. Essa é a opção funcionando como documentado, não uma falha. A opção descreve um caminho de reinício dentro de um processo em execução, e systemctl stop não é esse caminho.

Leia os dois nomes juntos e o desenho fica claro. Um mantém um descritor, o outro mantém material de chave, e ambos existem por causa do que acontece depois que os privilégios são largados.

Os dois recursos e a reinicialização a que pertencem

OpenVPN sinaliza sua própria reinicialização em duas situações comuns. Um SIGUSR1 explícito faz isso, e um ping-restart acionado por um par morto faz o mesmo. Ambos mantêm o processo vivo e executam novamente a configuração da conexão, e é aí que as opções ganham seu lugar.

Apenas a linha da reinicialização suave é o que essas duas opções mudam, e o trabalho que elas pulam é a parte cara em um link movimentado. Reabrir um dispositivo derruba os endereços e rotas ligados a ele, e reconstruí-los pode derrubar pacotes que estavam em trânsito quando a reinicialização começou. Uma parada destrói os mesmos objetos sem qualquer opção para preservá-los.

Por que as opções existem afinal

Um servidor OpenVPN endurecido normalmente inicia como root, abre suas chaves e seu dispositivo e depois passa para um usuário sem privilégios. Após essa passagem, algumas operações simplesmente desaparecem. Ler um arquivo de chave com modo 0600, criar uma interface de rede ou alterar rotas podem ser recusados.

Sem as opções persist, um par que fique em silêncio o tempo suficiente para acionar ping-restart forçaria exatamente essas operações. A reconexão falharia mesmo que nada na configuração tivesse mudado. O processo pareceria morrer sem motivo, e o log mostraria um erro de permissão em vez de um erro de rede.

Com elas, a reinicialização suave reutiliza o que a fase privilegiada já obteve. Não há magia e o processo não sobrevive a nada. A aquisição de recursos é simplesmente adiada.

Leia o primeiro erro, não o último

Quando uma reinicialização falha, leia o primeiro erro em vez do último. Uma chave protegida, um arquivo auth, um ioctl de interface e um hook externo são quatro recursos diferentes. Reter um não diz nada sobre o acesso aos outros. Um hook que chama uma ferramenta de firewall ainda precisa dos privilégios que essa ferramenta exige.

Os hooks têm seu próprio interruptor. O manual do OpenVPN emparelha as opções persist com up-restart, que decide se os scripts up e down são executados novamente após uma reinicialização. Uma interface que permaneceu no ar, portanto, não lhe diz nada sobre se a sua integração de resolução foi atualizada.

# which restart path just happened?
journalctl -u openvpn-client@office --since '10 min ago' | grep -E 'SIGUSR1|ping-restart|Restart pause|NOTE:'

# did the interface survive, and do its routes still exist?
ip -brief link show tun0
ip route show dev tun0

Esse par de comandos separa os dois modos de falha em segundos. Uma interface presente com rotas ausentes é um problema de hook ou de rota. Uma interface que desapareceu significa que o processo realmente terminou.

Uma interface mantida não é um kill switch

Se o requisito é que o tráfego nunca saia fora do túnel, um dispositivo mantido não entrega isso. As rotas para a outra família de endereços, uma segunda rota padrão e o caso em que o processo sai por completo ficam todos fora do alcance da opção.

Trate os dois requisitos separadamente. Manter o objeto do túnel entre reconexões é uma conveniência para o daemon. Bloquear a saída quando o túnel está fora é uma política de firewall com suas próprias regras e seu próprio teste. Confundir os dois produz uma configuração que parece defensiva e se comporta como uma reconexão de melhor esforço.

Nomeie o evento antes de diagnosticá-lo. Uma reinicialização suave, uma tentativa de conexão falha e uma parada de serviço são três eventos com três comportamentos, e só o primeiro é o que essas opções descrevem.