მომწოდებლის VPN აპი NetworkManager-ის წინააღმდეგ: ვის ეკუთვნის მდგომარეობა?
პროფილი ასახელებს დანამატს და არა მომწოდებლის კლიენტის ქცევას. ქსელში მართული ლეპტოპის შეცვლამდე გამოიკვლიეთ, ვის ეკუთვნის რეგისტრაცია, DNS, ბლოკირება და განახლებები.
პროფილის იმპორტი არ არის იგივე, რაც კლიენტის ჩანაცვლება. NetworkManager ინახავს დანამატის ტიპს დანამატისთვის დამახასიათებელ მონაცემებთან და საიდუმლოებებთან ერთად, და სწორედ იმ ტიპის მფლობელი დანამატი წყვეტს, რა შეუძლია კავშირს. ყველაფერი, რასაც მომწოდებლის აპლიკაცია აფენს ზემოდან, რეგისტრაციიდან მუდმივ ბლოკირებამდე, ფაილის გარეთ ცხოვრობს. უსაფრთხოა თუ არა გადართვა, დამოკიდებულია იმაზე, თუ რომელ ფენებს ეყრდნობით სინამდვილეში.
ფაილი ასახელებს დანამატს და არა ფუნქციათა ნაკრებს
NetworkManager-ის VPN-ის პარამეტრების ცნობარი აღწერს მომსახურების ტიპს, რომელიც ირჩევს დანამატს, ამასთან ერთად გაუმჭვირვალე მონაცემთა ლექსიკონს და საიდუმლოებათა ლექსიკონს, რომლებსაც მხოლოდ დანამატი ინტერპრეტირებს. პროფილი ხელშეკრულებაა ერთი რეალიზაციისთვის და არა ქცევის აღწერა, რომლის გამეორებაც ნებისმიერ კლიენტს შეუძლია. ორ კლიენტს შეუძლია იმავე პროტოკოლზე საუბარი და მაინც განსხვავდებოდეს იმაში, თუ რაზე მოლაპარაკებას აწარმოებენ და რომელ მონაცემთა ბილიკებს რთავენ. პროტოკოლის ეტიკეტი გეუბნებათ, რა არის გვირაბი, არასდროს — რას აკეთებს მასთან გარემომცველი კლიენტი.
ამიტომ შეადარეთ მოთხოვნები და არა გარსები. კითხვა არ არის, შეუძლია თუ არა ალტერნატივას დაკავშირება, რადგან ჩვეულებრივ შეუძლია; კითხვა არის, გადარჩება თუ არა გადასვლას ყოველი მოთხოვნა, რომელიც თავდაპირველ კლიენტს მისაღებს ხდიდა. ჩამოწერეთ ეს მოთხოვნები რაიმეს დაყენებამდე, თორემ შედარება გადაიქცევა იმის ნადირობად, რაც პირველი გატყდება.
რას ამატებს მომწოდებლის აპი გვირაბის გარშემო
მომწოდებლის კლიენტები ჩვეულებრივ აერთიანებენ რეგისტრაციას და მოწყობილობის მდგომარეობის შემოწმებებს, მეორე ფაქტორის ნაკადს საკუთარი ინტერფეისით, მუდმივ ბლოკირებას, განახლების არხს და მხარდაჭერის ხელსაწყოებს. ამის ნაწილი პროტოკოლის გვერდით დგას, ნაწილი კი ცალკე პროდუქტია, რომელიც მხოლოდ ინსტალატორს იზიარებს. NetworkManager-ს შეუძლია გვირაბისა და მისი მარშრუტიზაციის ჩანაცვლება, და დისპეტჩერის სკრიპტებს შეუძლიათ მოქმედებების გაშვება, როცა კავშირის მდგომარეობა იცვლება. თუმცა ის არ ამრავლებს ბლოკირების ძრავას, სერტიფიკატის განახლების პროცესს ან ვარაუდს, თუ რომელ მომხმარებელს შეუძლია კავშირის აწევა.
მეტი კომპონენტი არ ნიშნავს უფრო უსაფრთხოს, ნაკლები კი არ ნიშნავს უფრო სუსტს. კითხვა ის არის, რომელი კომპონენტი ახორციელებს იმ პოლიტიკას, რომლის დაცვაც გითხრეს. თუ აუდიტორი იკითხავს, რა ბლოკავს ტრაფიკს, როცა გვირაბი ვარდება, პასუხმა უნდა დაასახელოს რაღაც, რაც ამას ნამდვილად აკეთებს, და მხოლოდ დამაკავშირებელი პროფილი არ არის ეს პასუხი.
სად განსხვავდება საკუთრება სინამდვილეში
წაიკითხეთ ეს როგორც საკუთრების რუკა და არა როგორც სია, რადგან ქვემოთ მოცემული ჩავარდნები საკუთრების ხარვეზებია და კლიენტის კონფიგურაციის არავითარი რაოდენობა არ ხურავს მათ. ყოველი სტრიქონი ასახელებს ფენას, მხარეს, რომელიც დღეს ჩვეულებრივ ფლობს მას, და ადგილს, სადაც ხარვეზი პირველად ჩანს.
| Layer | Vendor application | NetworkManager connection | Where the gap shows up |
|---|---|---|---|
| Enrollment and posture | built into the client | absent unless something else supplies it | a managed device fails its next posture check |
| Address and resolver authority | the client sets both | the plugin plus dispatcher scripts | names resolve through the wrong resolver after a state change |
| Blocking on drop | a bundled engine | nothing by default | traffic continues in the clear after the tunnel dies |
| Upgrade path | the vendor's own channel | the distribution package and its plugin | a plugin update changes behaviour with no vendor note |
| Diagnostics and support | vendor tooling with client state | journal and dispatcher output | support cannot see why negotiation failed |
თითოეულ სტრიქონს შეუთავსეთ დაკვირვება, რომლის გამეორებაც შეგიძლიათ, და არა გრძნობა კლიენტის მიმართ. სახელი, რომელიც გადაწყდა განკუთვნილი გადამწყვეტით, მარშრუტი, რომელიც ქრება გვირაბის გაჩერებისას, და დაბლოკილი კავშირი სიმულირებული წყვეტის შემდეგ — ეს სამი დაკვირვება ერთად ფარავს ცხრილის უმეტეს ნაწილს. ჩაწერეთ დაკვირვება იმ მოთხოვნის გვერდით, რომელსაც ის ამტკიცებს, და შეინახეთ წარუმატებლები, რადგან წარუმატებელი დაკვირვება ჩანაწერის ერთადერთი ნაწილია, რომელიც შემდეგ ინციდენტს წინასწარმეტყველებს.
გადართვა საკუთრების გადაფარვის გარეშე
ერთი და იმავე მომსახურებისთვის მომწოდებლის კლიენტისა და NetworkManager-ის კავშირის ერთდროულად გაშვება ყველაზე გავრცელებული გზაა, რომლითაც ეს შედარებები ცუდად მიდის. ორივე აყენებს მარშრუტებს, ორივემ შეიძლება დააყენოს DNS, და ორივემ შეიძლება შეეხოს ქსელური დაცვის მდგომარეობას. რასაც მაშინ ზომავთ, მესამე განლაგებაა, რომელიც არც ერთი კლიენტის დოკუმენტირებულ ქცევას არ შეესაბამება.
nmcli -f NAME,UUID,TYPE connection show
nmcli connection show work --show-secrets | grep -E "^vpn\."
journalctl -u NetworkManager -b --since "10 min ago"პირველი ბრძანება გეუბნებათ, არის თუ არა პროფილი საერთოდ VPN ტიპის. მეორე აჩვენებს დანამატის მომსახურების ტიპს და რომელი საიდუმლოებებია შენახული, რაც მნიშვნელოვანია, როცა გასაღები ფაილის ნაცვლად აგენტისგან მოსალოდნელია. ჟურნალი არის ადგილი, სადაც ჩატვირთული, მაგრამ მოლაპარაკებაზე უუნარო დანამატი ამას იტყვის. თუ სამიდან არც ერთი პრობლემას არ აჩვენებს, ხარვეზი გვირაბის ზემოთ პოლიტიკის ფენებშია და არა კავშირში.
გამორთეთ ძველი კლიენტი ახალი კავშირის ჩართვამდე, შეინარჩუნეთ საბოლოო წერტილები და ანგარიში იდენტური, და ჩაწერეთ, რომელი კომპონენტი ფლობს მარშრუტებს, გადამწყვეტის პარამეტრებს და ბლოკირებას. სწორედ ეს ჩანაწერი უშლის ხელს შემდეგ განახლებას ორი მფლობელით დასრულდეს.