NetworkManager-import misslyckas med OpenVPN- och WireGuard-filer

Jag valde Importera från fil… i GNOME-inställningar, valde en profil som fungerar med leverantörens klient, och dialogen stängdes utan att lägga till något i listan. På en andra laptop slutfördes importen, anslutningen dök upp under profilens namn, och sedan misslyckades den vid den första autentiseringsfrågan. NetworkManager kör aldrig din .ovpn- eller wg-quick-fil som den är. Det lämnar filen till en parser, parsern omvandlar den till NetworkManagers eget anslutningsformat, och från och med då byggs tunneln utifrån det parsade objektet — hemligheter, rutter, DNS och allt. Så den användbara frågan är inte varför filen är trasig, utan om parsningen skedde och vad den behöll.

Vad importen egentligen gör med filen

För OpenVPN ligger parsern i pluginpaketet, och anslutningen den skapar pekar på en D-Bus-tjänst som org.freedesktop.NetworkManager.openvpn. Ingen plugin, ingen parser: typen är okänd för nmcli, och den grafiska listan för att lägga till en VPN kanske inte visar någon importpost alls. WireGuard skiljer sig på en viktig punkt — NetworkManager har haft egna WireGuard-inställningar sedan 1.30-serien, så det finns inget separat pluginpaket, men wg-quick-läsaren finns bara i byggen som levererar den.

Hur som helst läses filen en gång. Resultatet skrivs som en keyfile under /etc/NetworkManager/system-connections/, uppkallad efter anslutningen, ägd av root och oläsbar för andra användare eftersom den innehåller nyckelmaterialet. Den keyfilen är nu anslutningen; att redigera den ursprungliga .ovpn efteråt ändrar ingenting.

Tre symtom hör till tre olika faser. Ingen importpost eller en okänd typ betyder att pluginmodulen eller versionen saknas. Ett importfel som namnger ett direktiv betyder att parsern läste filen och avvisade en del av den. En anslutning som finns men aldrig aktiveras betyder att det parsade objektet är ofullständigt eller att serversidan avvisar det. Avgör vilket fall du har innan du redigerar något.

Bekräfta pluginmodulen innan du felsöker profilen

En saknad pluginmodul ser exakt ut som en skadad profil, så kontrollera paketet först. På Debian och Ubuntu levereras OpenVPN-stödet som network-manager-openvpn plus en skrivbordshjälpare; på Fedora är paketen NetworkManager-openvpn och NetworkManager-openvpn-gnome; på Arch är det networkmanager-openvpn.

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

Importera sedan från en absolut sökväg: nmcli connection import type openvpn file /home/you/profile.ovpn. Relativa sökvägar fungerar oftast, men ett skal som har bytt katalog gör en snabb import till en omväg. Kontrollera för WireGuard nmcli --version och se till att kärnsidan finns med modprobe wireguard; en import som lyckas på en maskin utan modulen lämnar dig med en anslutning vars enhet aldrig dyker upp. Den nmcli-referens dokumenterar underkommandot import och de accepterade typnamnen. Avvisas type wireguard blankt är bygget äldre än funktionen, och rätt steg är ett distributionspaket eller en backport — inte att kopiera konfigurationen till en godtycklig katalog och hoppas att något läser den.

Läs OpenVPN-anslutningen, inte .ovpn-filen

När anslutningen finns, läs de parsade inställningarna i stället för att läsa filen igen: nmcli connection show "Work VPN" | grep -E '^vpn\.'. Du vill ha remote och port, transporten, identitetsmaterialet — ca, cert, key, tls-auth eller tls-crypt — och autentiseringsmetoden. Lägg på en profil med lösenord för den privata nyckeln till sudo nmcli --show-secrets connection show "Work VPN" och titta på secret-flaggorna: 0 är none, så hemligheten ligger i keyfilen; 1 är agent-owned; 2 är not-saved, vilket betyder att den aldrig skrivs till keyfilen; 4 är not-required, vilket betyder att ingen hemlighet behövs alls. De är bitar, inte en skala, så 3 är helt enkelt agent-owned plus not-saved. En hemlighet som frågar en gång per session är agent-owned (1), där agenten frågar efter den; det finns inget separat flagnummer för det. En flaggmismatch är den vanliga orsaken till att en profil ansluter från skrivbordsappletten och misslyckas från ett skript eller vid uppstart.

Det snabbaste sättet att se vad parsern tappade är att be pluginmodulen skriva tillbaka filen och sedan diffa den: nmcli connection export "Work VPN" /tmp/roundtrip.ovpn. Direktiv som försvinner i den diffen finns inte vid anslutningstillfället. Hooks är de vanliga misstänkta — script-security, up, down och route-up förväntar sig ett skript som körs med förhöjda rättigheter och förs inte över medvetet. Sänk inte verifieringen och ge inga extra privilegier för att få en import att lyckas; ett icke stött option speglar oftast pluginmodulens funktionsuppsättning och inte en onåbar server. Flytta det beteendet till ett NetworkManager-dispatcherskript eller till policy på serversidan.

Bekräfta också att identitetsfälten överlevde: CA-referensen, remote-cert-tls och alla namnkontroller som profilen förlitade sig på. En anslutning som kommer upp utan dem talar kanske med vad som helst som svarar på den adressen.

Läs WireGuard-anslutningen, inte wg-quick-filen

En wg-quick-fil är ett format med skalsemantik; den importerade anslutningen är en uppsättning inställningar. PrivateKey blir gränssnittets privata nyckel, Address blir en eller flera IPv4- och IPv6-adresser, DNS mappar till NetworkManagers resolveregenskaper, MTU mappar till wireguard.mtu (wg-quicks egen standard är 1420), och varje peer-block blir en peer-post med offentlig nyckel, endpoint, tillåtna IP-adresser och persistent keepalive. Skriv ut vad som lagrades med nmcli --show-secrets connection show wg0; om peer-listan inte visas i den utskriften, läs keyfilen:

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

Det som inte överlever är skalhalvan av wg-quick. PreUp, PostUp, PreDown, PostDown och Table är det verktygets beteende, inte attribut på ett WireGuard-gränssnitt, så inget kör dem efter en import. Om originalet använde Table = off för att lämna standardrutten i fred, exponerar nyare NetworkManager-utgåvor ip4-auto-default-route och ip6-auto-default-route för samma syfte; sätt dem uttryckligen i stället för att anta att anslutningen beter sig som skriptet. En hook som sköt in en anpassad rutt behöver den rutten i anslutningens routinginställningar, annars saknas den helt enkelt.

Ge anslutningen exakt en ägare

Det klassiska uppföljningsfelet är en anslutning som fungerar till nästa uppstart och sedan loopar. Oftast var [email protected] fortfarande aktiverad från ett tidigare experiment, eller så startade en leverantörsklient sin egen daemon, och två ägare skrev rutter och DNS för samma destination. NetworkManager sätter resolvern via sin egen väg, wg-quick skriver via resolvconf, och den sista skrivaren vinner — så namnuppslagning fungerar, slutar, och fungerar igen. Kontrollera systemctl status wg-quick@wg0, nmcli connection show --active och ip link show type wireguard och inaktivera sedan den andra ägaren i stället för att justera dess metric.

Om du verkligen behöver båda, ge dem separata gränssnitt och disjunkta tillåtna IP-adresser, och låt exakt en av dem installera standardrutten. Två standardrutter med olika metrics är inte en split tunnel; det är en kapplöpning som avgörs av vilken tjänst som startar sist. Och efter en återanslutning, inspektera det tillämpade tillståndet igen — en engångsändring av resolvern för hand som får saker att fungera är inget bevis för att importen är komplett.

Verifiera med trafik och överlev en omstart

Ta upp anslutningen med nmcli connection up "Work VPN" och läs sedan tillstånd, adress och rutter i stället för att lita på ikonen: nmcli device show wg0 | grep -E 'GENERAL.STATE|IP4.ADDRESS|IP4.ROUTE', ip route show default, och en riktig uppslagning av ett namn som bara löses upp inne i tunneln. En handskakning eller en lyckad ping bevisar bara att krypteringen fungerar; den säger ingenting om vidarebefordran, split-tunnel-prefix eller privat DNS, och det är de delarna som brukar gå sönder.

Starta sedan om och upprepa det. Autoconnect-beteende, ett omdöpt gränssnitt och en pluginmodul som laddas efter enheten är alla fel du bara ser vid en färsk uppstart. journalctl -u NetworkManager -b --no-pager | tail -n 40 visar vad daemonen gjorde med den här anslutningen i den här uppstarten. För en andra dator, kopiera keyfilen och håll den rootägd med mode 600, eller använd nmcli connection export för OpenVPN och importera den resulterande .ovpn igen — exportvägen har ingen WireGuard-motsvarighet, så den riktningen är en filkopia eller en färsk import från det skyddade originalet.

Kortversion, i ordning: bekräfta plugin- eller NetworkManager-versionen, importera från en absolut sökväg, läs de parsade inställningarna inklusive secret-flaggorna, diffa OpenVPN-exporten mot originalet, kontrollera hooks och rutter på WireGuard-sidan, inaktivera alla andra ägare, och verifiera sedan en namnuppslagning och rutttabellen efter en omstart. När en anslutning klarar allt det kan profilfilen som startade den gå tillbaka till skyddad lagring.