NetworkManager-ymport fan OpenVPN- en WireGuard-bestannen mislearret

Ik keas Ymportearje út bestân… yn GNOME-ynstellingen, keas in profile dat mei de client fan de leveransier wurket, en de dialooch sleat sûnder eat oan de list ta te foegjen. Op in twadde laptop wie de ymport foltôge, ferskynde de ferbining ûnder de namme fan it profile, en doe mislearre se by de earste autentikaasje-freeg. NetworkManager fiert jo .ovpn- of wg-quick-bestân nea sa út. It jout it bestân oan in parser, de parser set it om yn NetworkManager syn eigen ferbiningsformaat, en fan dat stuit ôf wurdt de tunnel boud út dat parsde objekt — geheimen, rûtes, DNS en alles. De nuttige fraach is dus net wêrom't it bestân stikken is, mar oft it parsen bard is en wat it bewarre hat.

Wat de ymport eins mei it bestân docht

Foar OpenVPN wennet de parser yn it plugin-pakket, en de ferbining dy't er makket wiist nei in D-Bus-tsjinst lykas org.freedesktop.NetworkManager.openvpn. Gjin plugin, gjin parser: it type is ûnbekend foar nmcli, en de grafyske list om in VPN ta te foegjen lit miskien hielendal gjin ymport-yngong sjen. WireGuard ferskilt op ien wichtich punt — NetworkManager hat sûnt de 1.30-rige syn eigen WireGuard-ynstellingen, dus der is gjin apart plugin-pakket, mar de wg-quick-lêzer bestiet allinnich yn builds dy't him meileverje.

Hoe dan ek, it bestân wurdt ien kear lêzen. It resultaat wurdt as keyfile ûnder /etc/NetworkManager/system-connections/ skreaun, neamd nei de ferbining, eigendom fan root en ûnlêsber foar oare brûkers om't it it kaaimateriaal befettet. Dy keyfile is no de ferbining; it letter bewurkjen fan it oarspronklike .ovpn feroaret neat.

Trije symptomen hearre by trije ferskillende fazen. Gjin ymport-yngong of in ûnbekend type betsjut dat de plugin of ferzje ûntbrekt. In ymportflater dy't in rjochtline neamt betsjut dat de parser it bestân lêzen hat en in part derfan wegere hat. In ferbining dy't bestiet mar nea aktivearret betsjut dat it parsde objekt ûnfolslein is of dat de serverkant it wegeret. Beslis hokker gefal jo hawwe foardat jo eat bewurkje.

Kontrolearje de plugin foardat jo it profile debugge

In ûntbrekkende plugin liket krekt as in skansearre profile, dus kontrolearje earst it pakket. Op Debian en Ubuntu wurdt de OpenVPN-stipe levere as network-manager-openvpn plus in desktop-helper; op Fedora binne dat de pakketten NetworkManager-openvpn en NetworkManager-openvpn-gnome; op Arch is it networkmanager-openvpn.

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

Ymportearje dan fan in absolút paad: nmcli connection import type openvpn file /home/you/profile.ovpn. Relative paden wurkje meast, mar in shell dy't fan map feroare is makket fan in flugge ymport in omwei. Kontrolearje foar WireGuard nmcli --version en soargje dat de kernkant bestiet mei modprobe wireguard; in ymport dy't slagget op in masine sûnder de module lit jo efter mei in ferbining wêrfan't it apparaat nea ferskynt. De nmcli-referinsje dokumintearret it subkommando import en de akseptearre typenammen. Wurdt type wireguard bot wegere, dan is de build âlder as de funksje, en de juste stap is in distribúsjepakket of in backport — net de konfiguraasje nei in willekeurige map kopiearje en hoopje dat eat it lêst.

Lês de OpenVPN-ferbining, net de .ovpn

Sadra't de ferbining bestiet, lês de parsde ynstellingen ynstee fan it bestân opnij: nmcli connection show "Work VPN" | grep -E '^vpn\.'. Jo wolle de remote en poarte, it transport, it identiteitsmateriaal — ca, cert, key, tls-auth of tls-crypt — en de autentikaasjemetoade. Foegje by in profile mei in wachtwurd foar de privekaai sudo nmcli --show-secrets connection show "Work VPN" ta en sjoch nei de secret flags: 0 is none, dus it geheim sit yn 'e keyfile; 1 is agent-owned; 2 is not-saved, wat betsjuttet dat it nea nei de keyfile skreaun wurdt; 4 is not-required, wat betsjuttet dat der hielendal gjin geheim nedich is. It binne bits, gjin skaal, dus 3 is gewoan agent-owned plus not-saved. In geheim dat jo ien kear per sesje freget is agent-owned (1) wêrby't de agent derom freget; dêrfoar is gjin apart flaggenûmer. In flag-mismatch is de gewoane reden dat in profile fan 'e desktop-applet ôf ferbynt en fan in script of by it opstarten faalt.

De fluchste manier om te sjen wat de parser falle litten hat, is de plugin freegje it bestân werom te skriuwen en it dan te diffen: nmcli connection export "Work VPN" /tmp/roundtrip.ovpn. Rjochtlinen dy't yn dy diff ferdwine, sille op ferbiningstiid net bestean. Hooks binne de gewoane fertochten — script-security, up, down en route-up ferwachtsje in script dat mei ferhege rjochten rint en wurde bewust net oernommen. Ferleegje de ferifikaasje net en jou gjin ekstra rjochten om in ymport slagje te litten; in net-stipe opsje wjerspegelt meast de funksjeset fan 'e plugin ynstee fan in ûnberikbere server. Ferpleats dat gedrach nei in NetworkManager-dispatcher-script of nei belied oan 'e serverkant.

Kontrolearje ek oft de identiteitsfjilden it oerlibbe hawwe: de CA-referinsje, remote-cert-tls en elke nammerkontrôle dêr't it profile op boude. In ferbining dy't sûnder dy dingen omheech komt, praat miskien mei wat der op dat adres antwurdet.

Lês de WireGuard-ferbining, net it wg-quick-bestân

In wg-quick-bestân is in formaat mei shell-semantyk; de ymporteare ferbining is in set ynstellingen. PrivateKey wurdt de privekaai fan it ynterface, Address wurdt ien of mear IPv4- en IPv6-adressen, DNS mapt op NetworkManager syn resolver-eigenskippen, MTU mapt op wireguard.mtu (de eigen standert fan wg-quick is 1420), en elk peer-blok wurdt in peer-yngong mei publike kaai, endpoint, tasteane IP's en persistinte keepalive. Printsje wat opslein is mei nmcli --show-secrets connection show wg0; ferskynt de peer-list net yn dy útfier, lês dan de keyfile:

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

Wat net oerlibbet is de shell-helte fan wg-quick. PreUp, PostUp, PreDown, PostDown en Table binne gedrach fan dat ark, gjin attributen fan in WireGuard-ynterface, dus neat fiert se nei in ymport út. As it orizjineel Table = off brûkte om de standertrûte mei rêst te litten, biede resinte NetworkManager-releases ip4-auto-default-route en ip6-auto-default-route foar itselde doel; set se eksplisyt ynstee fan oan te nimmen dat de ferbining him as it script hâldt en draacht. In hook dy't in oanpaste rûte treau hat dy rûte nedich yn 'e routeringsynstellingen fan 'e ferbining, oars sil it gewoan ûntbrekke.

Jou de ferbining krekt ien eigner

De klassike ferfolchflater is in ferbining dy't wurket oant de folgjende boot en dan yn in lus rekket. Meast wie [email protected] noch ynskeakele út in earder eksperimint, of in leveransier-client starte syn eigen daemon, en twa eigners skreaunen rûtes en DNS foar deselde bestimming. NetworkManager set de resolver fia syn eigen paad, wg-quick skriuwt fia resolvconf, en de lêste skriuwer wint — dus nammeresolúsje wurket, stoppet, en wurket wer. Kontrolearje systemctl status wg-quick@wg0, nmcli connection show --active en ip link show type wireguard, en skeakelje dan de twadde eigner út ynstee fan oan syn metric te draaien.

As jo echt beide nedich hawwe, jou har aparte ynterfaces en disjunkte tasteane IP's, en lit krekt ien fan har de standertrûte ynstallearje. Twa standertrûtes mei ferskillende metrics is gjin split-tunnel; it is in wedstriid dy't beslist wurdt troch hokker tsjinst as twadde start. En besjoch nei in werferbining de tapaste steat opnij — in ienmalige manuele resolver-bewurking dy't dingen wurkje lit is gjin bewiis dat de ymport folslein is.

Ferifiearje mei ferkear en oerlibje in reboot

Bring de ferbining omheech mei nmcli connection up "Work VPN", en lês dan steat, adres en rûtes ynstee fan it byldsje te fertrouwen: nmcli device show wg0 | grep -E 'GENERAL.STATE|IP4.ADDRESS|IP4.ROUTE', ip route show default, en in echte opfrege fan in namme dy't allinnich binnen de tunnel resolvet. In handshake of in slagge ping bewissiget allinnich dat de krypto wurket; it seit neat oer trochstjoeren, split-tunnel-prefixen of prive-DNS, en dat binne de dielen dy't meast brekke.

Reboot dan en werhelje it. Autoconnect-gedrach, in werneamd ynterface en in plugin dy't nei it apparaat laden wurdt binne allegear flaters dy't jo allinnich by in farske boot sjogge. journalctl -u NetworkManager -b --no-pager | tail -n 40 lit sjen wat de daemon yn dizze boot mei dizze ferbining dien hat. Kopiearje foar in twadde desktop de keyfile en hâld him yn root-eigendom mei modus 600, of brûk nmcli connection export foar OpenVPN en ymportearje de resultearjende .ovpn opnij — it eksportpaad hat gjin WireGuard-ekwivalent, dus dy rjochting is in bestânskopy of in farske ymport út it beskerme orizjineel.

Koarte ferzje, yn folchoarder: befêstigje de plugin- of NetworkManager-ferzje, ymportearje fan in absolút paad, lês de parsde ynstellingen ynklusyf secret flags, diff de OpenVPN-eksport tsjin it orizjineel, kontrolearje hooks en rûtes oan 'e WireGuard-kant, skeakelje elke twadde eigner út, en ferifiearje dan nei in reboot in namme-opfrege en de rûtetabel. As in ferbining dat allegear trochstiet, kin it profilebestân dat it begon werom nei beskerme opslach.