NetworkManager-import feiler med OpenVPN- og WireGuard-filer

Jeg valgte Importer fra fil… i GNOME-innstillinger, valgte en profil som fungerer med leverandørens klient, og dialogen lukket seg uten å legge noe til i listen. På en annen laptop ble importen fullført, tilkoblingen dukket opp under profilens navn, og deretter feilet den ved den første autentiseringsforespørselen. NetworkManager kjører aldri .ovpn- eller wg-quick-filen din som den er. Den gir filen til en parser, parseren gjør den om til NetworkManagers eget tilkoblingsformat, og fra da av bygges tunnelen fra det parsede objektet — hemmeligheter, ruter, DNS og alt. Så det nyttige spørsmålet er ikke hvorfor filen er ødelagt, men om parsingen skjedde og hva den beholdt.

Hva importen faktisk gjør med filen

For OpenVPN ligger parseren i plugin-pakken, og tilkoblingen den lager peker på en D-Bus-tjeneste som org.freedesktop.NetworkManager.openvpn. Ingen plugin, ingen parser: typen er ukjent for nmcli, og den grafiske listen for å legge til en VPN viser kanskje ingen importoppføring i det hele tatt. WireGuard skiller seg på ett viktig punkt — NetworkManager har hatt egne WireGuard-innstillinger siden 1.30-serien, så det finnes ingen egen plugin-pakke, men wg-quick-leseren finnes bare i bygg som leverer den.

Uansett leses filen én gang. Resultatet skrives som en keyfile under /etc/NetworkManager/system-connections/, oppkalt etter tilkoblingen, eid av root og ulæselig for andre brukere fordi den inneholder nøkkelmaterialet. Den keyfilen er nå tilkoblingen; å redigere den opprinnelige .ovpn etterpå endrer ingenting.

Tre symptomer hører til tre forskjellige faser. Ingen importoppføring eller en ukjent type betyr at pluginmodulen eller versjonen mangler. En importfeil som navngir et direktiv betyr at parseren leste filen og avviste en del av den. En tilkobling som finnes men aldri aktiveres betyr at det parsede objektet er ufullstendig eller at serversiden avviser det. Avgjør hvilken du har før du redigerer noe.

Bekreft pluginmodulen før du feilsøker profilen

En manglende pluginmodul ser nøyaktig ut som en ødelagt profil, så sjekk pakken først. På Debian og Ubuntu leveres OpenVPN-støtten som network-manager-openvpn pluss en skrivebordshjelper; på Fedora er pakkene 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

Importer deretter fra en absolutt bane: nmcli connection import type openvpn file /home/you/profile.ovpn. Relative baner fungerer vanligvis, men et skall som har byttet katalog gjør en rask import til en omvei. For WireGuard, sjekk nmcli --version og sørg for at kjernesiden finnes med modprobe wireguard; en import som lykkes på en maskin uten modulen, etterlater deg med en tilkobling der enheten aldri dukker opp. Den nmcli-referansen dokumenterer underkommandoen import og de godtatte typenavnene. Avvises type wireguard blankt, er bygget eldre enn funksjonen, og det riktige trekket er en distribusjonspakke eller en backport — ikke å kopiere konfigurasjonen til en vilkårlig katalog og håpe at noe leser den.

Les OpenVPN-tilkoblingen, ikke .ovpn-filen

Når tilkoblingen finnes, les de parsede innstillingene i stedet for å lese filen på nytt: nmcli connection show "Work VPN" | grep -E '^vpn\.'. Du vil ha remote og port, transporten, identitetsmaterialet — ca, cert, key, tls-auth eller tls-crypt — og autentiseringsmetoden. På en profil med passord for den private nøkkelen legger du til sudo nmcli --show-secrets connection show "Work VPN" og ser på secret-flaggene: 0 er none, så hemmeligheten ligger i keyfilen; 1 er agent-owned; 2 er not-saved, som betyr at den aldri skrives til keyfilen; 4 er not-required, som betyr at det ikke trengs noen hemmelighet i det hele tatt. De er biter, ikke en skala, så 3 er rett og slett agent-owned pluss not-saved. En hemmelighet som spør én gang per økt er agent-owned (1), der agenten spør etter den; det finnes ikke et eget flaggnummer for det. En flaggmismatch er den vanlige grunnen til at en profil kobler til fra skrivebordsappletten og feiler fra et skript eller ved oppstart.

Den raskeste måten å se hva parseren slapp, er å be pluginmodulen skrive filen tilbake og deretter diffe den: nmcli connection export "Work VPN" /tmp/roundtrip.ovpn. Direktiver som forsvinner i den diffen, finnes ikke ved tilkoblingstid. Hooks er de vanlige mistenkte — script-security, up, down og route-up forventer et skript som kjører med forhøyede rettigheter og overføres bevisst ikke. Ikke senk verifiseringen og ikke gi ekstra rettigheter for å få en import til å lykkes; et ikke-støttet alternativ gjenspeiler vanligvis funksjonssettet til pluginmodulen og ikke en utilgjengelig server. Flytt den oppførselen til et NetworkManager-dispatcher-skript eller til policy på serversiden.

Bekreft også at identitetsfeltene overlevde: CA-referansen, remote-cert-tls og enhver navnekontroll profilen stolte på. En tilkobling som kommer opp uten dem, snakker kanskje med hva som helst som svarer på den adressen.

Les WireGuard-tilkoblingen, ikke wg-quick-filen

En wg-quick-fil er et format med skallsemantikk; den importerte tilkoblingen er et sett innstillinger. PrivateKey blir grensesnittets private nøkkel, Address blir én eller flere IPv4- og IPv6-adresser, DNS mapper til NetworkManagers resolver-egenskaper, MTU mapper til wireguard.mtu (wg-quicks egen standard er 1420), og hver peer-blokk blir en peer-oppføring med offentlig nøkkel, endpoint, tillatte IP-er og persistent keepalive. Skriv ut det som ble lagret med nmcli --show-secrets connection show wg0; vises ikke peer-listen i den utskriften, les keyfilen:

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

Det som ikke overlever, er skallhalvdelen av wg-quick. PreUp, PostUp, PreDown, PostDown og Table er oppførselen til det verktøyet, ikke attributter på et WireGuard-grensesnitt, så ingenting kjører dem etter en import. Hvis originalen brukte Table = off for å la standardruten være i fred, eksponerer nyere NetworkManager-utgivelser ip4-auto-default-route og ip6-auto-default-route for samme formål; sett dem eksplisitt i stedet for å anta at tilkoblingen oppfører seg som skriptet. En hook som dyttet en egendefinert rute, trenger den ruten i tilkoblingens rutinginnstillinger, ellers mangler den rett og slett.

Gi tilkoblingen nøyaktig én eier

Den klassiske oppfølgingsfeilen er en tilkobling som virker til neste oppstart og deretter går i løkke. Vanligvis var [email protected] fortsatt aktivert fra et tidligere eksperiment, eller en leverandørklient startet sin egen daemon, og to eiere skrev ruter og DNS for samme destinasjon. NetworkManager setter resolveren via sin egen vei, wg-quick skriver via resolvconf, og den siste skriveren vinner — så navneoppslag virker, stopper, og virker igjen. Sjekk systemctl status wg-quick@wg0, nmcli connection show --active og ip link show type wireguard, og deaktiver deretter den andre eieren i stedet for å justere metricen.

Hvis du virkelig trenger begge, gi dem separate grensesnitt og adskilte tillatte IP-er, og la nøyaktig én av dem installere standardruten. To standardruter med forskjellige metrics er ikke en split tunnel; det er et kappløp som avgjøres av hvilken tjeneste som starter sist. Og etter en gjenoppkobling, inspiser den anvendte tilstanden igjen — en engangs manuell resolver-endring som får ting til å virke, er ikke bevis for at importen er komplett.

Verifiser med trafikk og overlev en omstart

Ta opp tilkoblingen med nmcli connection up "Work VPN", og les deretter tilstand, adresse og ruter i stedet for å stole på ikonet: nmcli device show wg0 | grep -E 'GENERAL.STATE|IP4.ADDRESS|IP4.ROUTE', ip route show default, og et ekte oppslag av et navn som bare løses opp inne i tunnelen. En handshake eller en vellykket ping beviser bare at krypteringen virker; den sier ingenting om videresending, split-tunnel-prefikser eller privat DNS, og det er delene som vanligvis ryker.

Start deretter på nytt og gjenta det. Autoconnect-oppførsel, et omdøpt grensesnitt og en pluginmodul som lastes etter enheten er alle feil du bare ser ved en fersk oppstart. journalctl -u NetworkManager -b --no-pager | tail -n 40 viser hva daemonen gjorde med denne tilkoblingen i denne oppstarten. For en andre datamaskin, kopier keyfilen og hold den rooteid med mode 600, eller bruk nmcli connection export for OpenVPN og importer den resulterende .ovpn på nytt — eksportveien har ingen WireGuard-ekvivalent, så den retningen er en filkopi eller en fersk import fra det beskyttede originalet.

Kortversjon, i rekkefølge: bekreft plugin- eller NetworkManager-versjonen, importer fra en absolutt bane, les de parsede innstillingene inkludert secret-flagg, diff OpenVPN-eksporten mot originalen, sjekk hooks og ruter på WireGuard-siden, deaktiver enhver andre eier, og verifiser deretter et navneoppslag og rutetabellen etter en omstart. Når en tilkobling består alt dette, kan profilfilen som startet den, gå tilbake til beskyttet lagring.