NetworkManager-import van OpenVPN- en WireGuard-lêers misluk

Ek het Invoer vanaf lêer… in GNOME-instellings gekies, 'n profiel gekies wat met die verskaffer se kliënt werk, en die dialoog het toegemaak sonder om iets by die lys te voeg. Op 'n tweede skootrekenaar het die invoer voltooi, die verbinding het onder die profiel se naam verskyn, en toe het dit by die eerste verifikasieversoek gefaal. NetworkManager voer nooit jou .ovpn- of wg-quick-lêer net so uit nie. Dit gee die lêer aan 'n ontleder, die ontleder skakel dit om na NetworkManager se eie verbindingsformaat, en van daar af word die tonnel uit daardie ontlede objek gebou — geheime, roetes, DNS en alles. Die nuttige vraag is dus nie hoekom die lêer stukkend is nie, maar of die ontleding gebeur het en wat dit behou het.

Wat die invoer werklik met die lêer doen

Vir OpenVPN woon die ontleder in die inprop-pakket, en die verbinding wat dit skep wys na 'n D-Bus-diens soos org.freedesktop.NetworkManager.openvpn. Geen inprop, geen ontleder nie: die tipe is onbekend aan nmcli, en die grafiese lys om 'n VPN by te voeg wys dalk glad geen invoer-inskrywing nie. WireGuard verskil op een belangrike punt — NetworkManager dra sy eie WireGuard-instellings sedert die 1.30-reeks, so daar is geen aparte inprop-pakket nie, maar die wg-quick-leser bestaan net in boue wat dit insluit.

Hoe dit ook al sy, die lêer word een keer gelees. Die resultaat word as 'n sleutellêer onder /etc/NetworkManager/system-connections/ geskryf, vernoem na die verbinding, deur root besit en vir ander gebruikers onleesbaar omdat dit die sleutelmateriaal bevat. Daardie sleutellêer is nou die verbinding; om later die oorspronklike .ovpn te wysig, verander niks.

Drie simptome hoort by drie verskillende fases. Geen invoer-inskrywing of 'n onbekende tipe beteken die inprop of weergawe ontbreek. 'n Invoerfout wat 'n richtlijn noem, beteken die ontleder het die lêer gelees en 'n deel daarvan verwerp. 'n Verbinding wat bestaan maar nooit aktiveer nie, beteken die ontlede objek is onvolledig of die bedienerkant weier dit. Besluit watter een jy het voordat jy enigiets wysig.

Bevestig die inprop voordat jy die profiel ontfout

'n Ontbrekende inprop lyk presies soos 'n korrupte profiel, so kyk eerste na die pakket. Op Debian en Ubuntu word die OpenVPN-ondersteuning as network-manager-openvpn plus 'n lessenaarhelper verskeep; op Fedora is die pakkette NetworkManager-openvpn en NetworkManager-openvpn-gnome; op Arch is dit networkmanager-openvpn.

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

Voer dan vanaf 'n absolute pad in: nmcli connection import type openvpn file /home/you/profile.ovpn. Relatiewe paaie werk gewoonlik, maar 'n dop wat van gids verander het, maak van 'n vinnige invoer 'n ompad. Kyk vir WireGuard na nmcli --version en maak seker die kernkant bestaan met modprobe wireguard; 'n invoer wat op 'n masjien sonder die module slaag, laat jou met 'n verbinding waarvan die toestel nooit verskyn nie. Die nmcli-verwysing dokumenteer die import-subopdrag en die aanvaarde tipe name. As type wireguard botweg verwerp word, is die bou ouer as die funksie, en die regte stap is 'n verspreidingspakket of terugport — nie om die konfigurasie na 'n willekeurige gids te kopieer en te hoop iets lees dit nie.

Lees die OpenVPN-verbinding, nie die .ovpn nie

Sodra die verbinding bestaan, lees die ontlede instellings eerder as om die lêer weer te lees: nmcli connection show "Work VPN" | grep -E '^vpn\.'. Jy wil die remote en poort, die vervoer, die identiteitsmateriaal — ca, cert, key, tls-auth of tls-crypt — en die verifikasiemetode hê. Voeg by 'n profiel met 'n privaatsleutelwagwoord sudo nmcli --show-secrets connection show "Work VPN" by en kyk na die secret flags: 0 is none, so die geheim sit in die sleutellêer; 1 is agent-owned; 2 is not-saved, wat beteken dit word nooit na die sleutellêer geskryf nie; 4 is not-required, wat beteken daar is glad geen geheim nodig nie. Hulle is bisse, nie 'n skaal nie, so 3 is bloot agent-owned plus not-saved. 'n Geheim wat jou een keer per sessie vra, is agent-owned (1) met die agent wat daarvoor vra; daar is geen aparte vlaggetal daarvoor nie. 'n Vlagwantatting is die gewone rede waarom 'n profiel van die lessenaar-applet af verbind en uit 'n script of by die boot faal.

Die vinnigste manier om te sien wat die ontleder laat val het, is om die inprop te vra om die lêer terug te skryf en dit dan te diff: nmcli connection export "Work VPN" /tmp/roundtrip.ovpn. Richtlijnen wat in daardie diff verdwyn, sal nie by verbindingstyd bestaan nie. Hooks is die gewone verdagtes — script-security, up, down en route-up verwag dat 'n script met verhoogde regte loop en word doelbewus nie oorgedra nie. Moet nie die verifikasie verlaag of ekstra regte gee om 'n invoer te laat slaag nie; 'n onondersteunde opsie weerspieël gewoonlik die inprop se funksiestel eerder as 'n onbereikbare bediener. Skuif daardie gedrag na 'n NetworkManager-dispatcher-script of na bedienerkant-beleid.

Bevestig ook dat die identiteitsvelde oorleef het: die CA-verwysing, remote-cert-tls en enige naamkontrole waarop die profiel staatgemaak het. 'n Verbinding wat sonder hulle opkom, praat dalk met wat ook al op daardie adres antwoord.

Lees die WireGuard-verbinding, nie die wg-quick-lêer nie

'n wg-quick-lêer is 'n formaat met dop-semantiek; die ingevoerde verbinding is 'n stel instellings. PrivateKey word die koppelvlak se privaatsleutel, Address word een of meer IPv4- en IPv6-adresse, DNS map na NetworkManager se resolver-eienskappe, MTU map na wireguard.mtu (wg-quick se eie verstek is 1420), en elke peer-blok word 'n peer-inskrywing met publieke sleutel, endpoint, toegelate IP's en persistente keepalive. Druk wat gestoor is met nmcli --show-secrets connection show wg0; as die peer-lys nie in daardie uitset verskyn nie, lees die sleutellêer:

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

Wat nie oorleef nie, is die dop-helfte van wg-quick. PreUp, PostUp, PreDown, PostDown en Table is gedrag van daardie gereedskap, nie eienskappe van 'n WireGuard-koppelvlak nie, so niks voer hulle na 'n invoer uit nie. As die oorspronklike Table = off gebruik het om die verstekroete alleen te laat, bied onlangse NetworkManager-vrystellings ip4-auto-default-route en ip6-auto-default-route vir dieselfde doel; stel hulle eksplisiet in plaas daarvan om te aanvaar die verbinding gedra hom soos die script. 'n Hook wat 'n pasgemaakte roete gestoot het, het daardie roete in die verbinding se routering-instellings nodig, anders sal dit bloot ontbreek.

Gee die verbinding presies een eienaar

Die klassieke opvolgfout is 'n verbinding wat werk tot die volgende boot en dan loop. Gewoonlik was [email protected] nog geaktiveer uit 'n vroeëre eksperiment, of 'n verskaffer-kliënt het sy eie daemon begin, en twee eienaars het roetes en DNS vir dieselfde bestemming geskryf. NetworkManager stel die resolver deur sy eie pad, wg-quick skryf deur resolvconf, en die laaste skrywer wen — so naamoplossing werk, stop, en werk weer. Kyk na systemctl status wg-quick@wg0, nmcli connection show --active en ip link show type wireguard, en deaktiveer dan die tweede eienaar eerder as om aan sy metric te stel.

As jy regtig albei nodig het, gee hulle aparte koppelvlakke en disjunkte toegelate IP's, en laat presies een van hulle die verstekroete installeer. Twee verstekroetes met verskillende metrics is nie 'n split-tonnel nie; dit is 'n wedloop wat beslis word deur watter diens tweede begin. En ondersoek ná 'n herverbinding weer die toegepaste toestand — 'n eenmalige handmatige resolver-wysiging wat dinge laat werk, is nie bewys dat die invoer volledig is nie.

Verifieer met verkeer en oorleef 'n herbegin

Bring die verbinding op met nmcli connection up "Work VPN", en lees dan toestand, adres en roetes eerder as om die ikoon te vertrou: nmcli device show wg0 | grep -E 'GENERAL.STATE|IP4.ADDRESS|IP4.ROUTE', ip route show default, en 'n werklike opsoek van 'n naam wat net binne die tonnel oplos. 'n Handdruk of 'n suksesvolle ping bewys net dat die kripto werk; dit sê niks oor aanstuur, split-tonnel-voorvoegsels of private DNS nie, en dit is die dele wat gewoonlik breek.

Herbegin dan en herhaal dit. Autoconnect-gedrag, 'n herbenoemde koppelvlak en 'n inprop wat ná die toestel laai, is almal foute wat jy net op 'n vars boot sien. journalctl -u NetworkManager -b --no-pager | tail -n 40 wys wat die daemon in hierdie boot met hierdie verbinding gedoen het. Vir 'n tweede lessenaar, kopieer die sleutellêer en hou dit in root-besit met modus 600, of gebruik nmcli connection export vir OpenVPN en voer die resulterende .ovpn weer in — die uitvoerpad het geen WireGuard-ekwivalent nie, so daardie rigting is 'n lêerkopie of 'n vars invoer uit die beskermde oorspronklike.

Kort weergawe, in volgorde: bevestig die inprop- of NetworkManager-weergawe, voer vanaf 'n absolute pad in, lees die ontlede instellings insluitend secret flags, diff die OpenVPN-uitvoer teen die oorspronklike, kyk na hooks en roetes aan die WireGuard-kant, deaktiveer enige tweede eienaar, en verifieer dan ná 'n herbegin 'n naamopsoek en die roetetabel. Sodra 'n verbinding dit alles deurstaan, kan die profiellêer wat dit begin het terug na beskermde berging.