Due dispositivi, un certificato OpenVPN: il ciclo di riconnessione

Un tunnel che sale e poi si riavvia ogni mezzo minuto di solito non è un problema di cifratura né di MTU. È un’identità usata due volte. Il server vede un nome comune familiare, prende la nuova sessione come la più recente, e il dispositivo più vecchio scopre di essere stato sostituito. Dal lato client sembra un timeout di inattività e un riavvio, ed è per questo che l’indagine così spesso parte dal posto sbagliato.

Parti dall’intervallo di riavvio

L’intervallo è un indizio prima di ogni altra cosa. Una cadenza regolare che coincide con la finestra ping-restart indica una sessione sostituita più che un percorso guasto, perché i guasti di percorso raramente sono così regolari. Annota l’intervallo esatto tra i riavvii e la riga di motivo nel log del client. Un timeout seguito da un riavvio racconta una storia diversa da una stretta di mano fallita.

Controlla quando sono iniziati i riavvii rispetto a un secondo dispositivo. Un portatile nuovo, un telefono o un profilo copiato su una macchina di riserva sono i trigger abituali, e il momento di solito coincide con il giorno in cui qualcuno lo ha configurato.

Annota l’intervallo e il motivo. Entrambi sono prove, ed entrambi costano poco da raccogliere.

Leggi cosa ha detto il server sul secondo accesso

Su un server che controlli, il log nomina il nome comune e mostra una seconda connessione in arrivo. Senza duplicate-cn quell’arrivo sostituisce la sessione esistente per lo stesso nome, e il messaggio di solito lo dice chiaramente. Con duplicate-cn le due sessioni convivono e il sintomo cambia: i client restano attivi ma condividono un solo insieme di impostazioni per client e una sola decisione di revoca. Leggi le due voci insieme, perché la sostituzione si vede solo in sequenza.

Su un servizio ospitato potresti non avere alcun log del server. L’indizio è allora il momento: un tunnel stabile che cade ogni volta che si connette un’altra macchina, senza nulla nel log del client oltre al timeout.

Confronta i blocchi di certificato e chiave nei due profili, non solo il nome host remoto. I profili copiati di solito differiscono solo nel nome del file.

Separa l’identità dal lato server

Emetti un certificato per dispositivo tramite l’autorità che firma per questo server. Con Easy-RSA ciò significa un nome client separato per ogni dispositivo, e il profilo viene poi costruito da quel certificato e dalla sua chiave. Il nome comune diventa l’identità del dispositivo, ed è esattamente ciò che mancava al server. Assegna i nomi in base al dispositivo e non alla persona, così una sostituzione produce un nome nuovo.

La chiave condivisa del canale di controllo è un’altra cosa. tls-crypt o tls-auth protegge il canale di controllo per ogni client ed è pensata per essere condivisa. Non è un’identità client, e sostituirla non riparerà un certificato duplicato.

Tieni certificato, chiave e ogni file di configurazione per client sotto lo stesso nome comune, altrimenti la mappatura si rompe alla connessione successiva. Una discrepanza lì produce un client che si autentica e poi non riceve nulla.

Mantieni indirizzi e impostazioni allineati dopo la separazione

Gli indirizzi fissi introducono un secondo modo di entrare in collisione. Se il server li assegna tramite ifconfig-pool-persist o un file per client, quei record puntano ancora al vecchio nome. Due dispositivi possono ritrovarsi con lo stesso indirizzo del tunnel anche dopo aver separato i certificati, e quel guasto appare diverso dal ciclo originale.

Aggiorna la mappatura insieme al certificato, poi riconnetti entrambi i dispositivi e confronta gli indirizzi assegnati. Un indirizzo duplicato si manifesta come perdita intermittente anziché come riconnessione pulita.

Invia le impostazioni che devono differire per dispositivo tramite il file di quel dispositivo, non tramite un modello condiviso. Un modello condiviso rende anche il prossimo duplicato più difficile da notare.

Dismetti l’identità vecchia come si deve

Revoca il certificato quando l’hardware viene dismesso o manca, invece di cancellare il profilo dalla vecchia macchina. La revoca produce una nuova CRL, e il server ha bisogno di quel file dove punta crl-verify. Con quella direttiva al suo posto, una CRL assente o illeggibile fa rifiutare ogni client al server, quindi prova un account noto dopo ogni aggiornamento.

Tieni un inventario che lega ogni certificato a una persona o a un dispositivo, con date di emissione e di revoca. Quell’inventario risponde a chi ha ancora accesso senza leggere i nomi dei file, e impedisce al prossimo profilo copiato di riavviare il ciclo.