Import i NetworkManager fejler med OpenVPN- og WireGuard-filer

Jeg valgte Importér fra fil… i GNOME-indstillinger, valgte en profil, der virker med leverandørens klient, og dialogen lukkede uden at føje noget til listen. På en anden laptop blev importen gennemført, forbindelsen dukkede op under profilens navn, og derefter fejlede den ved den første godkendelsesanmodning. NetworkManager kører aldrig din .ovpn- eller wg-quick-fil som den er. Den giver filen til en parser, parseren omdanner den til NetworkManagers eget forbindelsesformat, og fra da af bygges tunnelen ud fra det parsede objekt — hemmeligheder, ruter, DNS og det hele. Så det nyttige spørgsmål er ikke, hvorfor filen er i stykker, men om parsingen skete, og hvad den beholdt.

Hvad importen egentlig gør ved filen

For OpenVPN ligger parseren i plugin-pakken, og den forbindelse, den opretter, peger på en D-Bus-tjeneste som org.freedesktop.NetworkManager.openvpn. Intet plugin, ingen parser: typen er ukendt for nmcli, og den grafiske liste til at tilføje en VPN viser måske slet ingen importpost. WireGuard adskiller sig på ét vigtigt punkt — NetworkManager har haft sine egne WireGuard-indstillinger siden 1.30-serien, så der er ingen separat plugin-pakke, men wg-quick-læseren findes kun i builds, der leverer den.

Uanset hvad læses filen én gang. Resultatet skrives som en keyfile under /etc/NetworkManager/system-connections/, opkaldt efter forbindelsen, ejet af root og ulæselig for andre brugere, fordi den indeholder nøglematerialet. Den keyfile er nu forbindelsen; at redigere den oprindelige .ovpn bagefter ændrer intet.

Tre symptomer hører til tre forskellige faser. Ingen importpost eller en ukendt type betyder, at plugin'et eller versionen mangler. En importfejl, der navngiver et direktiv, betyder, at parseren læste filen og afviste en del af den. En forbindelse, der findes, men aldrig aktiveres, betyder, at det parsede objekt er ufuldstændigt, eller at serversiden afviser det. Afgør, hvilken du har, før du redigerer noget.

Bekræft plugin'et, før du fejlretter profilen

Et manglende plugin ser præcis ud som en beskadiget profil, så tjek pakken først. På Debian og Ubuntu leveres OpenVPN-understøttelsen som network-manager-openvpn plus en skrivebordshjælper; på Fedora er pakkerne NetworkManager-openvpn og NetworkManager-openvpn-gnome; på Arch er det networkmanager-openvpn.

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

Importér derefter fra en absolut sti: nmcli connection import type openvpn file /home/you/profile.ovpn. Relative stier virker normalt, men en shell, der har skiftet mappe, gør en hurtig import til en omvej. For WireGuard, tjek nmcli --version og sørg for, at kernesiden findes med modprobe wireguard; en import, der lykkes på en maskine uden modulet, efterlader dig med en forbindelse, hvis enhed aldrig dukker op. Den nmcli-reference dokumenterer underkommandoen import og de accepterede typenavne. Afvises type wireguard blankt, er buildet ældre end funktionen, og det rigtige skridt er en distributionspakke eller en backport — ikke at kopiere konfigurationen til en vilkårlig mappe og håbe, at noget læser den.

Læs OpenVPN-forbindelsen, ikke .ovpn-filen

Når forbindelsen findes, læs de parsede indstillinger i stedet for at læse filen igen: nmcli connection show "Work VPN" | grep -E '^vpn\.'. Du vil have remote og port, transporten, identitetsmaterialet — ca, cert, key, tls-auth eller tls-crypt — og godkendelsesmetoden. På en profil med en adgangskode til den private nøgle tilføjer du sudo nmcli --show-secrets connection show "Work VPN" og ser på secret flags: 0 er none, så hemmeligheden ligger i keyfilen; 1 er agent-owned; 2 er not-saved, dvs. den skrives aldrig til keyfilen; 4 er not-required, dvs. der er slet ikke brug for nogen hemmelighed. Det er bits, ikke en skala, så 3 er simpelthen agent-owned plus not-saved. En hemmelighed, der spørger én gang pr. session, er agent-owned (1), hvor agenten spørger om den; der findes ikke et separat flag-nummer til det. Et flag-mismatch er den sædvanlige grund til, at en profil forbinder fra skrivebordsappletten og fejler fra et script eller ved opstart.

Den hurtigste måde at se, hvad parseren droppede, er at bede plugin'et skrive filen tilbage og derefter diffe den: nmcli connection export "Work VPN" /tmp/roundtrip.ovpn. Direktiver, der forsvinder i den diff, findes ikke på forbindelsestidspunktet. Hooks er de sædvanlige mistænkte — script-security, up, down og route-up forventer et script, der kører med forhøjede rettigheder, og overføres bevidst ikke. Sænk ikke verifikationen, og giv ikke ekstra rettigheder for at få en import til at lykkes; en ikke-understøttet mulighed afspejler normalt plugin'ets funktionssæt og ikke en utilgængelig server. Flyt den adfærd til et NetworkManager-dispatcher-script eller til serversidepolitik.

Bekræft også, at identitetsfelterne overlevede: CA-reference, remote-cert-tls og enhver navnekontrol, som profilen stolede på. En forbindelse, der kommer op uden dem, taler måske med hvad der end svarer på den adresse.

Læs WireGuard-forbindelsen, ikke wg-quick-filen

En wg-quick-fil er et format med shell-semantik; den importerede forbindelse er et sæt indstillinger. PrivateKey bliver grænsefladens private nøgle, Address bliver en eller flere IPv4- og IPv6-adresser, DNS mapper til NetworkManagers resolver-egenskaber, MTU mapper til wireguard.mtu (wg-quicks egen standard er 1420), og hver peer-blok bliver en peer-post med offentlig nøgle, endpoint, tilladte IP'er og persistent keepalive. Udskriv det, der blev gemt, med nmcli --show-secrets connection show wg0; hvis peer-listen ikke vises i den output, så læs keyfilen:

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

Det, der ikke overlever, er shell-halvdelen af wg-quick. PreUp, PostUp, PreDown, PostDown og Table er den værktøjs adfærd, ikke attributter på en WireGuard-grænseflade, så intet kører dem efter en import. Hvis originalen brugte Table = off for at lade standardruten være, eksponerer nyere NetworkManager-udgivelser ip4-auto-default-route og ip6-auto-default-route til samme formål; sæt dem eksplicit i stedet for at antage, at forbindelsen opfører sig som scriptet. Et hook, der skubbede en brugerdefineret rute, har brug for den rute i forbindelsens routingindstillinger, ellers mangler den bare.

Giv forbindelsen præcis én ejer

Den klassiske opfølgningsfejl er en forbindelse, der virker indtil næste opstart og derefter looper. Normalt var [email protected] stadig aktiveret fra et tidligere eksperiment, eller en leverandørklient startede sin egen daemon, og to ejere skrev ruter og DNS for samme destination. NetworkManager sætter resolveren ad sin egen vej, wg-quick skriver via resolvconf, og den sidste skriver vinder — så navneopløsning virker, stopper, og virker igen. Tjek systemctl status wg-quick@wg0, nmcli connection show --active og ip link show type wireguard, og deaktiver derefter den anden ejer i stedet for at justere dens metric.

Hvis du virkelig har brug for begge, giv dem separate grænseflader og adskilte tilladte IP'er, og lad præcis én af dem installere standardruten. To standardruter med forskellige metrics er ikke en split tunnel; det er et kapløb, der afgøres af, hvilken tjeneste der starter som den anden. Og efter en genopkobling, inspicér den anvendte tilstand igen — en enkeltstående manuel resolver-ændring, der får tingene til at virke, er ikke bevis for, at importen er komplet.

Verificér med trafik og overlev en genstart

Bring forbindelsen op med nmcli connection up "Work VPN", og læs derefter tilstand, adresse og ruter i stedet for at stole på ikonet: nmcli device show wg0 | grep -E 'GENERAL.STATE|IP4.ADDRESS|IP4.ROUTE', ip route show default, og et rigtigt opslag af et navn, der kun opløses inde i tunnelen. Et handshake eller et vellykket ping beviser kun, at krypteringen virker; det siger intet om videresendelse, split-tunnel-præfikser eller privat DNS, og det er de dele, der normalt brækker.

Genstart derefter, og gentag det. Autoconnect-adfærd, en omdøbt grænseflade og et plugin, der indlæses efter enheden, er alle fejl, du kun ser ved en frisk opstart. journalctl -u NetworkManager -b --no-pager | tail -n 40 viser, hvad daemonen gjorde med denne forbindelse i denne opstart. Til en anden computer skal du kopiere keyfilen og holde den root-ejet med mode 600, eller bruge nmcli connection export til OpenVPN og importere den resulterende .ovpn igen — eksportvejen har ingen WireGuard-ækvivalent, så den retning er en filkopi eller en frisk import fra den beskyttede original.

Kort version, i rækkefølge: bekræft plugin- eller NetworkManager-versionen, importér fra en absolut sti, læs de parsede indstillinger inklusive secret flags, diff OpenVPN-eksporten mod originalen, tjek hooks og ruter på WireGuard-siden, deaktiver enhver anden ejer, og verificér derefter et navneopslag og rutetabellen efter en genstart. Når en forbindelse består alt det, kan profilfilen, der startede den, gå tilbage i beskyttet lager.