La importació al NetworkManager falla amb fitxers OpenVPN i WireGuard

Vaig triar Importa des de fitxer… a Configuració del GNOME, vaig triar un perfil que funciona amb el client del proveïdor, i el diàleg es va tancar sense afegir res a la llista. En un segon portàtil la importació es va completar, la connexió va aparèixer amb el nom del perfil i després va fallar a la primera sol·licitud d'autenticació. El NetworkManager mai no executa el teu fitxer .ovpn o wg-quick tal com és. Entrega el fitxer a un analitzador, l'analitzador el converteix al format de connexió propi del NetworkManager i, a partir d'aleshores, el túnel es construeix a partir d'aquest objecte analitzat: secrets, rutes, DNS i tota la resta. Així, la pregunta útil no és per què està trencat el fitxer, sinó si l'anàlisi va passar i què va conservar.

Què fa realment la importació amb el fitxer

Per a OpenVPN, l'analitzador viu al paquet del connector, i la connexió que crea apunta a un servei D-Bus com org.freedesktop.NetworkManager.openvpn. Sense connector no hi ha analitzador: nmcli desconeix el tipus i la llista gràfica d'afegir VPN pot no mostrar cap entrada d'importació. WireGuard es diferencia en un punt important: el NetworkManager té els seus propis ajustos de WireGuard des de la sèrie 1.30, així que no hi ha un paquet de connector a part, però el lector de wg-quick només existeix en compilacions que l'inclouen.

De qualsevol manera, el fitxer es llegeix una vegada. El resultat s'escriu com a keyfile a /etc/NetworkManager/system-connections/, amb el nom de la connexió, propietat de root i il·legible per a altres usuaris perquè conté el material de les claus. Aquest keyfile és ara la connexió; editar després el .ovpn original no canvia res.

Tres símptomes pertanyen a tres fases diferents. Que no hi hagi entrada d'importació o que el tipus sigui desconegut vol dir que falta el connector o la versió. Un error d'importació que anomena una directiva vol dir que l'analitzador va llegir el fitxer i en va rebutjar una part. Una connexió que existeix però que mai no s'activa vol dir que l'objecte analitzat està incomplet o que el servidor la rebutja. Decideix quin dels tres tens abans d'editar res.

Confirma el connector abans de depurar el perfil

Un connector absent sembla exactament un perfil corrupte, així que revisa primer el paquet. A Debian i Ubuntu el suport d'OpenVPN arriba com network-manager-openvpn més un ajudant d'escriptori; a Fedora els paquets són NetworkManager-openvpn i NetworkManager-openvpn-gnome; a Arch és networkmanager-openvpn.

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

Després importa des d'un camí absolut: nmcli connection import type openvpn file /home/you/profile.ovpn. Els camins relatius solen funcionar, però un shell que ha canviat de directori converteix una importació ràpida en un desviament. Per a WireGuard, comprova nmcli --version i assegura't que el costat del nucli existeix amb modprobe wireguard; una importació que té èxit en una màquina sense el mòdul et deixa una connexió el dispositiu de la qual no apareix mai. La referència de nmcli documenta el subcomandament import i els noms de tipus acceptats. Si type wireguard es rebutja de pla, la compilació és anterior a la funció, i el pas correcte és un paquet de la distribució o un backport — no copiar la configuració a un directori arbitrari i esperar que alguna cosa la llegeixi.

Llegeix la connexió d'OpenVPN, no el .ovpn

Un cop la connexió existeix, llegeix els ajustos analitzats en lloc de rellegir el fitxer: nmcli connection show "Work VPN" | grep -E '^vpn\.'. Vols el remote i el port, el transport, el material d'identitat — ca, cert, key, tls-auth o tls-crypt — i el mètode d'autenticació. En un perfil amb contrasenya de clau privada, afegeix sudo nmcli --show-secrets connection show "Work VPN" i mira els secret flags: 0 és none, així que el secret és al keyfile; 1 és agent-owned; 2 és not-saved, cosa que vol dir que mai no s'escriu al keyfile; 4 és not-required, cosa que vol dir que no cal cap secret. Són bits, no una escala, així que 3 és simplement agent-owned més not-saved. Un secret que et pregunta una vegada per sessió és agent-owned (1) amb l'agent demanant-lo; no hi ha cap número de flag a part per a això. Un desajust de flags és la raó habitual que un perfil connecti des de l'applet d'escriptori i falli des d'un script o en arrencar.

La manera més ràpida de veure què ha descartat l'analitzador és demanar al connector que torni a escriure el fitxer i després comparar-lo: nmcli connection export "Work VPN" /tmp/roundtrip.ovpn. Les directives que desapareixen en aquesta comparació no existiran en connectar. Els hooks són els sospitosos habituals — script-security, up, down i route-up esperen un script executat amb privilegis elevats i deliberadament no es traslladen. No baixis la verificació ni concedeixis privilegis extra perquè una importació funcioni; una opció no admesa reflecteix normalment el conjunt de funcions del connector i no un servidor inabastable. Porta aquest comportament a un script dispatcher del NetworkManager o a una política del servidor.

Confirma també que els camps d'identitat han sobreviscut: la referència de CA, remote-cert-tls i qualsevol comprovació de nom en què confiés el perfil. Una connexió que puja sense ells pot estar parlant amb el que sigui que respongui en aquesta adreça.

Llegeix la connexió de WireGuard, no el fitxer wg-quick

Un fitxer wg-quick és un format amb semàntica de shell; la connexió importada és un conjunt d'ajustos. PrivateKey passa a ser la clau privada de la interfície, Address passa a ser una o més adreces IPv4 i IPv6, DNS s'assigna a les propietats de resolver del NetworkManager, MTU s'assigna a wireguard.mtu (el valor predeterminat propi de wg-quick és 1420), i cada bloc peer es converteix en una entrada peer amb clau pública, endpoint, IP permeses i keepalive persistent. Imprimeix què s'ha desat amb nmcli --show-secrets connection show wg0; si la llista de peers no apareix en aquesta sortida, llegeix el keyfile:

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

El que no sobreviu és la meitat de shell de wg-quick. PreUp, PostUp, PreDown, PostDown i Table són comportament d'aquesta eina, no atributs d'una interfície WireGuard, així que res no els executa després d'una importació. Si l'original feia servir Table = off per deixar intacta la ruta predeterminada, les versions recents del NetworkManager exposen ip4-auto-default-route i ip6-auto-default-route per al mateix propòsit; configura'ls explícitament en lloc de suposar que la connexió es comporta com el script. Un hook que empenyia una ruta personalitzada necessita aquesta ruta als ajustos d'encaminament de la connexió, o simplement faltarà.

Dóna a la connexió exactament un propietari

La fallada clàssica de després és una connexió que funciona fins al següent arrencada i llavors entra en bucle. Normalment [email protected] encara estava activat d'un experiment anterior, o un client del proveïdor llançava el seu propi dimoni, i dos propietaris escrivien rutes i DNS per a la mateixa destinació. El NetworkManager configura el resolver pel seu propi camí, wg-quick escriu mitjançant resolvconf, i guanya l'últim que escriu — la resolució de noms funciona, després s'atura i després torna a funcionar. Comprova systemctl status wg-quick@wg0, nmcli connection show --active i ip link show type wireguard, i després desactiva el segon propietari en lloc d'ajustar-ne la mètrica.

Si de debò necessites tots dos, dóna'ls interfícies separades i IP permeses disjuntes, i deixa que exactament un d'ells instal·li la ruta predeterminada. Dues rutes predeterminades amb mètriques diferents no són un túnel dividit; és una cursa que decideix el servei que arrenca segon. I després d'una reconnexió, inspecciona de nou l'estat aplicat — una edició manual del resolver que fa que tot funcioni no és prova que la importació estigui completa.

Verifica amb trànsit i sobreviu a un reinici

Aixeca la connexió amb nmcli connection up "Work VPN" i després llegeix estat, adreça i rutes en lloc de refiar-te de la icona: nmcli device show wg0 | grep -E 'GENERAL.STATE|IP4.ADDRESS|IP4.ROUTE', ip route show default i una consulta real d'un nom que només es resol dins del túnel. Un handshake o un ping correcte només demostra que la criptografia funciona; no diu res sobre el reenviament, els prefixos del túnel dividit ni el DNS privat, que són les parts que solen trencar-se.

Després reinicia i repeteix-ho. El comportament d'autoconnect, una interfície reanomenada i un connector que es carrega després del dispositiu són fallades que només veus en una arrencada neta. journalctl -u NetworkManager -b --no-pager | tail -n 40 mostra què va fer el dimoni amb aquesta connexió en aquesta arrencada. Per a un segon escriptori, copia el keyfile i mantén-lo propietat de root amb mode 600, o fes servir nmcli connection export per a OpenVPN i torna a importar el .ovpn resultant — el camí d'exportació no té equivalent a WireGuard, així que aquesta direcció és una còpia de fitxer o una importació nova des de l'original protegit.

Versió curta, per ordre: confirma el connector o la versió del NetworkManager, importa des d'un camí absolut, llegeix els ajustos analitzats incloent-hi els secret flags, compara l'exportació d'OpenVPN amb l'original, revisa hooks i rutes al costat de WireGuard, desactiva qualsevol segon propietari i després verifica, després d'un reinici, una consulta de noms i la taula de rutes. Quan una connexió supera tot això, el fitxer de perfil que la va iniciar pot tornar a l'emmagatzematge protegit.