Eliminare key-method da un profilo OpenVPN non cambia nulla
La direttiva è sparita dal parser, non dal protocollo. Separa l’opzione obsoleta dal formato di scambio delle chiavi prima di modificare un profilo.
Un profilo che funzionava da anni improvvisamente rifiuta di avviarsi, e il messaggio nomina una direttiva che nessuno ricorda di aver aggiunto: key-method. Il risultato di ricerca successivo suggerisce di aggiungere key-method 2 per compatibilità, un consiglio di un’altra epoca. Il parser che ha rifiutato la riga è attuale e non ha affatto quell’opzione. Rimuovere la riga corregge l’avvio e non cambia nulla nel modo in cui i due peer proteggono la sessione.
Proprio questo divario tra ciò che un profilo contiene e ciò che il protocollo fa davvero è l’intero argomento, e spiega diverse altre modifiche che le persone fanno contemporaneamente. Spiega anche perché quelle modifiche tendono ad arrivare in blocco.
Il sintomo è un errore di analisi, non un fallimento della stretta di mano
Le opzioni vengono lette prima che sia inviato qualsiasi pacchetto. Un profilo con una direttiva sconosciuta fallisce in quella fase, quindi il processo non raggiunge mai la rete e non produce mai un errore di stretta di mano. La formulazione di solito identifica l’opzione e il file, il che rende questo uno dei guasti più facili da attribuire. Nessun pacchetto, nessuna rotta e nessun firewall sono coinvolti.
openvpn --config /etc/openvpn/client/office.ovpn --verb 3 --log /tmp/parse.log
grep -n 'Options error' /tmp/parse.log
Se il messaggio nomina la direttiva, la diagnosi è conclusa: il file contiene qualcosa che questa build non accetta. Se il messaggio nomina invece un percorso di file, il problema è un include o una chiave mancante, che è un’altra sezione della stessa fase di avvio.
Ciò che non bisogna concludere è che il client o il server necessitino di una modalità di protocollo più vecchia. Un errore di analisi è un problema di vocabolario tra il tuo file e il binario, e il binario in questo caso ha semplicemente lasciato cadere una parola dal proprio vocabolario.
Direttiva e formato di trasmissione sono due cose diverse
La vecchia opzione key-method sceglieva come veniva incorniciato lo scambio di chiavi TLS, e lo scambio moderno è il metodo a più pacchetti che quell’opzione richiedeva un tempo. L’opzione è sparita perché non sceglieva più nulla; il formato che nominava è diventato l’unico. Rimuovere la riga lascia quindi la sessione con la stessa incorniciatura di prima. Una modifica testuale non può cambiarlo in nessuna direzione.
Per questo reintrodurre un vecchio binario per «ripristinare» il metodo 2 è la riparazione sbagliata. Non ripristina nulla se non un parser più vecchio con valori predefiniti più vecchi, e ti costa le correzioni arrivate dopo. Lo stesso ragionamento vale per l’indebolimento di un controllo del certificato o di una lista di cifrari nella speranza che la connessione torni.
Un controllo utile è la versione e la configurazione analizzata, non la presenza della parola nel file:
openvpn --version | head -n 1
grep -rn 'key-method' /etc/openvpn/ 2>/dev/null
Cosa rimuovere, e da quale file
Modifica il file che il processo in esecuzione legge davvero, e solo quel file. Sui sistemi pacchettizzati è di solito il profilo nella directory del client o del server indicata dall’unità, non una copia nella tua directory home che tieni come riferimento. Un profilo generato può anche essere ricostruito da un modello, quindi una modifica fatta solo sulla copia distribuita tornerà dopo la successiva esecuzione di provisioning.
Elimina la riga obsoleta e lascia in pace l’endpoint, i certificati, la politica dei cifrari e le impostazioni del canale di controllo. Sono opzioni supportate di cui il processo ha bisogno e non sono implicate nell’errore di analisi. Se lo stesso profilo contiene altre direttive che non riconosci, controlla ciascuna rispetto alla versione che esegui invece di eliminare un gruppo di esse finché il processo non si avvia.
Poi avvia l’istanza prevista e leggi il suo output di avvio. Un avvio pulito con il listener presente è la conferma che questa fase è conclusa; un test del client dopo risponde a un’altra domanda.
Un profilo rifiutato e un client rifiutato si somigliano
Due guasti producono thread di supporto simili e richiedono prove diverse. Un server che rifiuta la propria configurazione non si avvia mai, quindi nessun client può collegarsi. Un server che si avvia bene e rifiuta un client è in esecuzione, e il suo log contiene il motivo: un problema di certificato, un’opzione spinta che il client non accetta, una discrepanza di cifrario.
L’opzione rimossa non è una diagnosi per il secondo caso, e ricorrervi spreca la stessa ora due volte. Se il log del client mostra il rifiuto del server, leggi quel rifiuto; se mostra un errore locale, il file da esaminare è il profilo del client. Ricorrere a una direttiva che non esiste più ritarda entrambe le indagini della stessa misura.
Domande di compatibilità a cui la riga non ha mai risposto
I profili che circolano con questa direttiva di solito portano una storia su una piattaforma specifica, e la storia sopravvive alla ragione tecnica. Un client mobile o desktop ha ancora bisogno di un profilo completo supportato: una catena di certificati attendibile, un cifrario dei dati che entrambe le estremità accettano, una modalità del canale di controllo che entrambe le estremità implementano e nessuna direttiva che la build del client rifiuta. Niente di tutto ciò è deciso dalla presenza o dall’assenza della vecchia riga key-method.
La compressione è una questione di politica separata con la stessa forma. Rimuovere una riga key-method non dice nulla sul fatto che una direttiva di compressione sia supportata o accettabile nella tua distribuzione, e le due decisioni vanno prese in modo indipendente. Eliminare diverse impostazioni rilevanti per la sicurezza in una volta finché qualcosa si connette è il modo in cui un profilo funzionante diventa un profilo inspiegato.
Tieni un breve registro di ciò che hai rimosso e del perché: l’opzione, la versione che l’ha rifiutata e il comando che ha mostrato l’errore. La prossima persona che erediterà il profilo avrà bisogno esattamente di quei tre fatti, ed è meno costoso scriverli ora che ricostruirli dopo.