A NetworkManager importálása meghiúsul OpenVPN- és WireGuard-fájloknál

Kiválasztottam a Importálás fájlból… lehetőséget a GNOME-beállításokban, kiválasztottam egy profilt, amely működik a szállító kliensével, és a párbeszédablak bezárult anélkül, hogy bármit hozzáadott volna a listához. Egy második laptopon az importálás befejeződött, a kapcsolat megjelent a profil neve alatt, majd az első hitelesítési kérésnél meghiúsult. A NetworkManager soha nem futtatja a .ovpn vagy wg-quick fájlt úgy, ahogy van. Átadja a fájlt egy feldolgozónak, a feldolgozó átalakítja a NetworkManager saját kapcsolatformátumára, és onnantól az alagút ebből a feldolgozott objektumból épül fel — titkok, útvonalak, DNS és minden más. Tehát a hasznos kérdés nem az, hogy miért hibás a fájl, hanem hogy megtörtént-e a feldolgozás, és mit tartott meg.

Mit tesz valójában az importálás a fájllal

Az OpenVPN esetében a feldolgozó a bővítménycsomagban él, és a létrehozott kapcsolat egy D-Bus szolgáltatásra mutat, például org.freedesktop.NetworkManager.openvpn. Nincs bővítmény, nincs feldolgozó: a típus ismeretlen az nmcli számára, és a grafikus VPN-hozzáadási lista esetleg egyáltalán nem mutat importálási bejegyzést. A WireGuard egy fontos ponton különbözik — a NetworkManagernek az 1.30-as sorozat óta saját WireGuard-beállításai vannak, tehát nincs külön bővítménycsomag, de a wg-quick olvasó csak azokban a buildekben létezik, amelyek szállítják.

Akárhogy is, a fájlt egyszer olvassa be. Az eredmény keyfile-ként íródik a /etc/NetworkManager/system-connections/ alá, a kapcsolatról elnevezve, root tulajdonában, és más felhasználók számára olvashatatlan, mert tartalmazza a kulcsanyagot. Ez a keyfile most a kapcsolat; az eredeti .ovpn későbbi szerkesztése semmit sem változtat.

Három tünet három különböző fázishoz tartozik. Nincs importálási bejegyzés vagy ismeretlen típus azt jelenti, hogy hiányzik a bővítmény vagy a verzió. Az importálási hiba, amely megnevez egy direktívát, azt jelenti, hogy a feldolgozó beolvasta a fájlt, és annak egy részét elutasította. Az a kapcsolat, amely létezik, de soha nem aktiválódik, azt jelenti, hogy a feldolgozott objektum hiányos, vagy a szerver elutasítja. Döntse el, melyik eset áll fenn, mielőtt bármit szerkeszt.

Erősítse meg a bővítményt, mielőtt a profilt hibakeresné

A hiányzó bővítmény pontosan úgy néz ki, mint a sérült profil, ezért először a csomagot ellenőrizze. Debianon és Ubuntun az OpenVPN-támogatás network-manager-openvpn néven érkezik plusz egy asztali segéd; Fedorán a csomagok a NetworkManager-openvpn és a NetworkManager-openvpn-gnome; Archon ez a networkmanager-openvpn.

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

Ezután abszolút útvonalról importáljon: nmcli connection import type openvpn file /home/you/profile.ovpn. A relatív útvonalak általában működnek, de a könyvtárat váltott shell az gyors importot kerülőúttá teszi. A WireGuardnál ellenőrizze a nmcli --version parancsot, és győződjön meg róla, hogy a kernel oldala létezik a modprobe wireguard paranccsal; az import, amely a modul nélküli gépen sikerül, olyan kapcsolatot hagy, amelynek eszköze soha nem jelenik meg. A nmcli-referencia dokumentálja az import alparancsot és az elfogadott típusneveket. Ha a type wireguard azonnal elutasításra kerül, a build régebbi a funkciónál, és a helyes lépés egy disztribúciós csomag vagy backport — nem pedig a konfiguráció másolása egy tetszőleges könyvtárba abban a reményben, hogy valami olvassa.

Az OpenVPN-kapcsolatot olvassa, ne a .ovpn-t

Ha a kapcsolat létezik, a feldolgozott beállításokat olvassa a fájl újraolvasása helyett: nmcli connection show "Work VPN" | grep -E '^vpn\.'. A remote-ra és a portra, a transzportra, az identitásanyagra — ca, cert, key, tls-auth vagy tls-crypt — és a hitelesítési módszerre van szüksége. A privát kulcs jelszavával rendelkező profilnál adja hozzá a sudo nmcli --show-secrets connection show "Work VPN" parancsot, és nézze meg a secret jelzőket: a 0 a none, tehát a titok a keyfile-ban van; az 1 agent-owned; a 2 not-saved, vagyis soha nem íródik a keyfile-ba; a 4 not-required, vagyis egyáltalán nincs szükség titokra. Ezek bitek, nem skála, tehát a 3 egyszerűen agent-owned plus not-saved. Az a titok, amelyet munkamenetenként egyszer kérdeznek meg, agent-owned (1), amelyet az agent kér; erre nincs külön jelzőszám. A jelzők eltérése a szokásos oka annak, hogy egy profil az asztali appletből kapcsolódik, szkriptből vagy indításkor viszont meghiúsul.

A leggyorsabb módja annak megtekintésére, mit dobott el a feldolgozó, ha megkéri a bővítményt, hogy írja vissza a fájlt, majd összehasonlítja: nmcli connection export "Work VPN" /tmp/roundtrip.ovpn. Azok a direktívák, amelyek eltűnnek ebből a diffből, a kapcsolódás idején nem léteznek majd. A hookok a szokásos gyanúsítottak — a script-security, up, down és route-up emelt jogosultságú szkriptet vár, és szándékosan nem kerülnek át. Ne csökkentse az ellenőrzést, és ne adjon extra jogosultságokat az import sikeréhez; a nem támogatott opció általában a bővítmény funkciókészletét tükrözi, nem egy elérhetetlen szervert. Helyezze ezt a viselkedést NetworkManager dispatcher-szkriptbe vagy szerveroldali szabályzatba.

Azt is ellenőrizze, hogy az identitásmezők túlélték-e: a CA-hivatkozás, a remote-cert-tls és minden névellenőrzés, amelyre a profil támaszkodott. Az a kapcsolat, amely ezek nélkül jön fel, esetleg bármihez beszél, ami azon a címen válaszol.

A WireGuard-kapcsolatot olvassa, ne a wg-quick fájlt

A wg-quick fájl shell-szemantikájú formátum; az importált kapcsolat beállítások halmaza. A PrivateKey lesz az interfész privát kulcsa, az Address egy vagy több IPv4- és IPv6-cím, a DNS a NetworkManager resolver-tulajdonságaira képeződik le, az MTU a wireguard.mtu-ra képeződik (a wg-quick saját alapértéke 1420), és minden peer-blokk peer-bejegyzéssé válik nyilvános kulccsal, endpointekkel, engedélyezett IP-kkel és persistent keepalive-pal. Nyomtassa ki, mi lett tárolva, a nmcli --show-secrets connection show wg0 paranccsal; ha a peer-lista nem jelenik meg ebben a kimenetben, olvassa a keyfile-t:

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

Ami nem éli túl, az a wg-quick shell-fele. A PreUp, PostUp, PreDown, PostDown és Table az adott eszköz viselkedése, nem egy WireGuard-interfész attribútumai, ezért importálás után semmi nem futtatja őket. Ha az eredeti a Table = off beállítást használta, hogy békén hagyja az alapértelmezett útvonalat, az újabb NetworkManager-kiadások ugyanerre a célra az ip4-auto-default-route és ip6-auto-default-route beállításokat kínálják; állítsa be őket kifejezetten, ahelyett hogy feltételezné, hogy a kapcsolat úgy viselkedik, mint a szkript. Az a hook, amely egyéni útvonalat tolt be, annak az útvonalnak a kapcsolat útvonal-beállításaiban kell lennie, különben egyszerűen hiányozni fog.

Adjon a kapcsolatnak pontosan egy tulajdonost

A klasszikus utólagos hiba egy kapcsolat, amely a következő indításig működik, majd hurkolódik. Általában a [email protected] még egy korábbi kísérletből engedélyezve volt, vagy egy szállítói kliens indította a saját daemonját, és két tulajdonos írt útvonalakat és DNS-t ugyanahhoz a célhoz. A NetworkManager a saját útján állítja be a resolvert, a wg-quick a resolvconfon keresztül ír, és az utolsó író nyer — tehát a névfeloldás működik, majd leáll, majd újra működik. Ellenőrizze a systemctl status wg-quick@wg0, nmcli connection show --active és ip link show type wireguard parancsokat, majd tiltsa le a második tulajdonost, ahelyett hogy a metricjét hangolná.

Ha valóban mindkettőre szüksége van, adjon nekik külön interfészeket és diszjunkt engedélyezett IP-ket, és hagyja, hogy pontosan az egyik telepítse az alapértelmezett útvonalat. Két különböző metricájú alapértelmezett útvonal nem split tunnel; ez egy verseny, amelyet az a szolgáltatás dönt el, amelyik másodikként indul. És újracsatlakozás után ismét vizsgálja meg az alkalmazott állapotot — az egyszeri kézi resolver-módosítás, amely működőképessé tesz dolgokat, nem bizonyítja, hogy az import teljes.

Ellenőrizze forgalommal, és élje túl az újraindítást

Hozza fel a kapcsolatot a nmcli connection up "Work VPN" paranccsal, majd olvassa az állapotot, a címet és az útvonalakat ahelyett, hogy az ikonnak hinne: nmcli device show wg0 | grep -E 'GENERAL.STATE|IP4.ADDRESS|IP4.ROUTE', ip route show default, és egy valódi lekérdezés egy olyan névre, amely csak az alagúton belül oldódik fel. Egy handshake vagy egy sikeres ping csak azt bizonyítja, hogy a kriptográfia működik; semmit sem mond a továbbításról, a split-tunnel előtagokról vagy a privát DNS-ről, és ezek a részek szoktak eltörni.

Aztán indítsa újra, és ismételje meg. Az autoconnect viselkedése, az átnevezett interfész és az eszköz után betöltődő bővítmény mind olyan hibák, amelyeket csak friss indításkor lát. A journalctl -u NetworkManager -b --no-pager | tail -n 40 megmutatja, mit tett a daemon ezzel a kapcsolattal ebben az indításban. Egy második asztali géphez másolja a keyfile-t, és tartsa root tulajdonban, 600-as móddal, vagy használja a nmcli connection export parancsot OpenVPN-hez, és importálja újra az így kapott .ovpn fájlt — az exportútvonalnak nincs WireGuard-megfelelője, tehát ez az irány fájlmásolás vagy friss import a védett eredetiből.

Rövid változat, sorrendben: erősítse meg a bővítményt vagy a NetworkManager verzióját, importáljon abszolút útvonalról, olvassa a feldolgozott beállításokat a secret jelzőkkel együtt, hasonlítsa össze az OpenVPN-exportot az eredetivel, ellenőrizze a hookokat és útvonalakat a WireGuard oldalán, tiltsa le minden második tulajdonost, majd újraindítás után ellenőrizze a névfeloldást és az útvonaltáblát. Ha egy kapcsolat mindezt kiállja, a profilt indító fájl visszakerülhet a védett tárolóba.