OpenVPN avviato prima della rete non è un errore

Avviate il client al boot, l'unità riporta attivo, e il tunnel non c'è. La conclusione naturale è che il servizio non sia partito, e la correzione naturale è riavviarlo. Entrambe sono sbagliate abbastanza spesso da meritare una regola: un client in esecuzione che riprova sembra esattamente uno guasto dall'esterno. La differenza sta in ciò che fa il processo, non nello stato dell'unità.

Mito: un servizio avviato significa un tunnel funzionante

Un'unità attiva dimostra che il processo è stato avviato e non è uscito. Non dimostra che il profilo sia stato caricato, che il certificato sia stato accettato o che l'altro capo abbia risposto. Un client impacchettato può restare per minuti in un ciclo di tentativi mentre systemd non riporta altro che successo. Quello scarto tra stato e comportamento è l'intero argomento.

Il caso opposto è altrettanto comune. Il processo può essere uscito dopo non essere riuscito a leggere una chiave, e l'unità riporta allora uno stato fallito che non dice nulla sul perché. Entrambi gli stati richiedono il registro per essere distinti.

Leggete il registro dell'istanza invece dello stato dell'unità. La riga del motivo è nel registro, non nell'etichetta di stato.

Mito: le impostazioni di tentativo coprono ogni errore

La risoluzione dei nomi e i tentativi di trasporto sono controlli separati con valori predefiniti separati. resolv-retry governa le ricerche ripetute di un nome host remoto, e il valore documentato continua a provare all'infinito. connect-retry fissa l'intervallo tra i tentativi, mentre connect-retry-max può limitare quante volte viene provata ogni voce remota. Controllate quale fase nomina il registro prima di cambiarne uno.

Niente di tutto ciò vale per un profilo malformato, una chiave privata illeggibile o un account rifiutato. Questi richiedono una correzione, e un client che li riprova non avanza.

Riprovare all'infinito un certificato non approvato non è un motivo per rimuovere la verifica. È un motivo per leggere l'errore.

Mito: un lanciatore basta, quindi aggiungetene un altro

Una connessione già gestita da NetworkManager o da un'unità impacchettata non ha bisogno di un secondo lanciatore collegato. Due processi che competono per le stesse rotte producono interfacce duplicate, registri confusi e un tunnel che oscilla per motivi che nessuno vede. La seconda copia di solito arriva come aggiramento del fatto che la prima è lenta.

Decidete quale componente possiede il tunnel prima di aggiungere qualcosa. Poi rimuovete l'altro lanciatore invece di disattivarlo e sperare.

Il proprietario determina anche da dove arrivano i tentativi e le credenziali, per questo la decisione precede ogni regolazione. La proprietà viene prima esattamente per questo motivo.

Ciò che richiede davvero un ordine

L'ordine può attendere un indirizzo configurato, e questo è tutto ciò che garantisce. network-online.target ritarda l'attivazione finché il gestore considera la rete attiva, e la definizione di attiva dipende dal gestore. Non dice nulla sulla risoluzione del nome host VPN, sulla risposta dell'ascoltatore o sull'ammissione del dispositivo da parte di un portale captive.

Leggete l'unità installata e ogni drop-in prima di aggiungere dipendenze. Un After= ampio su ogni servizio di rete ritarda l'avvio senza stabilire la connessione che vi serve davvero.

Mettete in ordine la dipendenza che potete testare, e verificate tutto il resto con una sonda di disponibilità. Una sonda che apre il tunnel batte un timer che indovina.

Cosa succede dopo che il tunnel sale la prima volta

Il boot è un evento tra molti. Il collegamento di accesso cambia, una sessione del portale scade, il peer si riavvia. Distinguete una riconnessione interna da un'uscita di processo gestita dal gestore dei servizi, perché le due hanno proprietari diversi e lasciano prove diverse.

L'autenticazione interattiva limita il ripristino non presidiato. Un'unità in background non sblocca un portachiavi desktop né risponde a una richiesta MFA, quindi seguite la disposizione delle credenziali approvata per il contesto del servizio.

Decidete separatamente cosa possono fare le applicazioni mentre il tunnel è giù. Il tentativo ripristina una connessione, mentre una politica di blocco decide se il traffico diretto è consentito in quello scarto.