Come assemblare un profilo client OpenVPN dai file rilasciati

Il tuo operatore consegna un bundle CA, un certificato client e la sua chiave, e il client non si avvia finché non sono collegati in un unico profilo. Il profilo è configurazione: punta a quei file, non li contiene, e modificarlo non può trasformarlo in un certificato. La guida parte da un portatile già approvato e termina con un profilo che puoi avviare da una directory nota. Non crea una CA, non registra un nuovo certificato e non tocca il server.

L'obiettivo qui è un client da riga di comando OpenVPN 2.6 per Linux, instradato con TUN su UDP, con autenticazione tramite certificato.

Raccogli solo i file lato client

Lavora in una directory protetta e raccogli il materiale di fiducia della CA approvato, il certificato client rilasciato e la chiave privata che gli corrisponde. In questo esempio i nomi sono ca.crt, laptop-a.crt e laptop-a.key. I nomi dei file sono solo etichette; non dicono nulla su ciò che contiene ciascun file.

Se hai generato la chiave durante l'iscrizione, non ha mai lasciato la macchina; dall'emittente devono tornare solo il certificato firmato e la catena pubblica. Verifica che il certificato porti il ruolo client atteso dal servizio. Verifica anche che la chiave appartenga a quel certificato e non a uno precedente di un tentativo precedente. Una coppia che non corrisponde produce un errore TLS molto più tardi, che sembra un problema del server.

Lascia la chiave di firma privata della CA, la chiave privata del server e i parametri DH fuori da questo pacchetto.

Collega i file in un profilo piccolo

Il profilo qui sotto è volutamente breve. Ogni riga seleziona l'endpoint, vincola l'identità che il client accetterà, oppure punta a uno dei tre file.

client
dev tun
proto udp
remote vpn.example.net 1194
nobind

remote-cert-tls server
verify-x509-name vpn-gateway name
ca ca.crt
cert laptop-a.crt
key laptop-a.key

La riga remote seleziona l'endpoint di rete. remote-cert-tls server pretende che la controparte presenti un certificato con ruolo server. verify-x509-name fissa il nome atteso, qui vpn-gateway come Common Name del certificato del server con il campo nome predefinito di OpenVPN. Quel valore non è dedotto dal nome host DNS, quindi usa lo schema di identità fornito dall'operatore.

Non abbandonare quei controlli solo perché un endpoint di test mostra un certificato diverso.

Questo profilo di base presuppone nessuna sfida account separata e nessuna chiave del canale di controllo. Se il servizio richiede auth-user-pass, tls-auth o tls-crypt, conserva la configurazione e il materiale che ti sono stati dati, perché un segreto del canale di controllo generato da te non corrisponderà a quello del server. Conserva anche la politica di cifratura del servizio invece di importare righe di compressione o cifratura da un vecchio esempio.

Rendi esplicita la directory di lavoro

I percorsi relativi seguono la directory di lavoro del processo, non la posizione del file .ovpn.

Ciò sorprende chi sposta il profilo in una nuova cartella e si aspetta che la chiave lo segua. Per una directory scelta dall'amministratore, il comando sotto passa a un percorso assoluto prima di leggere il profilo e i suoi riferimenti.

sudo openvpn --cd /etc/openvpn/client/laptop-a --config laptop-a.ovpn

Una procedura guidata di importazione desktop o un servizio di sistema possono impacchettare le dipendenze per te e applicare regole proprie. Possono anche usare una directory di lavoro diversa da quella in cui hai fatto le prove. Verifica come il tuo metodo di avvio risolve i percorsi di chiave, certificato e CA. Spostare solo il file .ovpn non sposta la chiave privata separata.

Mantieni la chiave leggibile solo per l'utente o l'identità di servizio previsti.

Verifica la consegna, non i nomi dei file

Prima della prima connessione autorizzata, controlla l'endpoint, l'identità del certificato, l'emittente e la finestra di validità. Poi conferma che i riferimenti ai file si risolvano dalla directory di lavoro che userai davvero. Dopo la connessione, prova il comportamento dell'applicazione e del DNS che la politica di routing dovrebbe fornire. Tre file leggibili non dimostrano nulla sull'autorizzazione del server né su un percorso di risorsa utilizzabile.

Se compare una richiesta di passphrase, appartiene alla chiave privata, non a un account VPN.

Infine, inventaria il pacchetto come materiale di credenziali. Consegnare lo stesso certificato e la stessa chiave a un secondo portatile copia l'identità, e rinominare il file non ti dà una seconda iscrizione. È questa la differenza tra assemblare un profilo ed emetterlo.