Portabilità del profilo OpenVPN: chiavi portabili o opzioni di piattaforma

Lo stesso file .ovpn apre un tunnel in un client e non parte in un altro, e il certificato è di solito il primo sospetto. Più spesso il file contiene una direttiva che solo un motore implementa. Un profilo è un contratto con un client preciso, non uno script portabile.

Separate ciò che viaggia con l’identità da ciò che appartiene a una piattaforma. Allora il guasto di solito si nomina da solo.

Un file, due contratti

Un profilo raggruppa tre tipi di contenuto: materiale d’identità come i certificati CA e client e la chiave privata, dati di trasporto come l’endpoint remoto e il protocollo, e direttive di comportamento come la gestione del DNS o le opzioni del dispositivo. I primi due sono ampiamente portabili tra motori che supportano lo stesso protocollo. Il terzo è dove le implementazioni divergono. Trattare l’intero file come un’unica unità portabile è ciò che produce i guasti confusi.

Un file che funziona in una GUI su una piattaforma non è automaticamente valido per il client a riga di comando su un’altra. Anche quando entrambi sono OpenVPN, i parser e gli insiemi di opzioni differiscono. Per questo un’importazione riuscita non è prova di un profilo portabile.

Materiale portabile contro direttive di piattaforma

Le sezioni d’identità e trasporto sono la parte da conservare. ca, cert, key e remote descrivono chi si connette e dove, e significano la stessa cosa per ogni client conforme.

Le direttive di comportamento sono la parte da confrontare. block-outside-dns, per esempio, esiste per cambiare il comportamento DNS su Windows. Un client Unix potrebbe non riconoscerla affatto.

Leggete l’elenco delle opzioni del client ricevente invece di quello del mittente. Il manuale di riferimento di OpenVPN 2.6 documenta le opzioni del motore, e la finestra di importazione di una GUI non è quell’elenco.

Leggete l’errore del parser prima del certificato

Un errore che nomina un’opzione non riconosciuta è un guasto del parser, non un guasto di autenticazione. La connessione non ha mai raggiunto TLS, quindi cambiare i certificati non può aiutare. Leggete il primo errore dal client e dalla versione reali, poi rimuovete o sostituite solo la direttiva che quel client non può implementare. Eliminare sezioni di certificato o di rotte per far caricare il file è il modo in cui un profilo funzionante diventa insicuro.

Se l’errore menziona l’handshake, un certificato o un cifrario, il profilo è stato analizzato e il problema è altrove.

Tenete il file originale accanto a quello adattato. Quando il file adattato fallisce più tardi, l’originale è il controllo che dice se si è mosso la modifica o l’ambiente.

I privilegi sono una seconda frontiera

I privilegi sono l’altra frontiera: creare un dispositivo tunnel, installare rotte e leggere una chiave privata dipendono tutti dai permessi locali. Un file di chiave leggibile solo da root è una distribuzione normale, non un difetto del profilo. La correzione appartiene alla proprietà o alle capacità, non al file.

Eseguire il client con sudo può risolvere un rifiuto di permesso locale, e non può aggiungere una direttiva che il binario non implementa. Cambia anche quale portachiavi, quali percorsi di configurazione e quale contesto del gestore di rete si applicano, quindi il risultato non è lo stesso test.

Adattate con criterio

Quando un fornitore pubblica profili separati, prendete quello destinato al client ricevente. Adattare il file di un’altra piattaforma è l’ultima risorsa. Richiede un registro di ogni opzione modificata e una copia dell’originale.

Provate identità, routing e DNS come tre esiti separati. Un profilo che si autentica e instrada ma rompe la risoluzione dei nomi è un profilo parzialmente adattato, non uno funzionante.