Due nomi sono in gioco prima ancora che il client si connetta: il nome del file sul portatile (nuc.ovpn) e l’identità che il server ricava dalla credenziale. Una ricerca in client-config-dir usa la seconda. Rinominare il profilo sul client, o aggiungere .conf al file sul server, non cambia nulla su quale file il server apra.

Il confronto utile non è «quale nome ho usato» ma «quale regola applica il server», perché l’autenticazione con certificato e quella con nome utente/password possono produrre nomi effettivi diversi a partire dallo stesso accesso.

Nome del profilo contro nome comune del certificato

Nella configurazione predefinita basata su certificato il server prende il nome comune X.509 e cerca un file con esattamente quel nome dentro client-config-dir. Un profilo chiamato nuc.ovpn il cui certificato dice tester si risolve in /etc/openvpn/server/ccd/tester. Il nome del file del client non entra mai nel calcolo. È il primo punto in cui si nasconde una discrepanza.

Una directory piena di profili dai nomi accurati può quindi sbagliare ogni volta. Il file non viene abbinato per subject, per indirizzo e-mail né per il nome mostrato in una GUI; viene abbinato per la stringa del nome comune.

Su un filesystem sensibile alle maiuscole, Tester e tester sono due file diversi e solo uno viene mai aperto. Controllate il nome comune del certificato che il client presenta davvero, non quello di una copia nei vostri appunti.

username-as-common-name capovolge la regola

Quando il server esegue l’autenticazione con nome utente/password insieme a username-as-common-name, il nome utente autenticato sostituisce il nome comune del certificato per questa ricerca.

Confrontate i due casi direttamente: con identità da certificato il file segue il certificato e un cambio di password è irrilevante; con identità da nome utente il file segue il nome di accesso e una riemissione del certificato è irrilevante. Il campo che il server sostituisce è quello su cui allineare il nome. Un certificato riemesso con un nuovo CN cambia silenziosamente il bersaglio della ricerca, e il vecchio file CCD resta sul disco sembrando corretto.

Esistono configurazioni miste, ed è lì che nasce la maggior parte della confusione. Se un blocco di servizio attiva la sostituzione e un altro no, il nome effettivo dipende da quale istanza ha gestito la connessione. Confermate la configurazione attiva invece di dare per scontato che valga il file globale. La referenza delle opzioni del server a monte documenta la ricerca per file nominato e il ripiego facoltativo.

Che cosa legge il server e che cosa ignora in silenzio

Due piccole differenze decidono se un file viene selezionato. La prima è un’estensione aggiunta. La seconda è un carattere vagante nel nome.

OpenVPN non aggiunge .conf al nome che cerca, quindi tester.conf non corrisponde a tester. Un editor che nasconde le estensioni può lasciare un file che sembra corretto in un elenco e non corrisponde mai.

Quando non esiste un file corrispondente, il server può ripiegare su un file chiamato DEFAULT. L’arrivo di alcune impostazioni non è quindi prova che sia stato usato il file per singolo client. Confrontate l’indirizzo assegnato o le rotte spinte con ciò che produrrebbe il file per singolo client. I permessi sono il terzo filtro, perché il server apre il file dopo aver rinunciato ai privilegi; una shell root che riesca a leggerlo non dimostra nulla.

Un nome file corretto non convalida il contenuto

Selezione e contenuto sono guasti separati. Una volta aperto il file giusto, le sue direttive devono comunque essere valide per quel client.

ifconfig-push deve assegnare un indirizzo che la topologia possa davvero usare, e iroute ha senso solo per una sottorete instradata dietro quel client.

Una identità, più dispositivi

Due portatili che presentano lo stesso nome comune selezionano lo stesso file e ricevono le stesse impostazioni specifiche del client. Se servono indirizzi separati o una revoca separata, servono identità separate, non due copie di un file.

Il confronto è tra condividere un’identità ed emettere un certificato per dispositivo. La condivisione è più semplice da amministrare e più grossolana da revocare, mentre i certificati per dispositivo costano più configurazione e danno un’unità pulita da disattivare.

Articoli correlati