Riavviare un servizio su OpenVPN up: gli hook battono tun0.device

Collegare un servizio dipendente a tun0.device sembra un abbonamento al tunnel, e non lo è. Un’unità di dispositivo riflette l’esistenza dell’interfaccia, che può restare vera attraverso una connessione fallita e la riconnessione che segue. Il servizio agisce allora nel momento sbagliato, o mai, a seconda che l’interfaccia sia sparita nel frattempo. L’hook che descrive l’evento che vi interessa davvero è quello che chiama OpenVPN, non quello che systemd deduce.

Decidete quale condizione serve al servizio prima di scegliere il trigger, perché i tre candidati non sono intercambiabili.

Che cosa segue davvero l’unità di dispositivo

systemd crea un’unità di dispositivo dalla visione del kernel su un’interfaccia di rete, quindi tun0.device diventa attiva quando l’interfaccia appare e inattiva quando viene rimossa. Con persist-tun, un riavvio morbido mantiene l’interfaccia al suo posto, quindi l’unità non oscilla mai e nulla di legato ad essa viene attivato. Anche senza persistenza, l’unità non dice nulla su route, DNS o se l’estremità remota risponde.

Ciò la rende un cattivo sostituto di ’la VPN è pronta’. Un listener che ha bisogno solo dell’indirizzo locale può accontentarsi dell’esistenza dell’interfaccia, mentre un servizio che chiama un’applicazione sulla rete remota ha bisogno di route e raggiungibilità, che l’unità di dispositivo non può esprimere.

up, route-up e up-restart significano cose diverse

up viene eseguito dopo che il dispositivo TUN/TAP è aperto e l’interfaccia è configurata, che è il momento giusto per un listener che lega l’indirizzo assegnato. route-up viene eseguito dopo l’installazione delle route, soggetto a qualsiasi ritardo di route configurato, e si adatta a un lavoro che richiede la fase di route completata. Nessuno dei due dimostra che l’applicazione remota risponda. Scegliere tra loro è una questione di ciò che serve al servizio, non di quale hook suona più finito.

Con persist-tun, i riavvii riutilizzano il dispositivo, quindi up non viene eseguito di nuovo a meno che up-restart non sia impostato. Quell’opzione abilita lo script up per il ciclo di vita di riavvio documentato, e il suo ambiente è ridotto rispetto a un primo avvio. Uno script che presuppone l’ambiente completo funziona alla prima connessione e fallisce alla successiva.

Inviate l’azione senza attenderla

Un hook che chiama systemctl restart in modo sincrono può bloccarsi contro un’unità il cui ordinamento attende il tunnel. systemctl --no-block try-restart vpn-dependent.service mette il lavoro in coda e ritorna, il che impedisce all’hook di bloccare la connessione a cui stava reagendo. try-restart agisce solo su un’unità in esecuzione, mentre restart avvia anche una unità inattiva; scegliete deliberatamente, non per abitudine.

Mettere in coda non è verificare. L’hook restituisce successo non appena il lavoro è accettato, quindi il controllo deve avvenire nel journal dell’unità di destinazione o nel suo stato reale di listener.

La politica di riavvio vive nell’unità, non nell’hook

Un’unità oneshot con RemainAfterExit=yes resta attiva dopo l’uscita del suo comando, e una seconda richiesta di avvio non fa nulla perché systemd la considera già avviata. Questa è una proprietà attorno a cui progettare, non un difetto da aggirare con chiamate di avvio ripetute. Se l’azione deve essere eseguita per ogni connessione, l’unità ha bisogno di una forma che lo consenta.

After= ordina le unità, e BindsTo= lega le durate di vita, ma nessuno dei due significa ’riavvia questo ogni volta che la VPN si riconnette’. Un’unità legata al tunnel si ferma quando il tunnel si ferma; non si riavvia da sola quando il tunnel ritorna, a meno che qualcosa non la avvii di nuovo.

Provate tre riconnessioni, non una

L’avvio a freddo, un riavvio completo del client e una riconnessione morbida esercitano ciascuno un percorso diverso. La riconnessione morbida è quella che rivela un up-restart mancante, un ambiente ridotto o un’unità di dispositivo che non è mai diventata inattiva. Eseguite tutte e tre e confermate entrambe le direzioni: il servizio agisce quando il tunnel sale, e non si riavvia su cambiamenti di collegamento non correlati come un roaming Wi-Fi.

Mantenete un percorso di recupero indipendente quando il servizio dipendente porta il vostro accesso amministrativo. Un hook che riavvia ciò attraverso cui siete connessi è un cambiamento che può chiudervi fuori.