Que sobreviven realmente persist-tun e persist-key en OpenVPN

Deter o servizo elimina a interface mesmo con persist-tun definido. Esa é a opción funcionando tal como está documentada, non un fallo. A opción describe unha ruta de reinicio dentro dun proceso en execución, e systemctl stop non é esa ruta.

Lea os dous nomes xuntos e o deseño queda claro. Un conserva un descritor, o outro conserva material de clave, e ambos existen polo que ocorre despois de soltar os privilexios.

Os dous recursos e o reinicio ao que pertencen

OpenVPN sinala o seu propio reinicio en dúas situacións habituais. Un SIGUSR1 explícito faino, e un ping-restart provocado por un par morto fai o mesmo. Ambos deixan vivo o proceso e volven executar a configuración da conexión, e aí é onde as opcións gañan o seu lugar.

Só a fila do reinicio suave é o que cambian estas dúas opcións, e o traballo que saltan é a parte cara nunha ligazón ocupada. Reabrir un dispositivo derruba os enderezos e rutas asociadas a el, e reconstruílas pode perder paquetes que estaban en voo cando comezou o reinicio. Unha parada destrúe os mesmos obxectos sen ningunha opción para conservalos.

Por que existen as opcións en absoluto

Un servidor OpenVPN endurecido adoita arrincar como root, abre as súas claves e o seu dispositivo e despois pasa a un usuario sen privilexios. Tras ese paso, algunhas operacións simplemente desaparecen. Ler un ficheiro de clave con modo 0600, crear unha interface de rede ou cambiar rutas poden ser rexeitados.

Sen as opcións persist, un par que calase o tempo suficiente para activar ping-restart forzaría exactamente esas operacións. A reconexión fallaría aínda que nada da configuración cambiase. O proceso parecería morrer sen motivo, e o rexistro mostraría un erro de permisos en lugar dun erro de rede.

Con elas, o reinicio suave reutiliza o que a fase privilexiada xa obtivo. Non hai maxia e o proceso non sobrevive a nada. A adquisición de recursos simplemente aprazase.

Lea o primeiro erro, non o último

Cando un reinicio falla, lea o primeiro erro en lugar do último. Unha clave protexida, un ficheiro auth, un ioctl de interface e un hook externo son catro recursos distintos. Conservar un non di nada sobre o acceso aos demais. Un hook que chama unha ferramenta de devasa aínda necesita os privilexios que esa ferramenta esixe.

Os hooks teñen o seu propio interruptor. O manual de OpenVPN emparexa as opcións persist con up-restart, que decide se os scripts up e down se executan de novo tras un reinicio. Unha interface que quedou arriba, por tanto, non lle di nada sobre se se refrescou a súa integración de resolución.

# 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

Ese par de ordes separa os dous modos de fallo en segundos. Unha interface presente con rutas ausentes é un problema de hook ou de ruta. Unha interface que desapareceu significa que o proceso realmente rematou.

Unha interface conservada non é un kill switch

Se o requisito é que o tráfico nunca saia fóra do túnel, un dispositivo conservado non o entrega. As rutas para a outra familia de enderezos, unha segunda ruta predeterminada e o caso en que o proceso sae do todo quedan todos fóra do alcance da opción.

Trate os dous requisitos por separado. Conservar o obxecto do túnel entre reconexións é unha comodidade para o demonio. Bloquear a saída cando o túnel está caído é unha política de devasa coas súas propias regras e a súa propia proba. Confundilos produce unha configuración que parece defensiva e compórtase como unha reconexión de mellor esforzo.

Nomee o evento antes de diagnosticalo. Un reinicio suave, un intento de conexión fallido e unha parada do servizo son tres eventos con tres comportamentos, e só o primeiro é o que describen estas opcións.