Saltare la VPN di casa con un systemd ExecCondition

La VPN della rete domestica non ha nulla da fare quando il portatile è già su quella rete. La scorciatoia tentante è un comando di preparazione che esce con un codice diverso da zero; questo fa fallire l'unit e rende ogni dashboard simile a qualcosa di rotto. systemd ha una direttiva per esattamente questa forma di decisione, e separa un salto deliberato da un guasto reale. Farlo bene significa soprattutto scrivere che cosa significhi ogni codice di uscita.

Perché una precondizione che fallisce è la forma sbagliata

ExecStartPre tratta un'uscita diversa da zero come un errore di avvio, il che è corretto per un comando che prepara il servizio. Usarlo come condizione rende una decisione di policy indistinguibile da una dipendenza rotta. ExecCondition esiste perché un'unit possa rifiutarsi di partire senza essere contrassegnata come fallita.

Questa distinzione conta alle tre del mattino, quando nessuno vuole analizzare un'unit rossa che si comportava come previsto. Un'unit fallita nasconde anche i guasti reali tra quelli intenzionali.

Scrivete prima il contratto dei codici di uscita

Scrivete il contratto prima dello script. L'uscita zero significa continuare, l'uscita uno significa saltare i comandi di avvio rimanenti, e l'uscita 255 significa che la condizione stessa non ha potuto essere eseguita. I codici tra due e 254 di solito significano anch'essi saltare, cosa facile da dimenticare quando un helper restituisce un codice di errore casuale. Il drop-in qui sotto collega l'helper al nome reale dell'unit.

[Service]
ExecCondition=/usr/local/libexec/should-start-home-vpn

Controllate l'unit effettiva per eventuali SuccessExitStatus o impostazioni stop-post ereditate prima di supporre la semantica predefinita. Poi provate deliberatamente ciascuno dei tre esiti.

Un indizio di rete non è prova della posizione

Un indirizzo di router raggiungibile o un MAC noto possono suggerire la rete giusta, e nessuno dei due lo dimostra. Un'altra rete può riutilizzare lo stesso indirizzo, i dati ARP possono essere obsoleti e gli identificatori possono essere imitati. Trattate la sonda come un'ottimizzazione coerente con la policy, non come un risultato di autenticazione.

Decidete in anticipo che cosa significa l'incertezza. Avviare la VPN quando non siete sicuri è sicuro per un client che semplicemente non riuscirebbe a connettersi; saltarla quando non siete sicuri non lo è. Rendete la sonda limitata e leggete l'interfaccia attiva invece di supporre la prima dell'elenco. Una sonda che si blocca è peggio di una che risponde no, perché l'unit la aspetta.

Annotate queste ipotesi accanto al file dell'unit, così la persona successiva sa che cosa crede l'helper. Un commento in cima allo script è il posto più economico per conservarle.

Gestite il passaggio tra reti

La condizione viene eseguita all'avvio del servizio e non viene rivalutata in seguito. Un'unit saltata resta saltata dopo che il portatile si sposta in un bar, e un tunnel attivo resta su dopo che il portatile torna a casa. Collegate il ciclo di vita del cambio di rete alla decisione di avvio e arresto con un meccanismo separato.

systemctl cat home-vpn.service

Provate quattro casi: avvio a casa, avvio fuori casa, una sonda che non può essere eseguita e un passaggio tra reti mentre l'unit è attiva. Tenete visibile nel journal il motivo del salto, così una decisione intenzionale non sembri mai un errore di autenticazione. Il riferimento del servizio documenta la semantica di uscita e la versione minima.