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-ის მხარეს, გამორთეთ ნებისმიერი მეორე მფლობელი, და შემდეგ გადატვირთვის შემდეგ დაადასტურეთ სახელის გარჩევა და მარშრუტების ცხრილი. როცა კავშირი ყველა ამას გაივლის, პროფილის ფაილი, რომელმაც ის დაიწყო, შეიძლება დაცულ საცავში დაბრუნდეს.