Importi në NetworkManager dështon me skedarët OpenVPN dhe WireGuard

Zgjodha Importo nga skedari… në Cilësimet e GNOME, zgjodha një profil që funksionon me klientin e ofruesit, dhe dialogu u mbyll pa shtuar asgjë në listë. Në një laptop të dytë importi përfundoi, lidhja u shfaq me emrin e profilit dhe më pas dështoi në kërkesën e parë të vërtetimit. NetworkManager nuk e ekzekuton kurrë skedarin tuaj .ovpn ose wg-quick ashtu siç është. Ia dorëzon skedarin një analizuesi, analizuesi e kthen atë në formatin e vet të lidhjes së NetworkManager, dhe që nga ai moment tuneli ndërtohet nga ai objekt i analizuar — sekretet, rrugët, DNS dhe gjithçka tjetër. Pra pyetja e dobishme nuk është pse skedari është i dëmtuar, por nëse analiza ndodhi dhe çfarë mbajti.

Çfarë bën importi në të vërtetë me skedarin

Për OpenVPN, analizuesi jeton në paketën e shtojcës, dhe lidhja që krijon tregon drejt një shërbimi D-Bus si org.freedesktop.NetworkManager.openvpn. Pa shtojcë, pa analizues: lloji është i panjohur për nmcli, dhe lista grafike e shtimit të VPN-së mund të mos shfaqë fare zë importi. WireGuard ndryshon në një pikë të rëndësishme — NetworkManager ka cilësimet e veta të WireGuard që nga seria 1.30, ndaj nuk ka paketë të veçantë shtojce, por lexuesi i wg-quick ekziston vetëm në ndërtimet që e sjellin atë.

Në çdo rast, skedari lexohet një herë. Rezultati shkruhet si keyfile nën /etc/NetworkManager/system-connections/, emërohet sipas lidhjes, zotërohet nga root dhe është i palexueshëm për përdoruesit e tjerë sepse mban materialin e çelësave. Ai keyfile është tani lidhja; redaktimi i skedarit origjinal .ovpn më pas nuk ndryshon asgjë.

Tre simptoma u përkasin tre fazave të ndryshme. Mungesa e zërit të importit ose një lloj i panjohur do të thotë që mungon shtojca ose versioni. Një gabim importi që emërton një direktivë do të thotë që analizuesi lexoi skedarin dhe refuzoi një pjesë të tij. Një lidhje që ekziston por nuk aktivizohet kurrë do të thotë që objekti i analizuar është i paplotë ose serveri po e refuzon. Vendos cila nga tri rastet është e jotja përpara se të redaktosh gjithçka.

Konfirmo shtojcën përpara se të korrigjosh profilin

Një shtojcë që mungon duket saktësisht si një profil i dëmtuar, ndaj kontrollo fillimisht paketën. Në Debian dhe Ubuntu mbështetja e OpenVPN vjen si network-manager-openvpn plus një ndihmës desktopi; në Fedora paketat janë NetworkManager-openvpn dhe NetworkManager-openvpn-gnome; në Arch është networkmanager-openvpn.

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

Pastaj importo nga një shteg absolut: nmcli connection import type openvpn file /home/you/profile.ovpn. Shtigjet relative zakonisht funksionojnë, por një shell që ka ndërruar drejtori e kthen një import të shpejtë në rrugë të gjatë. Për WireGuard kontrollo nmcli --version dhe sigurohu që ana e kernelit ekziston me modprobe wireguard; një import që ka sukses në një makinë pa modulin të lë me një lidhje pajisja e së cilës nuk shfaqet kurrë. referenca e nmcli dokumenton nënkomandën import dhe emrat e llojeve të pranuara. Nëse type wireguard refuzohet menjëherë, ndërtimi është më i vjetër se kjo veçori, dhe hapi i duhur është një paketë e shpërndarjes ose një backport — jo kopjimi i konfigurimit në një drejtori arbitrare me shpresën se diçka do ta lexojë.

Lexo lidhjen e OpenVPN, jo .ovpn

Kur lidhja ekziston, lexo cilësimet e analizuara në vend që ta rilexosh skedarin: nmcli connection show "Work VPN" | grep -E '^vpn\.'. Të duhen remote dhe porta, transporti, materiali i identitetit — ca, cert, key, tls-auth ose tls-crypt — dhe metoda e vërtetimit. Në një profil me fjalëkalim të çelësit privat, shto sudo nmcli --show-secrets connection show "Work VPN" dhe shiko secret flags: 0 është none, pra sekreti ndodhet në keyfile; 1 është agent-owned; 2 është not-saved, që do të thotë se nuk shkruhet kurrë në keyfile; 4 është not-required, që do të thotë se nuk nevojitet fare sekret. Janë bit, jo shkallë, ndaj 3 është thjesht agent-owned plus not-saved. Një sekret që pyet një herë për sesion është agent-owned (1), me agjentin që e kërkon; nuk ka numër të veçantë flagu për këtë. Mospërputhja e flagve është arsyeja e zakonshme që një profil lidhet nga applet-i i desktopit dhe dështon nga një skript ose në nisje.

Mënyra më e shpejtë për të parë çfarë hodhi analizuesi është t'i kërkosh shtojcës ta shkruajë skedarin përsëri dhe pastaj ta krahasosh: nmcli connection export "Work VPN" /tmp/roundtrip.ovpn. Direktivat që zhduken në atë diff nuk do të ekzistojnë në kohën e lidhjes. Hook-et janë të dyshuarit e zakonshëm — script-security, up, down dhe route-up presin një skript që ekzekutohet me të drejta të ngritura dhe nuk transferohen qëllimisht. Mos e ul verifikimin dhe mos jep privilegje shtesë që importi të ketë sukses; një opsion i pambështetur zakonisht pasqyron grupin e veçorive të shtojcës dhe jo një server të paarritshëm. Zhvendose atë sjellje në një skript dispatcher të NetworkManager ose në politikë nga ana e serverit.

Konfirmo gjithashtu se fushat e identitetit mbijetuan: referenca e CA, remote-cert-tls dhe çdo kontroll emri ku profili mbështetej. Një lidhje që ngrihet pa to mund të flasë me çfarëdo që përgjigjet në atë adresë.

Lexo lidhjen e WireGuard, jo skedarin wg-quick

Skedari wg-quick është një format me semantikë shell; lidhja e importuar është një grup cilësimesh. PrivateKey bëhet çelësi privat i ndërfaqes, Address bëhet një ose më shumë adresa IPv4 dhe IPv6, DNS mapohet në vetitë resolver të NetworkManager, MTU mapohet në wireguard.mtu (vlera e paracaktuar e vetë wg-quick është 1420), dhe çdo bllok peer bëhet një zë peer me çelës publik, endpoint, IP të lejuara dhe persistent keepalive. Printo çfarë u ruajt me nmcli --show-secrets connection show wg0; nëse lista e peer-ve nuk shfaqet në atë dalje, lexo keyfile:

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

Ajo që nuk mbijeton është gjysma shell e wg-quick. PreUp, PostUp, PreDown, PostDown dhe Table janë sjellje e atij mjeti, jo atribute të një ndërfaqeje WireGuard, ndaj asgjë nuk i ekzekuton pas importit. Nëse origjinali përdorte Table = off për ta lënë rrugën e paracaktuar të qetë, lëshimet e reja të NetworkManager ofrojnë ip4-auto-default-route dhe ip6-auto-default-route për të njëjtin qëllim; vendosi ato në mënyrë eksplicite në vend që të supozosh se lidhja sillet si skripti. Një hook që shtynte një rrugë të personalizuar e ka të nevojshme atë rrugë në cilësimet e rrugëzimit të lidhjes, përndryshe thjesht do të mungojë.

Jepi lidhjes saktësisht një pronar

Dështimi klasik pasardhës është një lidhje që funksionon deri në nisjen tjetër dhe pastaj futet në cikël. Zakonisht [email protected] ishte ende i aktivizuar nga një eksperiment i mëparshëm, ose një klient i ofruesit po niste daemon-in e vet, dhe dy pronarë po shkruanin rrugë dhe DNS për të njëjtin destinacion. NetworkManager e vendos resolverin përmes rrugës së vet, wg-quick shkruan përmes resolvconf, dhe fiton shkruesi i fundit — kështu që zgjidhja e emrave funksionon, pastaj ndalon, pastaj funksionon përsëri. Kontrollo systemctl status wg-quick@wg0, nmcli connection show --active dhe ip link show type wireguard, pastaj çaktivizo pronarin e dytë në vend që të rregullosh metric-un e tij.

Nëse të duhen vërtet të dyja, jepu ndërfaqe të veçanta dhe IP të lejuara të pambivështuara, dhe lëre saktësisht njërin prej tyre të instalojë rrugën e paracaktuar. Dy rrugë të paracaktuara me metric të ndryshme nuk janë split tunnel; është një garë e vendosur nga shërbimi që niset i dyti. Dhe pas një rilidhjeje, inspekto përsëri gjendjen e aplikuar — një redaktim manual i resolverit një herë që i bën gjërat të funksionojnë nuk është provë se importi është i plotë.

Verifiko me trafik dhe mbijeto një rindezje

Ngri lidhjen me nmcli connection up "Work VPN", pastaj lexo gjendjen, adresën dhe rrugët në vend që t'i besosh ikonës: nmcli device show wg0 | grep -E 'GENERAL.STATE|IP4.ADDRESS|IP4.ROUTE', ip route show default dhe një kërkim të vërtetë për një emër që zgjidhet vetëm brenda tunelit. Një handshake ose një ping i suksesshëm provon vetëm se kriptografia funksionon; nuk thotë asgjë për përcjelljen, prefikset e split tunnel ose DNS privat, dhe pikërisht ato pjesë zakonisht thyhen.

Pastaj rindiz dhe përsërit. Sjellja e autoconnect, një ndërfaqe e riemërtuar dhe një shtojcë që ngarkohet pas pajisjes janë të gjitha dështime që i shihni vetëm në një nisje të pastër. journalctl -u NetworkManager -b --no-pager | tail -n 40 tregon çfarë bëri daemon-i me këtë lidhje në këtë nisje. Për një kompjuter të dytë, kopjo keyfile-in dhe mbaje në pronësi të root me modalitetin 600, ose përdor nmcli connection export për OpenVPN dhe riimporto .ovpn që rezulton — rruga e eksportit nuk ka ekuivalent WireGuard, ndaj ai drejtim është kopje skedari ose import i ri nga origjinali i mbrojtur.

Versioni i shkurtër, sipas radhës: konfirmo shtojcën ose versionin e NetworkManager, importo nga një shteg absolut, lexo cilësimet e analizuara duke përfshirë secret flags, krahaso eksportin e OpenVPN me origjinalin, kontrollo hook-et dhe rrugët në anën e WireGuard, çaktivizo çdo pronar të dytë, dhe pastaj pas rindezjes verifiko zgjidhjen e emrave dhe tabelën e rrugëve. Kur një lidhje i kalon të gjitha këto, skedari i profilit që e filloi mund të kthehet në ruajtjen e mbrojtur.