Un hook di sospensione da solo non riporta su la VPN

Un hook che esce con zero dimostra solo che lo script è stato eseguito. Mettilo dopo la rete, usa l'identità giusta e verifica se il profilo è persino idoneo.

Metti un comando di riconnessione nell'hook di sospensione e il problema sembra risolto. È risolto solo se l'hook viene eseguito dopo che la rete esiste, con un'identità che il client riconosce, attraverso un percorso che il client implementa davvero. La maggior parte dei guasti dopo la ripresa è uno di questi tre, e nessuno di essi appare come errore nell'hook stesso. L'hook restituisce comunque successo.

Uno script che esce con zero non ti ha detto nulla sul fatto che un tunnel sia tornato.

L'hook viene eseguito, e poi?

#!/bin/sh
case "$1" in
  pre)
    vpn-client disconnect
    ;;
  post)
    vpn-client connect
    ;;
esac

Ogni evento richiama l'hook due volte, prima e dopo la transizione, passandogli la fase e il nome dell'evento. Viene eseguito come root con un ambiente minimo, quindi servono percorsi assoluti e non va attesa alcuna variabile di sessione desktop. Il ritorno rapido di entrambe le chiamate dice solo che lo script è stato eseguito. Se il profilo sia salito dopo è un'osservazione separata e richiede la propria prova nel registro.

Tratta l'argomento della fase come parte del progetto. Un tentativo di riconnessione nella fase pre avviene mentre la macchina sta per perdere tutto, e non può riuscire.

Root, ambiente minimo, utente sbagliato

Se il client conserva il token di accesso per utente, eseguire l'hook come root lo lascia senza nulla da presentare. Controlla lo stato sotto l'identità che l'hook usa davvero, non quella che hai provato da un terminale desktop. Alcune build lasciano anche un demone che tiene l'interfaccia dopo una disconnessione, così una riconnessione finisce in uno stato obsoleto, e ripulire prima il processo lo ripristina al costo di uno spegnimento non pulito. Nessuno dei due comportamenti è visibile se provi solo il percorso felice.

Scrivi l'hook con percorsi assoluti, tienilo di proprietà di root ed eseguibile, e registra cosa ha fatto. Senza quel registro la prossima indagine parte da zero.

La connessione automatica non è il percorso della VPN

NetworkManager offre due meccanismi di attivazione: un flag di connessione automatica sul profilo e connessioni secondarie che partono quando si attiva un profilo primario. I tipi di dispositivo nativi implementano il primo; i plugin VPN storicamente hanno implementato solo il secondo, quindi spuntare la connessione automatica su un profilo OpenVPN può non avere alcun effetto. Ispeziona entrambe le proprietà, poi collega la VPN come secondaria del profilo Wi-Fi o Ethernet.

[Unit]
PartOf=NetworkManager.service
Requires=NetworkManager-wait-online.service
After=NetworkManager-wait-online.service

Un'interfaccia WireGuard gestita da un'unità systemd ha bisogno di quel file aggiuntivo invece di un hook, ordinato dopo che la rete è in linea.

Attendi la rete, con un tetto

timer=1
while ! ping -c1 -n -w1 203.0.113.1 >/dev/null; do
  sleep 1; timer=$((timer+1))
  [ $timer -ge 300 ] && exit 0
done
nmcli connection up "work-vpn"

Alla ripresa il tunnel può essere richiesto mentre il Wi-Fi si riassocia ancora, il che rende ogni attesa fissa una congettura. Attendi un indirizzo raggiungibile, poi alza il profilo, e limita l'attesa perché un hook non possa tenere il percorso di ripresa aperto all'infinito. Preferisci il nome del profilo a un indice numerico, e se il profilo corretto varia con la rete, fai registrare in anticipo la scelta dal tunnel sano in un file.

Guardati anche dalle tempeste di riavvio, contando i tentativi e fermandoti. Un watchdog che reagisce a ogni sonda fallita trasforma un'interruzione in un ciclo.

Sospendi una volta, poi leggi il journal per l'output dell'hook stesso. È l'unico test che dimostra l'ordine.

Articoli correlati