Tunnelblick data-ciphers non riconosciuto: quale motore era in esecuzione?

Tunnelblick segnala un’opzione data-ciphers non riconosciuta, cita OpenVPN 2.4 nello stesso respiro e la connessione non parte mai. Si tratta di un fallimento locale di analisi e non di un disaccordo di cifratura, perché il motore ha rifiutato il profilo prima che avvenisse qualsiasi negoziazione con il gateway. Il solito consiglio sulla politica di cifratura del server non può aiutare qui; l’analizzatore deve prima capire il file. Individua il motore che questa configurazione ha realmente avviato, e il resto segue.

Leggi la riga di log prima di toccare il profilo

Apri la connessione fallita nella finestra dei dettagli di Tunnelblick e leggi il log dall’inizio. Le prime righe indicano la versione del motore e il profilo che gli viene consegnato, seguite dall’opzione che ha fermato l’analisi. Tutto ciò che segue è rumore, perché il processo è terminato.

Annota tre fatti da quel log: la versione del motore, il nome della configurazione e il messaggio esatto. Quei tre sono tutta la diagnosi. Sono anche ciò che ti servirà se la correzione richiederà di modificare l’applicazione installata. Fai uno screenshot delle righe invece di parafrasarle, perché i nomi delle opzioni si digitano facilmente male quando li si ripete a memoria.

Conferma quale motore esegue quella configurazione

Tunnelblick è un’applicazione costruita attorno a un motore OpenVPN, e configurazioni diverse possono eseguire motori diversi. Controlla la versione selezionata per questa configurazione nella finestra dei dettagli invece di leggere la versione dell’applicazione, e non sostituirla con l’output di un binario openvpn da terminale che la configurazione non usa mai. La guida alle versioni di OpenVPN di Tunnelblick descrive come funziona questa selezione e dove viene memorizzata.

La distinzione conta perché una macchina può avere un binario moderno nel PATH e un motore 2.4 incluso dietro la connessione che ha fallito. Il profilo è valutato dal secondo.

openvpn --version
ls /Applications/Tunnelblick.app/Contents/Resources/openvpn/

Questi due comandi mostrano cosa eseguirebbe un terminale e quali directory dei motori porta con sé l’applicazione installata. Nessuno dei due dimostra cosa ha usato la configurazione fallita, dato che il log te l’ha già detto, e i percorsi differiscono tra le versioni di Tunnelblick.

Perché il nome della direttiva è cambiato

OpenVPN ha introdotto data-ciphers come elenco di negoziazione nella 2.5, sostituendo la grafia precedente ncp-ciphers diventata obsoleta in quella versione. Un motore 2.4 non ha questa opzione, quindi si ferma al primo token che non conosce. Nemmeno l’opzione singola cipher è un vecchio alias dell’elenco; nomina un solo cifrario invece di un insieme di negoziazione.

Per questo la sostituzione di testo tra versioni produce profili che vengono analizzati e poi si comportano in modo imprevisto, e per questo copiare un frammento da un post di un forum non è un controllo di versione. I nomi delle opzioni si sono spostati insieme alla gestione dei fallback e ai valori predefiniti, e un file composto rinominando una sola direttiva non equivale a uno scritto per il motore.

Correggi il motore o il profilo, non il sintomo

Per una distribuzione supportata, la riparazione duratura è una combinazione supportata di Tunnelblick e motore che accetta il profilo dell’operatore, organizzata tramite chi possiede l’installazione dell’applicazione. Se un’installazione più vecchia deve restare per un po', chiedi un profilo scritto per quel motore e per i cifrari che il gateway accetta davvero.

Eliminare data-ciphers e data-ciphers-fallback effettivamente cancella questo specifico errore di analisi, ed è esattamente per questo che è tentante. Cambia anche quali cifrari vengono negoziati, in silenzio, in una configurazione di sicurezza che non intendevi modificare. Conserva il profilo originale e confronta invece deliberatamente le impostazioni supportate.

Riprova e leggi la fase successiva

Dopo la correzione, riprova la connessione e leggi il nuovo log dall’inizio invece di dare per scontato il successo. Un profilo che ora viene analizzato può comunque fermarsi alla negoziazione del cifrario, alla verifica del certificato, all’autenticazione o all’instradamento, e ciascuno di questi fallimenti ha le proprie prove.

Se la negoziazione fallisce, confronta i cifrari supportati dai due peer con quelli consentiti a ciascuno. Se l’autenticazione fallisce, il profilo e il motore ora funzionano abbastanza bene da aver raggiunto il gateway, il che è un progresso che vale la pena registrare. Fermare quella catena al primo log silenzioso è il modo in cui un’impostazione di sicurezza viene rimossa per il motivo sbagliato.