Confrontare due profili OpenVPN senza esporre le chiavi

Due profili, uno si connette e l'altro no, e il modo rapido per capire perché è un diff. Il guaio è che lo stesso diff stampa la chiave privata inline, la chiave statica e qualsiasi blocco di credenziali contenuto nel file, e le persone incollano l'output in una chat prima di accorgersene. Decidere che cosa state confrontando viene prima di eseguire il comando. Confrontate struttura e ruoli su copie protette, e costruite un file redatto separato quando qualcun altro deve vederlo.

Che cosa contiene davvero un file .ovpn

Un file .ovpn è una configurazione con blocchi inline facoltativi. Può contenere un certificato CA, un certificato client, una chiave privata, una chiave tls-auth o tls-crypt, e direttive che puntano a file esterni o chiedono credenziali. Due file possono sembrare quasi identici e differire solo dentro un blocco, o in una direttiva che cambia del tutto il trasporto. Il numero di righe non vi dice nulla su quale di queste cose sia accaduta.

Una differenza dentro un blocco di chiave non è prova pubblica di nulla. Un certificato riemesso e uno con chiave rigenerata possono produrre la stessa forma di cambiamento, quindi la discordanza del blocco dice che il materiale è diverso, non quale decisione l'ha prodotto. Trattatela come un segnale per confrontare i campi, non come un risultato.

Confrontate per ruolo, non per riga

Seguite l'ordine proprio della connessione: prima endpoint e trasporto, poi fiducia e identità attesa, poi autenticazione utente, poi rotte, DNS e hook di script. Questa sequenza corrisponde a ciò che fa il client, quindi la prima differenza che incontrate è la prima cosa che può aver rotto la connessione. Confrontare in ordine alfabetico, invece, disperde le impostazioni correlate in tutto l'output.

Una passata consapevole dei campi esamina questi elementi, in quest'ordine. Tutto ciò che il client chiede in modo interattivo appartiene alla riga di autenticazione, non alle righe di fiducia.

• remote, proto e porta, incluso ogni blocco di connessione.
• ca e cert: emittente, soggetto e data di scadenza.
• Se esiste una chiave privata, mai che cosa contiene.
• tls-auth o tls-crypt presenza e direzione della chiave.
• Direttive di autenticazione, inclusa qualsiasi riferimento a un file di credenziali.
• Rotte, opzioni DNS e hook di script eseguiti alla connessione.

Quando un file contiene più blocchi di connessione, tenete ogni opzione con il suo endpoint. Confrontare solo la prima riga remote può mancare l'alternativa che il client sceglie davvero su questa rete.

Perché un diff semplice è lo strumento sbagliato

Un diff semplice è fatto per il testo, non per i segreti. Stamperà volentieri una chiave privata nello scrollback, e non vi dirà che la direttiva che state fissando è irrilevante per il guasto. Le estrazioni di campi sono insieme più sicure e più leggibili, perché il materiale del certificato può essere confrontato come metadati invece che come byte.

openssl x509 -in ca.crt -noout -subject -issuer -enddate
openssl x509 -in client.crt -noout -subject -issuer -enddate
grep -E '^(remote|proto|port|tls-auth|tls-crypt|route|dhcp-option)' profile.ovpn

I primi due comandi stampano identità e validità senza toccare la chiave, quindi il loro output è sicuro da incollare. Il grep stampa nomi e valori delle direttive ma mai i corpi dei blocchi, il che lo rende la prima passata giusta quando sospettate una differenza di trasporto o di routing. Se occorre confrontare un blocco, confrontatene l'hash invece del contenuto.

Costruite una copia redatta per il ticket

Rimuovete i segreti reali e gli identificatori inutili mantenendo i nomi dei campi e abbastanza struttura da spiegare la differenza. Un marcatore della stessa forma rivela comunque dove si trova il materiale e quanto era lungo, quindi decidete se anche questo è accettabile. Controllate l'allegato finale stesso invece di fidarvi del comando che ricordate di aver eseguito. Non modificate l'originale di lavoro solo per produrre un esempio, perché un profilo redatto non è necessariamente eseguibile e non va mai reimportato.

Mantenete gli originali riconoscibili per nome file e hash invece di copiarli in tre directory con nomi simili. Una stringa di hash basta a provare quale file è stato esaminato e non costa nulla se trapela. Potate le copie quando la modifica è chiusa, così la persona successiva eredita un unico file autorevole.

Tenete il confronto legato a un guasto

Un confronto vale il suo costo quando risponde a una domanda su un'importazione o su un guasto di connessione. Nominate prima il passo che fallisce, poi confrontate solo i campi da cui quel passo dipende; raccogliere tutte le credenziali del client in un'unica directory rende più probabile la prossima fuga e più lenta la prossima diagnosi. Più stretta è la domanda, più corta è la lista dei campi che possono rispondervi.

Se un nuovo file è arrivato dall'operatore, confermatene il percorso di distribuzione prima di sostituire materiale di fiducia. Dopo la modifica, ispezionate la copia importata che il client ha davvero scelto e il risultato negoziato, perché un'altra versione del client può ignorare una direttiva o leggerla diversamente. Il file su disco non è prova della connessione che è stata eseguita. La semantica delle direttive è nel manuale di OpenVPN 2.6.