vpn.persistent continua a provare, ma non ti tiene connesso

NetworkManager espone una proprietà, vpn.persistent, e le persone le chiedono di rispondere a quattro domande diverse contemporaneamente. La documentazione a monte è attenta: la persistenza si applica quando il servizio VPN la supporta e il profilo la abilita, e alla connessione viene poi chiesto di sopravvivere ai cambi di collegamento e alle interruzioni fino a una disconnessione esplicita. La stessa documentazione mostra anche che la proprietà vale false per impostazione predefinita, cosa che la maggior parte dei piani di ripristino non presuppone. Leggila come una richiesta di tentativo, non come la promessa di un risultato.

A cosa si impegna davvero l'impostazione

Un valore memorizzato in un profilo è un'istruzione per il gestore, e il gestore deve consegnare quell'istruzione a un plugin VPN che sappia cosa farne. Se il plugin installato ignora la proprietà, il profilo si attiva comunque e il registro resta silenzioso, che è il peggio dei due mondi per chiunque farà debug in seguito. Nulla dentro un profilo può costringere un plugin a implementare un comportamento che non ha, quindi l'unico risultato visibile è un'assenza.

Ecco perché la condizione nella documentazione conta più dell'interruttore. Controlla quale plugin e quale versione hai davvero, e scrivi la versione accanto alla descrizione della connessione così che la prossima persona non debba riscoprirla. Una politica di ripristino costruita su un flag non implementato fallisce esattamente una volta in produzione e sempre nel momento più scomodo.

Trattare la proprietà come un tentativo imposta anche l'aspettativa giusta per i test. Non controlli se il flag è impostato; controlli se è successo qualcosa quando il collegamento è caduto. Sono esperimenti diversi, e solo uno dei due vale un pomeriggio.

Quattro domande fuse in una

L'attivazione chiede cosa tira su la VPN in primo luogo. Un profilo NetworkManager può essere legato a una connessione di base, un servizio OpenVPN gestito separatamente ha un proprio avvio, e aggiungere un terzo lanciatore a questa disposizione ti dà due proprietari con idee diverse su chi comanda. Decidi quale componente possiede l'avvio prima di aggiungere un altro trigger.

Il ripristino chiede cosa succede quando il collegamento cambia o scompare, ed è la questione stretta che vpn.persistent affronta. La vitalità chiede se il client riesce a capire che l'estremità remota ha smesso di rispondere, e al suo posto risponde il comportamento di keepalive o di riavvio di OpenVPN; i due meccanismi sono spesso descritti con la stessa parola e implementati in luoghi diversi. Provali separatamente, con strumenti diversi, altrimenti attribuirai un comportamento all'altro.

L'intenzione chiede se la riconnessione sia desiderata affatto, ed è la domanda a cui il sondaggio di stato non può rispondere. Un arresto deliberato e un'interruzione producono lo stesso stato inattivo, quindi qualunque cosa si riconnetta per assenza sta indovinando una decisione umana. Indovinare va bene fino al momento in cui scavalca qualcuno.

Una lista di controllo che le tiene separate

Esegui gli eventi in ordine invece di leggere la configurazione e ragionarci sopra, e registra cosa mostra ciascuno con una marca temporale.

Primo, attiva la connessione di base prevista e conferma che la VPN è salita tramite il trigger che ti aspettavi e non tramite un meccanismo che avevi dimenticato installato. Secondo, durante un'interruzione approvata, confronta gli eventi VPN del gestore, lo stato di ripristino del client proprietario e una nuova richiesta a una risorsa privata. Terzo, disconnetti deliberatamente, attendi e conferma che nulla riavvia il profilo alle tue spalle.

Il terzo passo è quello che la gente salta, ed è quello che trova il vero difetto più spesso. Un watchdog che interroga un profilo attivo e si riconnette quando manca annullerà allegramente una disconnessione intenzionale dell'utente. Dal punto di vista dell'utente non è resilienza; è una macchina che non obbedirà. Chiedi a loro prima di aggiungerne uno.

Scrivi i risultati nello stesso documento della descrizione della connessione. Una politica di ripristino vale quanto l'ultima volta che qualcuno l'ha vista fallire di proposito. Le marche temporali rendono la differenza visibile a chiunque leggerà le note in seguito.

L'autenticazione fa parte del ripristino

Riconnettersi non è un atto puramente di rete. Se il flusso approvato richiede una nuova sfida, un codice monouso o un segreto a cui il contesto di attivazione non può arrivare, nessuna impostazione di persistenza può produrlo dal nulla.

Questo spiega uno schema familiare: la connessione si ripristina su una macchina con il portachiavi sbloccato e fallisce sulla stessa macchina dopo un riavvio. Il livello di rete ha fatto esattamente ciò che gli è stato chiesto e il livello delle credenziali non aveva nulla da offrire.

Correggi il flusso delle credenziali invece di accorciare l'intervallo di tentativi. Tentativi più rapidi contro una richiesta a cui nessuno può rispondere generano rumore nei registri e una falsa impressione che qualcosa venga tentato.

La persistenza non è un kill switch

La proprietà cerca di mantenere o ripristinare la relazione VPN. Non decide cosa possono fare le applicazioni mentre la VPN è inattiva, e non blocca nulla da sola.

Se il requisito è che nessun traffico esca fuori dal tunnel, quella è una politica separata con il proprio meccanismo, i propri test e i propri modi di fallire. Presumere che la persistenza lo copra trasforma una decisione di sicurezza in un incidente.

Registra entrambe le metà nelle note di ripristino: cosa ha tentato la VPN e quale traffico applicativo è stato consentito mentre il tentativo era in corso.