Un collegamento OpenVPN a chiave statica può servire più client?

La modalità a chiave statica collega esattamente due peer, e questa è la sua progettazione, non un limite che qualcuno ha dimenticato di rimuovere. client-to-client è un’opzione di inoltro della modalità server, quindi aggiungerla a una configurazione --secret non cambia nulla su quanti client possono connettersi. La decisione non è quale flag aggiungere, ma se la distribuzione richiede un collegamento punto a punto o un servizio multi-client. Se più dispositivi devono connettersi in modo indipendente, la modalità di protezione cambia e ogni dispositivo riceve un’identità.

Due peer, una chiave e nessuno stato per client: quella forma è tutta la storia della modalità.

A cosa serve la modalità a chiave statica

In modalità segreta entrambi i peer condividono un solo file di chiave, e quella chiave protegge direttamente il traffico. Non c’è stretta di mano, né scambio di certificati, né sessione per client, perché non ci sono client nel senso del server, solo due estremità.

La modalità resta utile per una coppia fissa di macchine con un processo documentato di rotazione delle chiavi, e OpenVPN 2.6 la segnala come obsoleta proprio perché la modalità TLS copre quei casi con proprietà migliori. Ciò che non può fare è distinguere un dispositivo che si connette da un altro, poiché il possesso del file è tutta la storia dell’autenticazione. Aggiungere un terzo dispositivo significa condividere la stessa chiave con esso, dopo di che i primi due non possono più distinguerlo da sé stessi.

Per questo il limite di due peer è strutturale e non un’impostazione da cambiare.

Perché client-to-client non è il pezzo mancante

client-to-client controlla se i client connessi possono scambiare traffico attraverso il server. Non ammette client, non assegna identità e non crea una modalità server che non è stata configurata, e in una configurazione a chiave statica non esiste un elenco di client che possa governare.

L’altra confusione comune riguarda il materiale tls-crypt o tls-auth. Un server TLS può condividere una di quelle chiavi tra tutti i client, perché protegge il canale di controllo invece di dimostrare chi è ciascun client. Una chiave condivisa del canale di controllo in modalità TLS è un oggetto diverso da una chiave dati statica condivisa, anche se entrambe arrivano come file che si somigliano.

La scelta tra le modalità si riduce a due domande. Più di un dispositivo deve connettersi in modo indipendente, e la distribuzione richiede la revoca per dispositivo? Un no a entrambe mantiene praticabile la modalità a chiave statica; un sì a una delle due punta al TLS. Non esiste una terza opzione in cui un secondo client venga ammesso senza la propria identità.

Costruire il server multi-client

Un server multi-client richiede la modalità TLS, un certificato lato server e un’identità per client. L’helper del server prepara il pool di indirizzi e la modalità multi-client, ma non fornisce la configurazione TLS, l’ancora di fiducia né i certificati client che rendono significativa l’ammissione.

Registra ogni dispositivo tramite l’autorità di certificazione esistente invece di copiare le credenziali di un client. Sono le identità distinte a rendere possibili revoca, routing per client e log utili, e un unico certificato client condiviso fa crollare tutte e tre le cose.

Se la distribuzione autentica gli utenti tramite una directory esterna o un secondo fattore, quella progettazione resta com’è. Il passaggio alla modalità server TLS decide come i peer si dimostrano a livello di tunnel e non impone il backend degli account. Mantieni le due decisioni separate, così che un cambiamento in una non alteri silenziosamente l’altra.

Poi decidi deliberatamente la politica di inoltro. client-to-client abilita il traffico tra client nel percorso server in spazio utente, cosa che molte distribuzioni vogliono e alcune non devono avere. È un interruttore di politica, non un meccanismo di identità, e va attivato perché la progettazione lo richiede, non perché un tutorial lo includeva.

Verificare che i client siano davvero indipendenti

Connetti due client e conferma che ricevono indirizzi diversi e appaiono con identità diverse nel registro del server. Poi revoca uno e conferma che l’altro continua a funzionare, che è la prova pratica che le identità non sono state condivise.

Prova il servizio consentito tra peer e uno che deve restare bloccato. Due accessi riusciti dimostrano l’ammissione, non l’isolamento, e la differenza conta quando la distribuzione deve separare gruppi di utenti.

Infine, leggi la modalità server dalla configurazione in esecuzione e non dalla memoria. Una configurazione a chiave statica con opzioni aggiuntive è ancora un collegamento punto a punto, e un server TLS corretto è l’unica disposizione in cui più client sono davvero peer separati.

Se il registro mostra un solo nome comune per ogni dispositivo, il problema non è la modalità. Il problema è il processo di registrazione.