Innflutningur í NetworkManager mistekst með OpenVPN og WireGuard skrám
Yfirleitt brotnar þáttarinn, ekki sniðið. Athugaðu viðbótina, lestu innfluttu tenginguna, lagaðu secret-flöggin og leiðirnar og prófaðu svo endurræsingu.
Ég valdi Flytja inn frá skrá… í GNOME-stillingum, valdi snið sem virkar með biðlara þjónustuaðilans, og glugginn lokaðist án þess að bæta neinu við listann. Á annarri fartölvu kláraðist innflutningurinn, tengingin birtist undir nafni sniðsins og síðan mistókst hún við fyrstu auðkenningarbeiðnina. NetworkManager keyrir aldrei .ovpn- eða wg-quick-skrána þína eins og hún er. Það sendir skrána til þáttara, þáttarinn breytir henni í eigið tengingarsnið NetworkManager og héðan í frá er göngin byggð úr þessum þáttaða hlut — leyndarmál, leiðir, DNS og allt annað. Þannig að gagnlega spurningin er ekki hvers vegna skráin er skemmd, heldur hvort þáttunin átti sér stað og hvað hún hélt.
Hvað innflutningurinn gerir í raun við skrána
Fyrir OpenVPN, býr þáttarinn í viðbótarpakkanum, og tengingin sem hann býr til vísar á D-Bus-þjónustu eins og org.freedesktop.NetworkManager.openvpn. Engin viðbót, enginn þáttari: tegundin er óþekkt fyrir nmcli, og myndræni listinn til að bæta við VPN sýnir kannski alls enga innflutningsfærslu. WireGuard er frábrugðið að einu mikilvægu leyti — NetworkManager hefur haft sínar eigin WireGuard-stillingar frá 1.30-seríunni, svo það er ekki sérstakur viðbótarpakki, en wg-quick-lesarinn er aðeins í byggingum sem senda hann með.
Hvort sem er er skráin lesin einu sinni. Niðurstaðan er skrifuð sem keyfile undir /etc/NetworkManager/system-connections/, nefnd eftir tengingunni, í eigu root og ólæsileg öðrum notendum því hún geymir lykliefnið. Þessi keyfile er nú tengingin; að breyta upprunalegu .ovpn síðar breytir engu.
Þrjú einkenni tilheyra þremur mismunandi stigum. Engin innflutningsfærsla eða óþekkt tegund þýðir að viðbótin eða útgáfan vantar. Innflutningsvilla sem nefnir tilskipun þýðir að þáttarinn las skrána og hafnaði hluta hennar. Tenging sem er til en virkjast aldrei þýðir að þáttaði hluturinn er ófullnægjandi eða að þjónninn hafnar henni. Ákveddu hvor tilvikanna þú hefur áður en þú breytir einhverju.
Staðfestu viðbótina áður en þú kembir sniðið
Vantar viðbót lítur nákvæmlega út eins og skemmt snið, svo athugaðu pakkann fyrst. Á Debian og Ubuntu er OpenVPN-stuðningur sendur sem network-manager-openvpn auk skjáborðsaðstoðar; á Fedora eru pakkarnir NetworkManager-openvpn og NetworkManager-openvpn-gnome; á Arch er það networkmanager-openvpn.
dpkg -l network-manager-openvpn-gnome | tail -n 2 rpm -q NetworkManager-openvpn pacman -Q networkmanager-openvpn
Flyttu svo inn frá algerri slóð: nmcli connection import type openvpn file /home/you/profile.ovpn. Tiltölulegar slóðir virka venjulega, en skel sem hefur skipt um möppu gerir fljótlegan innflutning að krókaleið. Fyrir WireGuard skaltu athuga nmcli --version og ganga úr skugga um að kjarnahliðin sé til með modprobe wireguard; innflutningur sem heppnast á vél án einingarinnar skilur þig eftir með tengingu þar sem tækið birtist aldrei. nmcli-tilvísun skjalfestir undirskipunina import og samþykkt tegundanöfn. Ef type wireguard er hafnað beint er byggingin eldri en eiginleikinn, og rétta skrefið er dreifingarpakki eða backport — ekki að afrita stillinguna í handahófskennda möppu og vona að eitthvað lesi hana.
Lestu OpenVPN-tenginguna, ekki .ovpn
Þegar tengingin er til skaltu lesa þáttuðu stillingarnar í stað þess að lesa skrána aftur: nmcli connection show "Work VPN" | grep -E '^vpn\.'. Þú vilt remote og portið, flutninginn, auðkennisefnið — ca, cert, key, tls-auth eða tls-crypt — og auðkenningaraðferðina. Á sniði með lykilorði fyrir einkalykil skaltu bæta við sudo nmcli --show-secrets connection show "Work VPN" og skoða secret-flöggin: 0 er none, svo leyndarmálið liggur í keyfile; 1 er agent-owned; 2 er not-saved, sem þýðir að það er aldrei skrifað í keyfile; 4 er not-required, sem þýðir að ekkert leyndarmál er nauðsynlegt. Þetta eru bitar, ekki kvarði, svo 3 er einfaldlega agent-owned plús not-saved. Leyndarmál sem spyr einu sinni á hverri lotu er agent-owned (1), þar sem agentinn biður um það; ekkert sérstakt flaggnúmer er til fyrir það. Misræmi í flöggum er venjulega ástæðan fyrir því að snið tengist frá skjáborðsforritinu og mistekst frá skriftu eða við ræsingu.
Fljótlegasta leiðin til að sjá hvað þáttarinn sleppti er að biðja viðbótina að skrifa skrána aftur og bera hana svo saman: nmcli connection export "Work VPN" /tmp/roundtrip.ovpn. Tilskipanir sem hverfa í þeim samanburði munu ekki vera til við tengingu. Hookar eru venjulegu grunsemdirnar — script-security, up, down og route-up gera ráð fyrir skriftu sem keyrð er með auknum réttindum og er vísvitandi ekki flutt. Ekki lækka sannprófunina og ekki veita aukaréttindi til að láta innflutning heppnast; óstudd valkostur endurspeglar venjulega eiginleika viðbótarinnar en ekki óaðgengilegan þjón. Færðu þá hegðun í NetworkManager-dispatcher-skriftu eða í stefnu á þjónshlið.
Staðfestu líka að auðkennisreitirnir hafi lifað af: CA-tilvísunin, remote-cert-tls og hver sú nafnaprófun sem sniðið treysti á. Tenging sem kemst upp án þeirra talar kannski við hvað sem svarar á þeirri slóð.
Lestu WireGuard-tenginguna, ekki wg-quick-skrána
wg-quick-skrá er snið með skeljarmerkingum; innflutta tengingin er mengi stillinga. PrivateKey verður einkalykill viðmótsins, Address verður eitt eða fleiri IPv4- og IPv6-vistföng, DNS varpast á resolver-eiginleika NetworkManager, MTU varpast á wireguard.mtu (eigið sjálfgefið gildi wg-quick er 1420), og hver peer-blokk verður peer-færsla með opinberum lykli, endpoint, leyfðum IP og persistent keepalive. Prentaðu það sem vistað var með nmcli --show-secrets connection show wg0; ef peer-listinn birtist ekki í þeirri úttak skaltu lesa keyfile:
sudo sed -n '/^\[wireguard\]/,/^\[/p' /etc/NetworkManager/system-connections/wg0.nmconnection
Það sem lifir ekki af er skeljarhelmingur wg-quick. PreUp, PostUp, PreDown, PostDown og Table eru hegðun þess tóls, ekki eiginleikar WireGuard-viðmóts, svo ekkert keyrir þau eftir innflutning. Ef upprunalega notaði Table = off til að láta sjálfgefnu leiðina í friði bjóða nýrri NetworkManager-útgáfur ip4-auto-default-route og ip6-auto-default-route í sama tilgangi; stilltu þau skýrt í stað þess að gera ráð fyrir að tengingin hagi sér eins og skriftan. Hook sem ýtti sérsniðinni leið þarf þá leið í leiðarstillingum tengingarinnar, annars vantar hana einfaldlega.
Gefðu tengingunni nákvæmlega einn eiganda
Klassíska eftirköstin er tenging sem virkar þar til næstu ræsingar og fer svo í lykkju. Venjulega var [email protected] enn virkt frá fyrra tilrauni, eða biðlari þjónustuaðilans ræsti sinn eigin daemon, og tveir eigendur skrifuðu leiðir og DNS fyrir sama áfangastað. NetworkManager setur resolverinn eftir sinni eigin leið, wg-quick skrifar í gegnum resolvconf, og síðasti skrifandinn vinnur — svo nafnaupplausn virkar, stöðvast svo, og virkar svo aftur. Athugaðu systemctl status wg-quick@wg0, nmcli connection show --active og ip link show type wireguard og slökktu svo á öðrum eigandanum í stað þess að stilla metric hans.
Ef þú þarft virkilega báða skaltu gefa þeim aðskilin viðmót og aðskilin leyfð IP og láta nákvæmlega annan þeirra setja upp sjálfgefnu leiðina. Tvær sjálfgefna leiðir með mismunandi metric eru ekki split tunnel; það er kapphlaup sem þjónustan sem ræsist önnur ræður. Og eftir endurtengingu skaltu skoða notað ástand aftur — einstök handvirk resolver-breyting sem lætur hlutina virka er ekki sönnun þess að innflutningnum sé lokið.
Sannprófaðu með umferð og lifðu endurræsingu af
Ræstu tenginguna með nmcli connection up "Work VPN" og lestu svo ástand, vistfang og leiðir í stað þess að treysta tákngerðinni: nmcli device show wg0 | grep -E 'GENERAL.STATE|IP4.ADDRESS|IP4.ROUTE', ip route show default og raunveruleg uppfletting á nafni sem leysist aðeins inni í göngunum. Handshake eða árangursríkt ping sannar aðeins að dulritunin virki; það segir ekkert um framsendingu, split tunnel forskeyti eða einka-DNS, og það eru hlutarnir sem venjulega brotna.
Endurræstu svo og endurtaktu. Autoconnect-hegðun, endurnefnt viðmót og viðbót sem hleðst eftir tækið eru allt bilanir sem þú sérð aðeins við hreina ræsingu. journalctl -u NetworkManager -b --no-pager | tail -n 40 sýnir hvað daemoninn gerði við þessa tengingu í þessari ræsingu. Fyrir aðra tölvu skaltu afrita keyfile og halda honum í eigu root með ham 600, eða nota nmcli connection export fyrir OpenVPN og flytja inn .ovpn sem verður til aftur — útflutningsleiðin hefur ekkert WireGuard-ígildi, svo sú átt er skráarafrit eða nýr innflutningur frá hinu varða upprunalega.
Stutta útgáfan, í röð: staðfestu viðbótina eða NetworkManager-útgáfuna, flyttu inn frá algerri slóð, lestu þáttuðu stillingarnar þar á meðal secret-flöggin, berðu OpenVPN-útflutninginn saman við upprunalega, athugaðu hooka og leiðir á WireGuard-hlið, slökktu á hverjum öðrum eiganda og sannprófaðu svo eftir endurræsingu nafnaupplausn og leiðartöfluna. Þegar tenging stenst allt þetta getur sniðskráin sem hóf hana farið aftur í varða geymslu.