NetworkManager-ի ներմուծումը ձախողվում է OpenVPN և WireGuard ֆայլերի դեպքում

GNOME-ի կարգավորումներում Ներմուծել ֆայլից… ընտրեցի, ընտրեցի պրոֆիլ, որը աշխատում է մատակարարի հաճախորդի հետ, և երկխոսությունը փակվեց՝ ցանկին ոչինչ չավելացնելով։ Երկրորդ նոթբուքում ներմուծումն ավարտվեց, կապը հայտնվեց պրոֆիլի անունով, և հետո այն ձախողվեց առաջին նույնականացման հարցման ժամանակ։ NetworkManager-ը երբեք չի գործարկում ձեր .ovpn կամ wg-quick ֆայլը այնպես, ինչպես կա։ Այն ֆայլը հանձնում է վերլուծիչին, վերլուծիչը այն վերածում է NetworkManager-ի սեփական կապի ձևաչափի, և այդ պահից թունելը կառուցվում է այդ վերլուծված օբյեկտից՝ գաղտնիքներ, երթուղիներ, DNS և մնացած ամեն ինչ։ Ուստի օգտակար հարցը ոչ թե այն է, թե ինչու է ֆայլը կոտրված, այլ արդյոք վերլուծությունը տեղի է ունեցել և ինչ է պահպանել։

Ինչ է իրականում անում ներմուծումը ֆայլի հետ

OpenVPN-ի համար վերլուծիչը ապրում է փլագինի փաթեթում, և ստեղծված կապը ցույց է տալիս D-Bus ծառայության, ինչպիսին է org.freedesktop.NetworkManager.openvpn։ Փլագին չկա՝ վերլուծիչ չկա. տիպը անհայտ է nmcli-ի համար, և VPN ավելացնելու գրաֆիկական ցանկը կարող է ընդհանրապես ներմուծման գրառում չցուցադրել։ WireGuard-ը տարբերվում է մեկ կարևոր կետով՝ NetworkManager-ը 1.30 շարքից ի վեր ունի իր սեփական WireGuard կարգավորումները, ուստի առանձին փլագին փաթեթ չկա, բայց wg-quick ընթերցիչը գոյություն ունի միայն այն կառուցումներում, որոնք այն մատակարարում են։

Ամեն դեպքում ֆայլը կարդացվում է մեկ անգամ։ Արդյունքը գրվում է որպես keyfile /etc/NetworkManager/system-connections/-ում, անվանված կապի անունով, պատկանում է root-ին և անընթեռնելի է այլ օգտվողների համար, քանի որ պարունակում է բանալու նյութը։ Այդ keyfile-ն այժմ կապն է. սկզբնական .ovpn-ը հետագայում խմբագրելը ոչինչ չի փոխում։

Երեք ախտանիշ պատկանում են երեք տարբեր փուլերի։ Ներմուծման գրառման բացակայությունը կամ անհայտ տիպը նշանակում է, որ փլագինը կամ տարբերակը բացակայում է։ Դիրեկտիվա անվանող ներմուծման սխալը նշանակում է, որ վերլուծիչը կարդացել է ֆայլը և մերժել դրա մի մասը։ Գոյություն ունեցող, բայց երբեք չակտիվացող կապը նշանակում է, որ վերլուծված օբյեկտը թերի է կամ սերվերը մերժում է այն։ Որոշեք, թե երեք դեպքերից որն ունեք, նախքան որևէ բան խմբագրելը։

Հաստատեք փլագինը, նախքան պրոֆիլը վրիպազերծելը

Բացակայող փլագինը ճիշտ վնասված պրոֆիլի տեսք ունի, ուստի նախ ստուգեք փաթեթը։ Debian-ում և Ubuntu-ում OpenVPN աջակցությունը գալիս է որպես network-manager-openvpn՝ գումարած աշխատասեղանի օգնական. Fedora-ում փաթեթներն են NetworkManager-openvpn և NetworkManager-openvpn-gnome. Arch-ում դա networkmanager-openvpn-ն է։

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

Այնուհետև ներմուծեք բացարձակ ուղուց՝ nmcli connection import type openvpn file /home/you/profile.ovpn։ Հարաբերական ուղիները սովորաբար աշխատում են, բայց գրացուցակը փոխած shell-ը արագ ներմուծումը վերածում է շրջանցիկ ճանապարհի։ WireGuard-ի համար ստուգեք nmcli --version-ը և համոզվեք, որ միջուկի կողմը գոյություն ունի modprobe wireguard-ով. ներմուծումը, որը հաջողվում է առանց մոդուլի մեքենայում, ձեզ թողնում է կապ, որի սարքը երբեք չի հայտնվում։ nmcli տեղեկատուն փաստաթղթավորում է import ենթահրամանը և ընդունելի տիպերի անունները։ Եթե type wireguard-ը անմիջապես մերժվում է, կառուցումը ավելի հին է, քան այդ ֆունկցիան, և ճիշտ քայլը դիստրիբյուտիվ փաթեթը կամ backport-ն է, այլ ոչ թե կոնֆիգուրացիան կամայական գրացուցակ պատճենելը՝ հույսով, որ ինչ-որ բան այն կկարդա։

Կարդացեք OpenVPN կապը, ոչ թե .ovpn-ը

Երբ կապը գոյություն ունի, կարդացեք վերլուծված կարգավորումները՝ ֆայլը նորից կարդալու փոխարեն. nmcli connection show "Work VPN" | grep -E '^vpn\.'։ Ձեզ պետք են remote-ը և պորտը, տրանսպորտը, նույնականացման նյութը՝ ca, cert, key, tls-auth կամ tls-crypt, և նույնականացման մեթոդը։ Մասնավոր բանալու գաղտնաբառով պրոֆիլում ավելացրեք sudo nmcli --show-secrets connection show "Work VPN"-ը և նայեք secret դրոշներին. 0-ը none է, ուստի գաղտնիքը keyfile-ում է. 1-ը agent-owned է. 2-ը not-saved է, այսինքն՝ այն երբեք չի գրվում keyfile-ում. 4-ը not-required է, այսինքն՝ գաղտնիք ընդհանրապես պետք չէ։ Դրանք բիթեր են, ոչ սանդղակ, ուստի 3-ը պարզապես agent-owned գումարած not-saved է։ Գաղտնիքը, որը հարցնում են մեկ անգամ նստաշրջանում, agent-owned (1) է, ընդ որում՝ այն հարցնում է գործակալը. դրա համար առանձին դրոշի համար գոյություն չունի։ Դրոշների անհամապատասխանությունը սովորական պատճառն է, թե ինչու պրոֆիլը միանում է աշխատասեղանի ապլետից և ձախողվում է սկրիպտից կամ բեռնման ժամանակ։

Ամենաարագ ճանապարհը տեսնելու, թե ինչ է նետել վերլուծիչը, փլագինին խնդրելն է ֆայլը հետ գրել, ապա համեմատել այն. nmcli connection export "Work VPN" /tmp/roundtrip.ovpn։ Այդ diff-ում անհետացող դիրեկտիվները միանալու պահին գոյություն չեն ունենա։ Hook-երը սովորական կասկածյալներն են՝ script-security, up, down և route-up սպասում են բարձրացված իրավունքներով գործարկվող սկրիպտի և դիտավորյալ չեն տեղափոխվում։ Մի իջեցրեք ստուգումը և լրացուցիչ իրավունքներ մի տվեք, որպեսզի ներմուծումը հաջողվի. չաջակցվող ընտրանքը սովորաբար արտացոլում է փլագինի գործառույթների հավաքածուն, ոչ թե անհասանելի սերվերը։ Տեղափոխեք այդ վարքը NetworkManager-ի dispatcher սկրիպտ կամ սերվերի կողմի քաղաքականություն։

Նաև հաստատեք, որ նույնականացման դաշտերը վերապրել են՝ CA հղումը, remote-cert-tls-ը և ցանկացած անվան ստուգում, որի վրա հենվել է պրոֆիլը։ Կապը, որը բարձրանում է առանց դրանց, գուցե խոսում է այն ամենի հետ, ինչ պատասխանում է այդ հասցեում։

Կարդացեք WireGuard կապը, ոչ թե wg-quick ֆայլը

wg-quick ֆայլը shell իմաստաբանությամբ ձևաչափ է. ներմուծված կապը կարգավորումների հավաքածու է։ PrivateKey-ը դառնում է ինտերֆեյսի մասնավոր բանալին, Address-ը դառնում է մեկ կամ մի քանի IPv4 և IPv6 հասցե, DNS-ը քարտեզագրվում է NetworkManager-ի resolver հատկություններին, MTU-ն քարտեզագրվում է wireguard.mtu-ին (wg-quick-ի սեփական լռելյայնը 1420-ն է), և յուրաքանչյուր peer բլոկ դառնում է peer գրառում՝ հանրային բանալիով, endpoint-ով, թույլատրված IP-ներով և persistent keepalive-ով։ Տպեք, թե ինչ է պահվել, nmcli --show-secrets connection show wg0-ով. եթե peer ցանկը չի հայտնվում այդ ելքում, կարդացեք keyfile-ը։

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

Այն, ինչ չի վերապրում, wg-quick-ի shell կեսն է։ PreUp, PostUp, PreDown, PostDown և Table-ը այդ գործիքի վարքն են, ոչ թե WireGuard ինտերֆեյսի ատրիբուտներ, ուստի ներմուծումից հետո դրանք ոչինչ չի գործարկում։ Եթե բնօրինակը օգտագործել է Table = off՝ լռելյայն երթուղին հանգիստ թողնելու համար, նոր NetworkManager թողարկումները նույն նպատակով առաջարկում են ip4-auto-default-route և ip6-auto-default-route. սահմանեք դրանք բացահայտորեն՝ փոխարենը ենթադրելու, որ կապը վարվում է ինչպես սկրիպտը։ Hook-ը, որը հրում էր հատուկ երթուղի, կարիք ունի այդ երթուղու կապի երթուղային կարգավորումներում, այլապես այն պարզապես կբացակայի։

Տվեք կապին ճիշտ մեկ սեփականատեր

Դասական հաջորդ ձախողումը կապն է, որն աշխատում է մինչև հաջորդ բեռնումը և հետո ընկնում ցիկլի մեջ։ Սովորաբար [email protected]-ը դեռ միացված էր նախորդ փորձից, կամ մատակարարի հաճախորդը գործարկում էր իր daemon-ը, և երկու սեփականատեր գրում էին երթուղիներ և DNS նույն նպատակակետի համար. NetworkManager-ը resolver-ը սահմանում է իր ուղով, wg-quick-ը գրում է resolvconf-ի միջոցով, և հաղթում է վերջին գրողը, ուստի անունների լուծումն աշխատում է, հետո դադարում, հետո նորից աշխատում։ Ստուգեք systemctl status wg-quick@wg0, nmcli connection show --active և ip link show type wireguard-ը, ապա անջատեք երկրորդ սեփականատիրոջը՝ նրա metric-ը կարգավորելու փոխարեն։

Եթե ձեզ իսկապես պետք են երկուսը, տվեք նրանց առանձին ինտերֆեյսներ և չհատվող թույլատրված IP-ներ, և թող ճիշտ մեկը տեղադրի լռելյայն երթուղին։ Տարբեր metric-ներով երկու լռելյայն երթուղիներ split tunnel չեն. դա մրցավազք է, որը որոշում է երկրորդը մեկնարկող ծառայությունը։ Եվ վերամիանալուց հետո նորից ստուգեք կիրառված վիճակը. մեկանգամյա ձեռքով resolver-ի ուղղումը, որը գործը լավացնում է, ապացույց չէ, որ ներմուծումը ամբողջական է։

Ստուգեք երթևեկությամբ և վերապրեք վերագործարկումը

Բարձրացրեք կապը nmcli connection up "Work VPN"-ով, ապա կարդացեք վիճակը, հասցեն և երթուղիները՝ պատկերակին վստահելու փոխարեն. nmcli device show wg0 | grep -E 'GENERAL.STATE|IP4.ADDRESS|IP4.ROUTE', ip route show default և թունելի ներսում միայն լուծվող անվան իրական հարցում։ Handshake-ը կամ հաջող ping-ը միայն ապացուցում է, որ գաղտնագրումն աշխատում է. այն ոչինչ չի ասում փոխանցման, split tunnel նախածանցների կամ մասնավոր DNS-ի մասին, և հենց այդ մասերն են սովորաբար կոտրվում։

Ապա վերագործարկեք և կրկնեք։ Autoconnect-ի վարքը, վերանվանված ինտերֆեյսը և սարքից հետո բեռնվող փլագինը բոլորը խափանումներ են, որ տեսնում եք միայն մաքուր բեռնման ժամանակ։ journalctl -u NetworkManager -b --no-pager | tail -n 40-ը ցույց է տալիս, թե ինչ արեց daemon-ը այս կապի հետ այս բեռնման ժամանակ։ Երկրորդ համակարգչի համար պատճենեք keyfile-ը և պահեք այն root-ի սեփականության ներքո 600 ռեժիմով, կամ օգտագործեք nmcli connection export-ը OpenVPN-ի համար և նորից ներմուծեք ստացված .ovpn-ը. արտահանման ուղին WireGuard-ի համարժեք չունի, ուստի այդ ուղղությունը ֆայլի պատճեն է կամ նոր ներմուծում պաշտպանված բնօրինակից։

Կարճ տարբերակը՝ հերթականությամբ. հաստատեք փլագինը կամ NetworkManager-ի տարբերակը, ներմուծեք բացարձակ ուղուց, կարդացեք վերլուծված կարգավորումները՝ ներառյալ secret դրոշները, համեմատեք OpenVPN արտահանումը բնօրինակի հետ, ստուգեք hook-երը և երթուղիները WireGuard-ի կողմում, անջատեք ցանկացած երկրորդ սեփականատեր, ապա վերագործարկումից հետո ստուգեք անվան լուծումը և երթուղիների աղյուսակը։ Երբ կապը անցնում է այս ամենը, այն սկսող պրոֆիլի ֆայլը կարող է վերադառնալ պաշտպանված պահոց։