Reiniciar un servizo en OpenVPN up: os hooks gañan a tun0.device

Conectar un servizo dependente a tun0.device parece subscribirse ao túnel, e non o é. Unha unidade de dispositivo reflicte que a interface existe, o que pode seguir sendo certo durante unha conexión fallida e a reconexión que a segue. Entón o servizo actúa no momento equivocado, ou nunca, segundo se a interface desapareceu mentres tanto. O hook que describe o evento que realmente che importa é o que chama OpenVPN, non o que infire systemd.

Decide que condición necesita o servizo antes de escoller o disparador, porque os tres candidatos non son intercambiables.

Que segue realmente a unidade de dispositivo

systemd crea unha unidade de dispositivo a partir da visión do kernel sobre unha interface de rede, así que tun0.device actívase cando aparece a interface e desactívase cando se elimina. Con persist-tun, un reinicio suave mantén a interface no seu sitio, así que a unidade nunca oscila e nada vinculado a ela se dispara. Mesmo sen persistencia, a unidade non di nada sobre rutas, DNS nin se o extremo remoto responde.

Iso convértea nun mal substituto de 'a VPN está lista'. Un oínte que só necesita o enderezo local pode conformarse coa existencia da interface, mentres que un servizo que chama unha aplicación na rede remota necesita rutas e accesibilidade, que a unidade de dispositivo non pode expresar.

up, route-up e up-restart significan cousas distintas

up execútase despois de abrir o dispositivo TUN/TAP e configurar a interface, que é o momento axeitado para un oínte que liga o enderezo asignado. route-up execútase despois de instalar as rutas, suxeito a calquera atraso de ruta configurado, e encaixa nun traballo que necesita a etapa de rutas completa. Ningún dos dous demostra que a aplicación remota responda. Escoller entre eles é unha cuestión do que necesita o servizo, non de que hook soa máis rematado.

Con persist-tun, os reinicios reutilizan o dispositivo, así que up non se executa de novo a menos que se estableza up-restart. Esa opción habilita o script up para o ciclo de vida de reinicio documentado, e o seu contorno é reducido en comparación cun primeiro arranque. Un script que asume o contorno completo funciona na primeira conexión e falla na seguinte.

Enviar a acción sen esperar por ela

Un hook que chama systemctl restart de forma síncrona pode bloquearse contra unha unidade cuxa orde espera o túnel. systemctl --no-block try-restart vpn-dependent.service pon o traballo en cola e volve, o que impide que o hook bloquee a conexión á que estaba reaccionando. try-restart actúa só sobre unha unidade en execución, mentres que restart tamén inicia unha inactiva; escolle deliberadamente, non por costume.

Pór en cola non é verificar. O hook devolve éxito en canto se acepta o traballo, así que a comprobación debe ocorrer no rexistro da unidade obxectivo ou no seu estado real de escoita.

A política de reinicio vive na unidade, non no hook

Unha unidade oneshot con RemainAfterExit=yes permanece activa despois de que o seu comando saia, e unha segunda solicitude de inicio non fai nada porque systemd a considera xa iniciada. Iso é unha propiedade coa que hai que deseñar, non un defecto que se sortee con chamadas de inicio repetidas. Se a acción debe executarse por conexión, a unidade necesita unha forma que o permita.

After= ordena unidades e BindsTo= ata vidas, pero ningún dos dous significa 'reinicia isto cada vez que a VPN se reconecte'. Unha unidade vinculada ao túnel detense cando o túnel se detén; non se reinicia soa cando o túnel volve, a menos que algo a inicie de novo.

Proba tres reconexións, non unha

O arranque en frío, un reinicio completo do cliente e unha reconexión suave exercitan cada un un camiño distinto. A reconexión suave é a que expón un up-restart ausente, un contorno reducido ou unha unidade de dispositivo que nunca se desactivou. Executa as tres e confirma ambas as direccións: o servizo actúa cando o túnel sobe, e non se reinicia ante cambios de enlace non relacionados como un roaming Wi-Fi.

Mantén un camiño de recuperación independente cando o servizo dependente leva o teu propio acceso administrativo. Un hook que reinicia aquilo polo que estás conectado é un cambio que te pode deixar fóra.