L'importazione in NetworkManager non riesce con i file OpenVPN e WireGuard

Ho scelto Importa da file… nelle Impostazioni di GNOME, ho scelto un profilo che funziona con il client del fornitore, e la finestra si è chiusa senza aggiungere nulla all'elenco. Su un secondo portatile l'importazione è stata completata, la connessione è comparsa con il nome del profilo e poi ha fallito alla prima richiesta di autenticazione. NetworkManager non esegue mai il tuo file .ovpn o wg-quick così com'è. Consegna il file a un parser, il parser lo converte nel formato di connessione proprietario di NetworkManager e da quel momento il tunnel viene costruito da quell'oggetto analizzato: segreti, rotte, DNS e tutto il resto. Quindi la domanda utile non è perché il file sia rotto, ma se l'analisi sia avvenuta e che cosa abbia conservato.

Che cosa fa davvero l'importazione con il file

Per OpenVPN, il parser vive nel pacchetto del plugin, e la connessione che crea punta a un servizio D-Bus come org.freedesktop.NetworkManager.openvpn. Nessun plugin, nessun parser: il tipo è sconosciuto a nmcli, e l'elenco grafico per aggiungere una VPN potrebbe non mostrare alcuna voce di importazione. WireGuard differisce in un punto importante: NetworkManager ha impostazioni WireGuard proprie dalla serie 1.30, quindi non esiste un pacchetto plugin separato, ma il lettore wg-quick esiste solo nelle build che lo includono.

In ogni caso il file viene letto una volta. Il risultato viene scritto come keyfile sotto /etc/NetworkManager/system-connections/, con il nome della connessione, di proprietà di root e illeggibile per gli altri utenti perché contiene il materiale delle chiavi. Quel keyfile ora è la connessione; modificare in seguito il .ovpn originale non cambia nulla.

Tre sintomi appartengono a tre fasi diverse. Nessuna voce di importazione o un tipo sconosciuto significa che manca il plugin o la versione. Un errore di importazione che nomina una direttiva significa che il parser ha letto il file e ne ha rifiutato una parte. Una connessione che esiste ma non si attiva mai significa che l'oggetto analizzato è incompleto o che il server lo rifiuta. Decidi quale dei tre hai prima di modificare qualcosa.

Conferma il plugin prima di fare il debug del profilo

Un plugin mancante sembra esattamente un profilo corrotto, quindi controlla prima il pacchetto. Su Debian e Ubuntu il supporto OpenVPN arriva come network-manager-openvpn più un helper desktop; su Fedora i pacchetti sono NetworkManager-openvpn e NetworkManager-openvpn-gnome; su Arch è networkmanager-openvpn.

dpkg -l network-manager-openvpn-gnome | tail -n 2
rpm -q NetworkManager-openvpn
pacman -Q networkmanager-openvpn

Poi importa da un percorso assoluto: nmcli connection import type openvpn file /home/you/profile.ovpn. I percorsi relativi di solito funzionano, ma una shell che ha cambiato directory trasforma un'importazione rapida in una deviazione. Per WireGuard, controlla nmcli --version e assicurati che il lato kernel esista con modprobe wireguard; un'importazione che riesce su una macchina senza il modulo ti lascia con una connessione il cui dispositivo non compare mai. Il riferimento di nmcli documenta il sottocomando import e i nomi di tipo accettati. Se type wireguard viene rifiutato di netto, la build è precedente alla funzione, e la mossa corretta è un pacchetto della distribuzione o un backport — non copiare la configurazione in una directory arbitraria sperando che qualcosa la legga.

Leggi la connessione OpenVPN, non il .ovpn

Una volta che la connessione esiste, leggi le impostazioni analizzate invece di rileggere il file: nmcli connection show "Work VPN" | grep -E '^vpn\.'. Ti servono il remote e la porta, il trasporto, il materiale di identità — ca, cert, key, tls-auth o tls-crypt — e il metodo di autenticazione. Su un profilo con password della chiave privata, aggiungi sudo nmcli --show-secrets connection show "Work VPN" e guarda i secret flag: 0 è none, quindi il segreto sta nel keyfile; 1 è agent-owned; 2 è not-saved, cioè non viene mai scritto nel keyfile; 4 è not-required, cioè non serve alcun segreto. Sono bit, non una scala, quindi 3 è semplicemente agent-owned più not-saved. Un segreto che ti chiede una volta per sessione è agent-owned (1) con l'agente che lo chiede; non esiste un numero di flag separato per questo. Un disallineamento dei flag è la ragione abituale per cui un profilo si connette dall'applet del desktop e fallisce da uno script o all'avvio.

Il modo più rapido per vedere che cosa ha scartato il parser è chiedere al plugin di riscrivere il file e poi confrontarlo: nmcli connection export "Work VPN" /tmp/roundtrip.ovpn. Le direttive che spariscono in quel confronto non esisteranno al momento della connessione. Gli hook sono i soliti sospetti — script-security, up, down e route-up si aspettano uno script eseguito con privilegi elevati e non vengono trasferiti di proposito. Non abbassare la verifica e non concedere privilegi extra per far riuscire un'importazione; un'opzione non supportata riflette di solito l'insieme di funzioni del plugin e non un server irraggiungibile. Sposta quel comportamento in uno script dispatcher di NetworkManager o in una policy lato server.

Conferma anche che i campi di identità siano sopravvissuti: il riferimento CA, remote-cert-tls e qualsiasi controllo del nome su cui il profilo faceva affidamento. Una connessione che sale senza di essi potrebbe parlare con qualunque cosa risponda su quell'indirizzo.

Leggi la connessione WireGuard, non il file wg-quick

Un file wg-quick è un formato con semantica di shell; la connessione importata è un insieme di impostazioni. PrivateKey diventa la chiave privata dell'interfaccia, Address diventa uno o più indirizzi IPv4 e IPv6, DNS mappa sulle proprietà resolver di NetworkManager, MTU mappa su wireguard.mtu (il valore predefinito di wg-quick è 1420), e ogni blocco peer diventa una voce peer con chiave pubblica, endpoint, IP consentiti e keepalive persistente. Stampa ciò che è stato salvato con nmcli --show-secrets connection show wg0; se l'elenco dei peer non compare in quell'output, leggi il keyfile:

sudo sed -n '/^\[wireguard\]/,/^\[/p' /etc/NetworkManager/system-connections/wg0.nmconnection

Ciò che non sopravvive è la metà shell di wg-quick. PreUp, PostUp, PreDown, PostDown e Table sono comportamento di quello strumento, non attributi di un'interfaccia WireGuard, quindi nulla li esegue dopo un'importazione. Se l'originale usava Table = off per lasciare in pace la rotta predefinita, le versioni recenti di NetworkManager espongono ip4-auto-default-route e ip6-auto-default-route per lo stesso scopo; impostali esplicitamente invece di dare per scontato che la connessione si comporti come lo script. Un hook che spingeva una rotta personalizzata ha bisogno di quella rotta nelle impostazioni di routing della connessione, altrimenti mancherà semplicemente.

Dai alla connessione esattamente un proprietario

Il classico guasto successivo è una connessione che funziona fino al riavvio seguente e poi entra in loop. Di solito [email protected] era ancora attivo da un esperimento precedente, oppure un client del fornitore avviava un proprio demone, e due proprietari scrivevano rotte e DNS per la stessa destinazione. NetworkManager imposta il resolver per la propria via, wg-quick scrive tramite resolvconf, e vince l'ultimo che scrive — quindi la risoluzione dei nomi funziona, poi si ferma, poi funziona di nuovo. Controlla systemctl status wg-quick@wg0, nmcli connection show --active e ip link show type wireguard, poi disattiva il secondo proprietario invece di regolare la sua metrica.

Se ti servono davvero entrambi, assegna loro interfacce separate e IP consentiti disgiunti, e lascia che esattamente uno dei due installi la rotta predefinita. Due rotte predefinite con metriche diverse non sono un tunnel diviso; è una corsa decisa dal servizio che parte secondo. E dopo una riconnessione, ispeziona di nuovo lo stato applicato — una modifica manuale del resolver che fa funzionare le cose non è prova che l'importazione sia completa.

Verifica con il traffico e sopravvivi a un riavvio

Tira su la connessione con nmcli connection up "Work VPN" e poi leggi stato, indirizzo e rotte invece di fidarti dell'icona: nmcli device show wg0 | grep -E 'GENERAL.STATE|IP4.ADDRESS|IP4.ROUTE', ip route show default e una vera risoluzione di un nome che risolve solo dentro il tunnel. Un handshake o un ping riuscito dimostra solo che la crittografia funziona; non dice nulla su inoltro, prefissi del tunnel diviso o DNS privato, che sono le parti che di solito si rompono.

Poi riavvia e ripeti. Il comportamento di autoconnect, un'interfaccia rinominata e un plugin che si carica dopo il dispositivo sono tutti guasti che vedi solo a un avvio pulito. journalctl -u NetworkManager -b --no-pager | tail -n 40 mostra che cosa ha fatto il demone con questa connessione in questo avvio. Per un secondo desktop, copia il keyfile e tienilo di proprietà di root con mode 600, oppure usa nmcli connection export per OpenVPN e reimporta il .ovpn risultante — il percorso di esportazione non ha equivalente WireGuard, quindi quella direzione è una copia di file o una nuova importazione dall'originale protetto.

Versione breve, in ordine: conferma il plugin o la versione di NetworkManager, importa da un percorso assoluto, leggi le impostazioni analizzate inclusi i secret flag, confronta l'esportazione OpenVPN con l'originale, controlla hook e rotte sul lato WireGuard, disattiva qualsiasi secondo proprietario, poi verifica dopo un riavvio una risoluzione di nome e la tabella delle rotte. Quando una connessione supera tutto questo, il file di profilo che l'ha avviata può tornare nell'archiviazione protetta.