L’elenco VPN di GNOME può non offrire nulla che corrisponda al profilo che vi è stato consegnato, e la conclusione abituale è che il desktop non sappia fare OpenVPN. Invece sa. Quello che manca è un pacchetto plugin, e il client da riga di comando presente sulla stessa macchina non c’entra nulla con il menu. È il mito da sfatare per primo, perché manda le persone a reinstallare la cosa sbagliata.

Il menu elenca plugin, non protocolli

GNOME mostra i tipi di connessione che il gestore di rete riporta, e il gestore riporta i plugin installati. Un elenco vuoto descrive quindi l’insieme dei plugin installati, non le capacità del protocollo. Ecco perché un binario openvpn funzionante non cambia nulla nel pannello.

La distinzione conta perché i due guasti sembrano identici dal pannello. Un plugin mancante e un plugin rotto producono entrambi una finestra che non può aiutare, e solo il primo si risolve installando qualcosa. Chiedere al gestore ciò che sa li separa prima di installare qualsiasi cosa. La domanda costa un comando e sostituisce un’ora di tentativi.

Quale pacchetto possiede la finestra

Su Ubuntu 18.04 i pacchetti hanno nomi specifici, e le versioni più recenti hanno mantenuto la stessa suddivisione. Leggeteli come ruoli e non come alternative, perché installarne uno raramente risolve il problema da solo. Un pacchetto contiene il demone più il client da riga di comando, e nessuno dei due conosce alcuna finestra di impostazioni.

È il pacchetto plugin che consente al gestore di rete di creare, memorizzare e avviare una connessione OpenVPN. Il pacchetto editor fornisce il modulo, i suoi campi e il percorso di salvataggio che il pannello richiama. Una macchina con il plugin e senza editor mostra un tipo che non può configurare, mentre una macchina con l’editor e senza plugin non mostra nulla. Installate l’insieme insieme e l’ambiguità scompare.

sudo apt install openvpn network-manager-openvpn network-manager-openvpn-gnome
nmcli --version

Su 18.04 quelli sono i veri nomi d’archivio, non segnaposto. Un desktop KDE richiede il proprio pacchetto editor e richiede comunque il plugin, ed è la parte che una guida solo per GNOME omette.

Il riavvio fa parte dell’installazione

Il pannello chiede al gestore i tipi supportati all’avvio del servizio, e un elenco già visualizzato non viene aggiornato da un’installazione. Installare mentre il servizio è in esecuzione produce quindi la combinazione frustrante di un’installazione riuscita e una finestra invariata. Il riavvio non è una manutenzione facoltativa; è il passaggio che rende visibile l’installazione.

Il riavvio interrompe la connettività per alcuni secondi, e qualsiasi sessione SSH che passa sulla stessa interfaccia va con essa, quindi prevedetelo se la macchina è remota. Poi riaprite il pannello e chiedete direttamente al gestore cosa supporta. Un’interrogazione diretta è una prova migliore di un menu che potrebbe essere in cache.

sudo systemctl restart NetworkManager
nmcli -f NAME,TYPE connection show
nmcli connection add type vpn

L’ultimo comando è il test decisivo. Con il plugin, fallisce per argomenti mancanti; senza, segnala un tipo VPN sconosciuto. Un esito è un modulo in attesa di essere compilato, e l’altro è ancora un problema di pacchetti. Eseguitelo prima e dopo l’installazione se volete che il contrasto sia evidente.

Lasciate che nmcli legga il file .ovpn

Nulla vi obbliga a ricostruire un profilo fornito controllo per controllo. Il gestore legge direttamente i file .ovpn e trasforma le loro direttive in una connessione memorizzata, certificati inline compresi. L’importazione batte anche la trascrizione in accuratezza, perché un cifrario scritto male o una chiave troncata producono un guasto che sembra un problema del server.

Lasciate il profilo accanto a qualsiasi chiave o certificato a cui fa riferimento finché il salvataggio non è completo, perché una connessione che memorizza solo percorsi di file si rompe quando quei file si spostano. Poi provate la connessione per nome, e rispondete a qualsiasi richiesta di credenziali in primo piano così vedete cosa vuole. Una connessione salvata e mai attivata non è prova di nulla.

nmcli connection import type openvpn file ~/Downloads/office.ovpn
nmcli --ask connection up office
nmcli -f NAME,TYPE,STATE connection show --active

Quel terzo comando conferma che il tunnel è attivo con il nome che vi aspettate. Separa anche una connessione fallita da una che non è mai stata attivata.

Cosa il menu non può dirvi

Un tipo assente non dice nulla sul gateway, e non significa che il server rifiuti OpenVPN. Non è un motivo per installare un plugin di un protocollo non correlato affinché compaia una voce di menu. Quel secondo errore ha un nome nella pratica: le persone finiscono per puntare un profilo PPTP o AnyConnect a un servizio OpenVPN perché quelle erano le voci disponibili.

Riparate prima i pacchetti; la domanda sul server viene dopo. Un profilo che si importa pulito e non si autentica mai sta fallendo su una questione di certificato, TLS o credenziali, non di editor. Ognuna di queste lascia prove diverse, e nessuna compare nella finestra. Leggete il log del client prima di riaprire il pannello delle impostazioni.

Provatelo con una risorsa che usate davvero

Una volta che il tipo esiste e la connessione è salvata, avviatela e aprite una risorsa che usate davvero. L’attivazione da sola prova solo che le due estremità si sono accordate su un tunnel. Un tunnel che si alza e non trasporta nulla è il modo di guasto successivo, e il pannello non può vederlo.

Annotate quale risorsa avete provato, così la prossima persona ripete quel controllo invece di ricominciare. Quando il tunnel è attivo e la risorsa fallisce ancora, l’indagine passa a rotte e DNS invece di tornare alla finestra. Quella nota è la differenza tra una correzione e un racconto.

Articoli correlati