OpenVPN : avviare un file .ovpn su Linux e comprendere un fallimento

Hai ricevuto un file .ovpn, avvii OpenVPN su una VM Debian o Ubuntu, poi il terminale visualizza un errore o rimane bloccato prima della connessione. Il file può essere valido mentre punta a un certificato assente, una porta filtrata o un percorso che interrompe la tua sessione SSH. Controlla il profilo, prendi nota del primo errore, poi verifica il percorso e il servizio interno dopo la connessione.

Leggi il file .ovpn prima di avviare OpenVPN

Conserva una console locale, una console del fornitore, iDRAC/IPMI o una rete di gestione distinta già validata. Avvia il test da questo accesso indipendente. redirect-gateway può essere scritto nel file o inviato dal server dopo la connessione. Il percorso predefinito può quindi passare attraverso il tunnel. Una seconda sessione SSH che utilizza lo stesso percorso non è un accesso di emergenza.

Se sei collegato in SSH prima del test, visualizza e annota l’indirizzo cliente. Dalla console di controllo utilizzata dopo la connessione, reinserisci questo indirizzo prima di verificare il suo percorso. Una console di recupero consente di tornare sul server, non garantisce che la tua sessione SSH rimanga aperta.

# Nella sessione SSH prima dell'avvio:
printf '%sn' "$SSH_CLIENT"
# Nella console di controllo dopo la connessione:
SSH_CLIENT_IP='198.51.100.42' # sostituisci con l'indirizzo cliente annotato
ip route get "$SSH_CLIENT_IP"

Posiziona il file in una directory riservata al tuo account e limita i suoi diritti se sono integrate delle chiavi. Non inserire né identificativo, né password nel file di dimostrazione o in un deposito Git.

mkdir -p ~/vpn-test
install -m 600 /percorso/ricevuto/client.ovpn ~/vpn-test/client.ovpn
cd ~/vpn-test
grep -nE '^[[:space:]]*(remote|proto|port|ca|cert|key|pkcs12|tls-auth|tls-crypt|tls-verify|auth-user-pass|auth-user-pass-verify|redirect-gateway|redirect-private|route|route-ipv6|route-gateway|route-table|route-noexec|route-nopull|pull-filter|config|plugin|script-security|up|down|route-up|route-pre-down|ipchange|dns-updown|management|daemon|log|log-append|syslog|status|writepid|askpass|cd|chroot|user|group|learn-address|client-connect|client-disconnect)' client.ovpn

Questa lettura mostra l’host remoto, il protocollo, i file di certificati e il metodo di autenticazione senza mostrare il loro contenuto. Se config carica un altro file, rileggilo dalla directory del profilo, ripeti questo filtro e segui ogni config fino all’ultimo file. L’intera catena deve essere compresa prima dell’avvio. up, down, route-up, route-pre-down, ipchange e tls-verify avviano comandi esterni. plugin carica una libreria nel processo OpenVPN. management apre un’interfaccia di controllo che non deve essere esposta. Un profilo cliente che contiene learn-address, client-connect, client-disconnect o auth-user-pass-verify viene rifiutato per questa diagnosi. Fermati anche se uno degli altri percorsi è sconosciuto. Gli script esterni richiedono un valore script-security di 2 o 3, valore che il profilo può impostare esso stesso. Controlla anche auth-user-pass: senza argomento, OpenVPN richiederà le credenziali al prompt; con un percorso, leggerà questo file e trasmetterà il suo contenuto al server del profilo. L’avvio con sudo rimane normale per creare l’interfaccia e i percorsi, ma nessun file referenziato deve essere sconosciuto.

# Per ogni percorso trovato dopo "config", da ~/vpn-test:
sed -n '1,220p' percorso-incluso.conf

Un file di cui la provenienza o le direttive rimangono sconosciute non deve mai essere avviato su un server di produzione né su una macchina di cui l’accesso SSH è rilevante. Il primo tentativo deve essere fatto in una VM usa e getta con console indipendente. Questa lettura riduce il rischio, non trasforma un profilo arbitrario in un profilo sicuro. Rifiuta anche daemon, log, log-append e syslog per questa diagnosi: spostano i messaggi fuori dal terminale e possono lasciare il processo in background.

Se il profilo fa riferimento a percorsi relativi, non spostare solo client.ovpn. Conserva la directory ricevuta in una posizione controllata o copia ogni dipendenza riletta con la stessa struttura ad albero e diritti restrittivi. Ad esempio, un profilo che cita ca ca.crt deve ritrovare ca.crt in ~/vpn-test.

install -m 600 /percorso/ricevuto/ca.crt ~/vpn-test/ca.crt

Una dipendenza assente o illeggibile è un fallimento del profilo, distinto da un errore TLS dopo il tentativo di rete. Un file .ovpn può anche includere i certificati tra tag, questo controllo non visualizzerà quindi alcun percorso esterno.

find ~/vpn-test -maxdepth 1 -type f -printf '%f %mn'
# Per proto udp4/tcp4:
getent ahostsv4 vpn.esempio.net
# Per proto udp6/tcp6:
getent ahostsv6 vpn.esempio.net
ip -brief link show > ~/vpn-test/links-before.txt

Sostituisci l’host e la famiglia con i valori di remote e proto. Un profilo può contenere più righe remote. Se la famiglia rimane aperta, controlla entrambe le uscite e poi conserva l’indirizzo realmente annunciato da OpenVPN nel log. La connessione OpenVPN stessa rimane il test utile del protocollo e della porta, sia essa UDP o TCP.

Avviare il client in primo piano e mantenere il log

Avvia il client in primo piano. Il terminale deve quindi mostrare l’indirizzo contattato e il primo errore sfruttabile. Installa il pacchetto se openvpn è assente:

command -v openvpn || { sudo apt update && sudo apt install openvpn; }
sudo openvpn --config ~/vpn-test/client.ovpn --verb 3

Con --verb 3, tieni la prima errore esplicito, l’indirizzo del server e la fase in cui il client si ferma.

• Options error o un file inesistente indicano un percorso, una direttiva o un certificato da correggere prima di un nuovo tentativo.
• TLS Error dopo il tentativo di connessione richiede un controllo del server, della porta, del protocollo UDP/TCP, del filtro di rete, di tls-auth o tls-crypt, dei certificati, dell’ora di sistema e dei parametri crittografici del profilo.
• Una richiesta di identificativo può provenire da auth-user-pass. Inseriscilo al prompt o utilizza il meccanismo previsto dal tuo fornitore, senza aggiungere il segreto a client.ovpn.
• Il messaggio Initialization Sequence Completed conferma che il client ha completato la sua inizializzazione. Non prova ancora che la risorsa interna attesa sia raggiungibile.

Tieni il comando aperto durante il controllo successivo. Ferma con Ctrl+C solo dopo aver verificato l’interfaccia, i percorsi e il servizio interno.

Verificare l’interfaccia e il percorso dopo la connessione

Registra le interfacce prima della connessione, poi confrontale dopo. tun trasporta pacchetti IP, tap emula un’interfaccia Ethernet. La direttiva dev può anche imporre un nome. Usa solo il nome effettivamente creato. ip route get mostra il dispositivo che Linux sceglierebbe, senza inviare pacchetti.

# Dopo "Initialization Sequence Completed":
ip -brief link show | diff -u ~/vpn-test/links-before.txt -
VPN_IF='nome-dell-interfaccia-creata'
ip -brief address show dev "$VPN_IF"
ip route get 10.8.0.10
ip route get 1.1.1.1
ip route get "$SSH_CLIENT_IP"

Sostituisci 10.8.0.10 con un obiettivo interno documentato dal team che fornisce il VPN. Il suo percorso deve menzionare l’interfaccia del tunnel se questa rete passa attraverso OpenVPN. Rileggi anche il percorso verso SSH_CLIENT_IP se avevi una sessione remota prima del test.

Il percorso non prova che il servizio interno risponde. Testa quindi il servizio atteso con l’indirizzo e la porta documentati dal tuo team. Per un servizio HTTPS che espone una pagina di salute, ad esempio:

getent hosts intranet.esempio.lan
curl --fail --silent --show-error --connect-timeout 5 --max-time 10 --output /dev/null --write-out '%{http_code}n' https://intranet.esempio.lan:443/health

Sostituisci questo nome, la porta e il percorso con quelli del servizio reale. Il primo comando deve restituire un indirizzo interno. Il secondo deve visualizzare il codice atteso da questo servizio, ad esempio 200 o 204. curl verifica anche il certificato TLS: installa la CA interna o utilizza la documentazione del servizio se necessaria, senza aggiungere --insecure. Per un DNS interno, interroga piuttosto un nome e un risolutore documentati dal tuo team.

Scelgo questo avvio puntuale prima di un servizio openvpn-client@... su un server, poiché la diagnosi rimane separata dall’avvio. Dopo Ctrl+C, verifica che l’interfaccia sia scomparsa, che il percorso verso l’obiettivo interno non utilizzi più il tunnel e che il percorso verso l’indirizzo SSH annotato torni al dispositivo atteso. Un profilo con script down o route-pre-down impone questo controllo, non consente di presumere che la pulizia sia riuscita.

ip link show "$VPN_IF"
ip route get 10.8.0.10
ip route get "$SSH_CLIENT_IP"

Il primo comando deve segnalare che l’interfaccia non esiste più. Confronta i due percorsi con le loro uscite annotate prima e durante il tunnel. Un percorso ancora legato all’interfaccia rimossa o uno script di pulizia in errore richiede una verifica prima di un nuovo tentativo.