duplicate-cn dà a due dispositivi una sola identità, non due

Copiate il profilo sul tablet, collegatevi e il portatile cade. Aggiungete duplicate-cn, entrambi restano connessi e il problema sembra risolto finché i due dispositivi non si contendono lo stesso indirizzo del tunnel o un tablet perduto manda l'intero account offline. L'opzione cambia una cosa e una sola: se il server consente una seconda sessione sotto un nome che ha già visto. Tutto ciò che le persone si aspettano che sistemi, dall'indipendenza dei dispositivi all'indirizzamento per dispositivo fino alla revoca selettiva, passa ancora per l'identità, e l'identità qui è il certificato.

Il mito: una seconda sessione è una seconda identità

L'intuizione dice che due connessioni devono essere due client, e due client dovrebbero essere due dispositivi con diritti propri. Il server non lo modella così. Vede un nome comune e, con duplicate-cn attivo, accetta più di una sessione viva che porta quel nome, ciascuna con il proprio stato di sessione nel demone.

Niente di quell'accettazione tocca la verifica del certificato. Lo stesso certificato resta la credenziale, la stessa chiave resta la chiave privata, e ogni politica basata sul soggetto del certificato si risolve ancora due volte allo stesso valore. Una seconda sessione è un secondo socket, non una seconda identità.

Questa distinzione è invisibile finché tutto funziona. Diventa molto visibile nel momento in cui dovete distinguere i due dispositivi, che di solito è il giorno in cui uno dei due va perduto.

Che cosa cambia davvero quando due sessioni condividono un nome

Senza l'opzione, una nuova connessione sotto un nome comune già connesso sposta la sessione precedente. È per questo che il portatile cade quando si connette il tablet, ed è una salvaguardia deliberata contro l'ambiguità, non un bug. Con l'opzione, entrambe le sessioni restano vive e il server le segue separatamente per sessione, non per dispositivo.

Ogni sessione mantiene la propria connessione esterna e le proprie chiavi negoziate, quindi la velocità simultanea è davvero simultanea. Ciò che condividono è tutto ciò che deriva dalla credenziale: ricerche di policy, configurazione specifica del client, identità nei log e revoca. Lo stato di sessione appartiene alla connessione e muore con essa, mentre i fatti a livello di credenziale persistono per entrambe. Per questo l'output di stato può elencare due volte lo stesso nome mentre i contatori restano separati.

Verificate che cosa fa davvero la vostra build prima di progettare su di essa, perché l'effetto dell'opzione lo definisce l'opzione stessa e non la tradizione orale:

grep -n 'duplicate-cn\|client-config-dir\|username-as-common-name' /etc/openvpn/server.conf

L'indirizzo statico che pensavate di aver assegnato

La configurazione per client viene cercata per nome, ed è qui la trappola. Un file client-config-dir intitolato al nome comune si applica a ogni dispositivo che usa quel nome, quindi un ifconfig-push al suo interno assegna a entrambi i dispositivi lo stesso indirizzo del tunnel. La seconda sessione o non si stabilisce o va in collisione in un modo che sembra un guasto di routing.

Un pool dinamico si comporta meglio per caso, perché a ogni sessione viene assegnato un indirizzo dal pool in modo indipendente. Questo non vi dà comunque un indirizzo stabile per dispositivo, e certamente non vi dà una politica per dispositivo legata a quell'indirizzo.

Se il deployment usa username-as-common-name, la chiave di ricerca diventa il nome utente autenticato invece del soggetto del certificato, e la stessa collisione si ripete per chiunque acceda due volte. Il nome che guida la configurazione deve essere univoco per dispositivo perché la configurazione per dispositivo significhi qualcosa.

Che cosa un'identità condivisa non può fare al momento della rimozione

La revoca agisce sul certificato, non sul nome visualizzato e non sulla sessione. Revocate quel certificato e ogni dispositivo che ne detiene una copia perde l'accesso in un colpo, compreso quello in ufficio che nessuno vuole disturbare. Tenetelo e il dispositivo perduto continua a funzionare, perché nulla nel protocollo lo distingue dalla copia approvata.

I log ereditano la stessa ambiguità. L'output di stato mostra un nome comune e un indirizzo reale, ed entrambi possono appartenere a uno o all'altro dispositivo. Una revisione di incidente che deve sapere quale macchina abbia fatto cosa non può rispondere con i registri della VPN stessa, per quanti dettagli offra il livello di log.

Non esiste una scorciatoia crittografica. Due dispositivi che presentano lo stesso certificato sono, per il server, lo stesso partecipante due volte, e qualunque schema pretenda il contrario è una convenzione di denominazione e non un controllo.

Quando la condivisione è giusta, e come limitarla

La condivisione ha usi legittimi: un account di laboratorio usato da più macchine di test, o una famiglia in cui i dispositivi sono gestiti insieme e la granularità della revoca non conta. In quei casi attivate l'opzione deliberatamente, tenete la credenziale condivisa fuori dalla politica per dispositivo e lasciate spazio al pool perché le sessioni non possano scontrarsi su un indirizzo.

Per tutto ciò che richiede indirizzi separati, log separati o una rimozione separata, emettete certificati separati tramite il normale percorso di registrazione. Questo dà a ogni sistema a valle un oggetto distinto su cui basarsi, e l'opzione smette di contare perché i nomi sono già unici.

Qualunque percorso scegliate, provate il modello di gestione e non l'accesso. Collegate entrambi i dispositivi, confermate che hanno indirizzi diversi, poi simulate una perdita e verificate di poter rimuovere esattamente uno dei due. Il manuale di openvpn(8) definisce l'ambito dell'opzione; la vostra procedura di rimozione definisce se la condivisione sia davvero accettabile.