NetworkManager-import feilar med OpenVPN- og WireGuard-filer

Eg valde Importer frå fil… i GNOME-innstillingar, valde ein profil som fungerer med klienten til leverandøren, og dialogen lukka seg utan å leggje noko til i lista. På ein annan laptop vart importen fullført, tilkoplinga dukka opp under namnet til profilen, og deretter feila ho ved den første autentiseringsførespurnaden. NetworkManager køyrer aldri .ovpn- eller wg-quick-fila di som ho er. Det gir fila til ein parser, parsaren gjer ho om til NetworkManagers eige tilkoplingsformat, og frå då av vert tunnelen bygd frå det parserte objektet — løyndomar, ruter, DNS og alt. Så det nyttige spørsmålet er ikkje kvifor fila er øydelagd, men om parsa skjedde og kva ho behheldt.

Kva importen eigentleg gjer med fila

For OpenVPN ligg parsaren i plugin-pakka, og tilkoplinga han lagar peikar på ein D-Bus-teneste som org.freedesktop.NetworkManager.openvpn. Ingen plugin, ingen parser: typen er ukjend for nmcli, og den grafiske lista for å leggje til ein VPN viser kanskje ingen importoppføring i det heile. WireGuard skil seg på eitt viktig punkt — NetworkManager har hatt eigne WireGuard-innstillingar sidan 1.30-serien, så det finst inga eiga plugin-pakke, men wg-quick-lesaren finst berre i bygg som leverer han.

Uansett vert fila lesen éin gong. Resultatet vert skrive som ei keyfile under /etc/NetworkManager/system-connections/, kalla opp etter tilkoplinga, eigd av root og uleseleg for andre brukarar fordi ho inneheld nøkkelmaterialet. Den keyfila er no tilkoplinga; å redigere den opphavlege .ovpn etterpå endrar ingenting.

Tre symptom høyrer til tre ulike fasar. Ingen importoppføring eller ein ukjend type betyr at pluginmodulen eller versjonen manglar. Ein importfeil som namngir eit direktiv betyr at parsaren las fila og avviste ein del av ho. Ei tilkopling som finst men aldri vert aktivert betyr at det parserte objektet er ufullstendig eller at serversida avviser det. Avgjer kva tilfelle du har før du redigerer noko.

Stadfest pluginmodulen før du feilsøkjer profilen

Ein manglande pluginmodul ser nøyaktig ut som ein øydelagd profil, så sjekk pakka først. På Debian og Ubuntu vert OpenVPN-støtta levert som network-manager-openvpn pluss ein skrivebordshjelpar; 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 frå ein absolutt bane: nmcli connection import type openvpn file /home/you/profile.ovpn. Relative banar fungerer vanlegvis, men eit skal som har bytt katalog gjer ein rask import til ein omveg. For WireGuard, sjekk nmcli --version og sørg for at kjernesida finst med modprobe wireguard; ein import som lukkast på ein maskin utan modulen, lèt deg att med ei tilkopling der eininga aldri dukkar opp. Den nmcli-referansen dokumenterer underkommandoen import og dei godtekne typenamna. Vert type wireguard avvist blankt, er bygget eldre enn funksjonen, og det rette trekket er ei distribusjonspakke eller ein backport — ikkje å kopiere konfigurasjonen til ein vilkårleg katalog og håpe at noko les han.

Les OpenVPN-tilkoplinga, ikkje .ovpn-fila

Når tilkoplinga finst, les dei parserte innstillingane i staden for å lese fila 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å ein profil med passord for den private nøkkelen legg du til sudo nmcli --show-secrets connection show "Work VPN" og ser på secret-flaggene: 0 er none, så løyndomen ligg i keyfila; 1 er agent-owned; 2 er not-saved, som betyr at han aldri vert skriven til keyfila; 4 er not-required, som betyr at det ikkje trengst nokon løyndom i det heile. Dei er bitar, ikkje ein skala, så 3 er rett og slett agent-owned pluss not-saved. Ein løyndom som spør éin gong per økt er agent-owned (1), der agenten spør etter han; det finst ikkje eit eige flaggnummer for det. Ein flaggmismatch er den vanlege grunnen til at ein profil koplar til frå skrivebordsappletten og feilar frå eit skript eller ved oppstart.

Den raskaste måten å sjå kva parsaren slapp, er å be pluginmodulen skrive fila tilbake og deretter diffe ho: nmcli connection export "Work VPN" /tmp/roundtrip.ovpn. Direktiv som forsvinn i den diffen, finst ikkje ved tilkoplingstid. Hooks er dei vanlege mistenkte — script-security, up, down og route-up ventar seg eit skript som køyrer med forhøgde rettar og vert medvite ikkje overførte. Ikkje senk verifiseringa og ikkje gi ekstra rettar for å få ein import til å lukkast; eit ikkje-støtta alternativ speglar vanlegvis funksjonssettet til pluginmodulen og ikkje ein utilgjengeleg tenar. Flytt den åtferda til eit NetworkManager-dispatcher-skript eller til policy på serversida.

Stadfest også at identitetsfelta overlevde: CA-referansen, remote-cert-tls og kvar namnekontroll profilen stolte på. Ei tilkopling som kjem opp utan dei, snakkar kanskje med kva som helst som svarar på den adressa.

Les WireGuard-tilkoplinga, ikkje wg-quick-fila

Ei wg-quick-fil er eit format med skallsemantikk; den importerte tilkoplinga er eit sett innstillingar. PrivateKey vert den private nøkkelen til grensesnittet, Address vert éin eller fleire IPv4- og IPv6-adresser, DNS mappar til resolver-eigenskapane til NetworkManager, MTU mappar til wireguard.mtu (wg-quick sin eigen standard er 1420), og kvar peer-blokk vert ein peer-oppføring med offentleg nøkkel, endpoint, tillatne IP-ar og persistent keepalive. Skriv ut det som vart lagra med nmcli --show-secrets connection show wg0; visest ikkje peer-lista i den utskrifta, les keyfila:

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

Det som ikkje overlever, er skallhalvdelen av wg-quick. PreUp, PostUp, PreDown, PostDown og Table er åtferda til det verktøyet, ikkje attributt på eit WireGuard-grensesnitt, så ingenting køyrer dei etter ein import. Viss originalen brukte Table = off for å la standardruta vere i fred, eksponerer nyare NetworkManager-utgjevingar ip4-auto-default-route og ip6-auto-default-route for same føremål; set dei eksplisitt i staden for å anta at tilkoplinga oppfører seg som skriptet. Ein hook som dytta ei eigendefinert rute, treng den ruta i rutinginnstillingane til tilkoplinga, elles manglar ho rett og slett.

Gi tilkoplinga nøyaktig éin eigar

Den klassiske oppfølgingsfeilen er ei tilkopling som virkar til neste oppstart og deretter går i løkke. Vanlegvis var [email protected] framleis aktivert frå eit tidlegare eksperiment, eller ein leverandørklient starta sin eigen daemon, og to eigarar skreiv ruter og DNS for same destinasjon. NetworkManager set resolveren via sin eigen veg, wg-quick skriv via resolvconf, og den siste skrivaren vinn — så namneoppslag virkar, stoppar, og virkar igjen. Sjekk systemctl status wg-quick@wg0, nmcli connection show --active og ip link show type wireguard, og deaktiver deretter den andre eigaren i staden for å justere metricen.

Viss du verkeleg treng begge, gi dei separate grensesnitt og åtskilde tillatne IP-ar, og la nøyaktig éin av dei installere standardruta. To standardruter med ulike metrics er ikkje ein split tunnel; det er eit kappløp som vert avgjort av kva teneste som startar sist. Og etter ei gjenoppkopling, inspiser den brukte tilstanden igjen — ei eingongs manuell resolver-endring som får ting til å virke, er ikkje bevis for at importen er komplett.

Verifiser med trafikk og overlev ein omstart

Ta opp tilkoplinga med nmcli connection up "Work VPN", og les deretter tilstand, adresse og ruter i staden for å stole på ikonet: nmcli device show wg0 | grep -E 'GENERAL.STATE|IP4.ADDRESS|IP4.ROUTE', ip route show default, og eit ekte oppslag av eit namn som berre vert løyst opp inne i tunnelen. Ein handshake eller ein vellukka ping beviser berre at krypteringa virkar; han seier ingenting om vidaresending, split-tunnel-prefiks eller privat DNS, og det er delane som vanlegvis ryker.

Start deretter på nytt og gjer det om att. Autoconnect-åtferd, eit omdøypt grensesnitt og ein pluginmodul som lastar etter eininga er alle feil du berre ser ved ein fersk oppstart. journalctl -u NetworkManager -b --no-pager | tail -n 40 viser kva daemonen gjorde med denne tilkoplinga i denne oppstarten. For ein andre datamaskin, kopier keyfila og hald ho rooteigd med mode 600, eller bruk nmcli connection export for OpenVPN og importer den resulterande .ovpn på nytt — eksportvegen har ingen WireGuard-ekvivalent, så den retninga er ein filkopi eller ein fersk import frå det verna originalet.

Kortversjon, i rekkjefølgje: stadfest plugin- eller NetworkManager-versjonen, importer frå ein absolutt bane, les dei parserte innstillingane inkludert secret-flagg, diff OpenVPN-eksporten mot originalen, sjekk hooks og ruter på WireGuard-sida, deaktiver kvar andre eigar, og verifiser deretter eit namneoppslag og rutetabellen etter ein omstart. Når ei tilkopling består alt dette, kan profilfila som starta ho, gå tilbake til verna lagring.