Come verificare il server di un profilo OpenVPN prima di importarlo

Qualcuno ti invia un profilo, tu lo importi e trenta secondi dopo un client sta chiamando una destinazione che nessuno ha controllato. Leggi prima il file in un editor di testo, perché tutto ciò che conta sta in una manciata di direttive: remote, proto, port, ca, cert, tls-crypt e verify-x509-name. Tutto il resto sono valori predefiniti, ed è lì che vivono le sorprese.

Elenca ogni endpoint che il file può usare

Parti dagli endpoint, perché un profilo può contenerne diversi. grep -nE '^[[:space:]]*(remote|proto|port|remote-random|connection)' profile.ovpn stampa ogni candidato nell'ordine del file, compresi quelli annidati nei blocchi <connection> inline.

Quando una direttiva omette la porta, il client ricade sul valore predefinito dell'ascoltatore, quindi solo remote vpn.example.com significa porta 1194 con qualsiasi proto compaia più avanti nel file. Più righe remote semplici sono alternative: il client le prova in ordine a meno che remote-random non le mescoli, e non sostituisce mai in silenzio l'host di un altro operatore. Due righe remote su domini non correlati è il punto in cui ti fermi e chiedi quale fosse quella intesa.

Nota anche la grafia di proto. tcp è accettato come sinonimo di tcp-client lato client, ma tcp-server in un profilo client è un errore di configurazione che tende a bloccarsi invece di fallire in modo pulito.

Conferma il nome, poi la porta

dig +short vpn.example.com ti dice se il nome esiste e quali indirizzi restituisce, e un endpoint multi-homed o dietro un proxy può restituirne legittimamente diversi. La risoluzione è un prerequisito, non una prova di proprietà; chiunque può puntare un nome a un indirizzo, e un indirizzo può rispondere per molti nomi.

Poi controlla l'ascoltatore sulla porta che hai trovato, in base al trasporto. Su TCP, openssl s_client -connect vpn.example.com:1194 -servername vpn.example.com stampa la catena che il server presenta. Su UDP serve DTLS: openssl s_client -dtls1_2 -connect vpn.example.com:1194 esegue la stessa stretta di mano sui datagrammi. Una stretta di mano completata dimostra che qualcosa ascolta e detiene un certificato, il che è più di quanto mostri un ping e meno di quanto esigano le stesse impostazioni di fiducia del profilo.

Quando la stretta di mano fallisce e l'host risponde al ping, la porta è probabilmente sbagliata o filtrata. Prendilo come motivo per chiedere la porta corretta, non come invito a setacciare quelle vicine. Anche nc -vzu riporta successo su alcuni stack senza che nulla ascolti, quindi una sonda UDP nuda non significa nulla senza una stretta di mano dietro.

Leggi i pin di fiducia separatamente dall'indirizzo

L'indirizzo decide dove va il client; il blocco di fiducia decide di chi si fida una volta arrivato. verify-x509-name "vpn.example.com" name fissa il nome comune del soggetto, e remote-cert-tls server richiede l'uso esteso della chiave per l'autenticazione del server. Un profilo consegnato da un operatore dovrebbe portare entrambi.

Cerca ca, un blocco <ca> inline e tls-crypt oppure tls-auth. Un profilo che usa tls-auth necessita di key-direction 1 sul client quando il lato server usa la direzione 0, e una mancata corrispondenza fa fallire la stretta di mano con un errore TLS che si legge come un difetto del certificato. Una CA inline che non appartiene all'operatore di cui hai appena risolto il nome significa che il file è stato assemblato da due fonti, e questo è il caso che vale la pena rifiutare di netto.

verify-x509-name accetta le modalità name, name-prefix o subject, e l'ultima si aspetta un nome distinto completo nell'esatto ordine in cui il server lo stampa. Scegli una modalità che si adatti alla forma del valore, perché il client rifiuta ogni connessione invece di avvisare di un quasi errore. Per un file che non hai scritto tu, name con un semplice nome host è la scelta meno sorprendente.

Controlla le opzioni che falliscono in silenzio

OpenVPN 2.6 negozia i cifrari tramite data-ciphers, e un profilo che porta solo una vecchia riga cipher AES-256-CBC può completare il canale di controllo e poi bloccarsi sui dati. Leggere quel valore ti dice se il file precede il server a cui ti unisci; la pagina di manuale della 2.6 elenca l'ordine di negoziazione se devi citarla all'operatore.

auth-user-pass senza nome file significa che il client chiederà, quindi un profilo che sembra autosufficiente ha comunque bisogno di credenziali. auth-user-pass credentials.txt significa che si aspetta un file che probabilmente non ti è stato inviato. nobind e resolv-retry infinite sono ordinari e innocui, mentre explicit-exit-notify è solo per UDP e inutile su TCP.

Nessuna di queste cambia dove si connette il profilo, ma ciascuna cambia se si connette del tutto, e nessuna è visibile nella finestra di importazione del client.

Decidi, poi annota ciò che hai deciso

Dopo questa lettura ci sono tre esiti e solo uno è l'importazione. Quando l'endpoint e i pin corrispondono alle istruzioni ricevute per un canale separato, importalo. Quando l'endpoint sembra corretto ma i pin o la CA non corrispondono, chiedi un file corretto. Quando il file mescola endpoint o materiale CA di fonti diverse, cancellalo e chiedi una copia nuova.

Annota l'hash che hai esaminato, così la persona successiva può capire se il file è cambiato: sha256sum profile.ovpn, incollato accanto all'endpoint nelle tue note. Un profilo è un assetto completo, non un elenco di indirizzi, quindi non innestare mai un remote funzionante nel blocco di fiducia di qualcun altro conservandone le credenziali.

Tieni le chiavi private e le password fuori da schermate e thread di chat mentre confronti gli appunti. L'endpoint e le opzioni non segrete bastano per porre una domanda precisa, e il resto appartiene al file.

Se lo importi comunque e il primo tentativo fallisce, avvia il client con --verb 3 e leggi le prime dieci righe: l'indirizzo remote risolto, il proto negoziato e l'errore TLS compaiono in quest'ordine, il che ti dice quale dei controlli sopra hai saltato.