Le impostazioni non importano il .ovpn che la CLI accetta
Un profilo che si connette da un terminale può comunque fallire l'importazione desktop. Controllate il plugin, le direttive che scarta e ciò che è stato realmente salvato.
Lo stesso file si connette da una shell e rifiuta di essere importato nel pannello desktop. Questo esclude il server, le credenziali e la sintassi del profilo, perché il client da riga di comando li ha già analizzati tutti e tre. Resta il percorso desktop stesso: i pacchetti di cui ha bisogno, il sottoinsieme di direttive che comprende e l'oggetto che scrive su disco. Ognuno fallisce in modo diverso, e i messaggi raramente indicano quello giusto.
Tre cose che la finestra richiede prima di analizzare qualcosa
L'importazione gira con i permessi del vostro utente, quindi un file in una directory accessibile solo a root viene rifiutato prima che il contenuto conti. Il pannello elenca anche solo i tipi di VPN il cui plugin di NetworkManager è installato; senza il plugin OpenVPN, l'opzione è assente invece che guasta. Infine, la scheda di rete deve essere gestita: un'interfaccia contrassegnata come non gestita può accettare una connessione salvata che non si attiverà mai. Controllate tutte e tre prima di modificare il profilo.
Due comandi risolvono il primo passaggio: dpkg -l network-manager-openvpn-gnome per il plugin e nmcli device status per lo stato della scheda.
Cosa scarta in silenzio l'importatore
La traduzione desktop punta a un insieme fisso di proprietà. Le righe fuori da quell'insieme vengono scartate in silenzio, ed è per questo che il tunnel può salire con parti della configurazione prevista mancanti. Gli script dichiarati con up, down e script-security di solito spariscono, come le opzioni dell'interfaccia di gestione e i blocchi remoti aggiuntivi. Una rotta scritta con la parola chiave vpn_gateway è l'eccezione: l'importatore vuole lì un gateway IPv4 letterale e si interrompe con un errore invece di scartare la riga.
Una rotta scartata ha una forma riconoscibile. La connessione si attiva, l'interfaccia ottiene un indirizzo e una sottorete specifica resta irraggiungibile perché la rotta non è mai arrivata nel profilo.
Leggete la connessione salvata, non il file di origine
Il risultato autorevole di un'importazione è il file di chiavi, non il .ovpn che avete selezionato. sudo cat /etc/NetworkManager/system-connections/office.nmconnection mostra ciò che il pannello ha realmente salvato. Se una rotta è presente lì ma manca dalla tabella attiva, l'importazione è riuscita e il problema è l'attivazione. Se manca dal file, l'importatore l'ha scartata e nessuna riconnessione la ripristinerà.
Due percorsi alternativi evitano il livello di traduzione. nmcli connection import type openvpn file ./office.ovpn scrive lo stesso oggetto e segnala errori che il pannello nasconde.
L'editor più vecchio, avviato con nm-connection-editor, espone campi di rotta che il pannello non ha. Per i profili che dipendono da script o da direttive non supportate, tenete il client da riga di comando e sorvegliatelo con un servizio, dopo aver disattivato la connessione desktop in modo che un solo componente possieda il tunnel.
Quando l'importazione funziona ma l'attivazione no
La scheda avanzata conserva il trasporto che è stato importato o scelto per ultimo. Un server in ascolto su UDP fallisce subito quando si seleziona TCP, e il messaggio raramente lo dice. Una connessione che deve partire senza un utente connesso richiede che il suo segreto sia salvato per tutti gli utenti, che è un'impostazione diversa dal salvarlo solo per questa sessione.
Quando nella finestra non c'è nulla di utile, journalctl -u NetworkManager -b mostra perché l'attivazione è fallita. Il client shell non tocca mai quel percorso, ed è per questo che continua a funzionare mentre la copia desktop no.
Come controllo finale, confrontate la versione del plugin con la versione della distribuzione. Un plugin non allineato può installarsi pulito e comunque rifiutarsi di attivare un profilo che nmcli importa senza lamentarsi.