რატომ ვერ მუშაობს GlobalProtect-ის Linux კლიენტი ახალ Ubuntu-ზე

გონივრული ვარაუდია, რომ თქვენი GlobalProtect პორტალიდან მიღებული .deb დაზიანებულია, ან ვენდორმა ცუდი build გამოუშვა. ჩვეულებრივ ასე არ არის. ვენდორის Linux ინტერფეისი კვლავ Qt5 WebKit-ზეა ბმული, ხოლო ახალი Ubuntu გამოშვებები მას აღარ აწვდიან, ამიტომ პაკეტი ითხოვს ბიბლიოთეკას, რომელიც თქვენმა დისტრიბუციამ განზრახ ამოიღო. ეს შეფუთვის შეუსაბამობაა და არა დაზიანებული ჩამოტვირთვა, და სწორედ ეს განსხვავება წყვეტს, შუადღეს პაკეტების იძულებით დაყენებას დახარჯავთ თუ ათ წუთს სხვა კლიენტის არჩევას.

.deb არ არის დაზიანებული

დამოკიდებულება, რომელსაც დისტრიბუცია აღარ ატარებს, ბიბლიოთეკის პენსიაზე გასვლის ნორმალური შედეგია. Qt5 WebKit ამოღებულ იქნა გვიანდელი Ubuntu არქივებიდან და Debian-იდან, ხოლო მიზეზი უსაფრთხოების მოვლა იყო და არა მოთხოვნის ნაკლებობა. როცა ეს ხდება, ყოველი პაკეტი, რომელიც ჯერ კიდევ მასზეა ბმული, წყვეტს დაყენებადობას, რაც არ უნდა კარგად იყოს აწყობილი.

ორი მარცხი ერთი და იმავე ბაგად მოხსენდება და ასე არ არის. ბიბლიოთეკის გარეშე გამოშვებაზე ინსტალატორი ჩერდება დაუკმაყოფილებელ დამოკიდებულებაზე. იმ გამოშვებაზე, სადაც კლიენტი დაყენდება და შემდეგ შესვლისას ვარდება, თქვენ ხედავთ TLS ან SAML ხელის ჩამორთმევის პრობლემას ჩაშენებული ბრაუზერის კომპონენტში. პირველი შეფუთვაა; მეორე გაშვების დროა, და არც ერთი არ სწორდება ძველი ბიბლიოთეკების თანამედროვე სამუშაო მაგიდაზე კოპირებით.

დაადასტურეთ დამოკიდებულება და ნუ აიძულებთ მას

დააყენეთ პაკეტი ცხადად, რათა ხელსაწყომ დაასახელოს გადაუჭრელი დამოკიდებულება და არა მოგცეთ შეჯამება. შემდეგ იკითხეთ, აქვს თუ არა თქვენს გამოშვებას საერთოდ კანდიდატი, რადგან „აქ მიუწვდომელია” და „დროებით აკლია ამ სარკეში” სულ სხვა გადაწყვეტილებებამდე მიგვიყვანს:

sudo apt install ./GlobalProtect_UI_deb-*.deb
apt-cache policy libqt5webkit5
apt-cache rdepends --installed libqt5webkit5

თუ apt-cache policy არ იუწყება არც ერთ კანდიდატს, შეწყვიტეთ მისი დაყენების მცდელობა და დაიწყეთ ალტერნატივის არჩევა. საინტერესო არ არის დაკარგული პაკეტის სახელი; საინტერესოა ის ფაქტი, რომ ვენდორის დამოკიდებულებათა გრაფიკა არ გადაადგილდა თქვენი მომხმარებლების მიერ გაშვებულ დისტრიბუციებთან ერთად.

რას უკეთებს ძველი პაკეტების იძულება სამუშაო მაგიდას

მოძრავი გადაწყვეტა ბიბლიოთეკის ძველი გამოშვებიდან გამოთრევაა. მიმდინარე Ubuntu-ზე ეს Qt5-ის უმცირესი ვერსიის კონფლიქტში გადადის: ძველი პაკეტები ეწევიან libqt5core5t64 უკან, და შემდეგ დაყენებული KDE და PyQt პაკეტები იწყებენ ABI ვერსიის მოთხოვნას, რომელსაც დაქვეითებული ბიბლიოთეკა აღარ აწვდის. შედეგი ნაწილობრივი განახლებაა, რომელიც უკავშირო პროგრამებს ამტვრევს, და ეს იმ შუადღეზე ბევრად უარესია, რომლითაც დაიწყეთ.

ეს შედეგი მოსალოდნელია და არა უიღბლობა. Qt-ის ABI მოლოდინები უმცირეს ვერსიებზე მკაცრია, და დისტრიბუცია ერთ შეთანხმებულ კომპლექტს აწვდის. სხვა გამოშვებიდან ერთი ბიბლიოთეკის შერევა მიზნობრივი შესწორება არ არის; ეს მეორე, ნაკლებად კონტროლირებადი განახლებაა.

იგივე რჩევა ეხება მარცხის გაშვების დროის ვარიანტს. OpenSSL-ის სისტემური უსაფრთხოების დონის დაწევა, რათა ძველი კლიენტის ხელის ჩამორთმევა შედგეს, ცვლის მანქანაზე ყოველ TLS კავშირს ერთი პროგრამის გასწორებისთვის, მათ შორის პაკეტების მენეჯერისა, რომელიც დაგჭირდებათ, როცა სხვა რამ გატყდება.

openconnect ამ პროტოკოლზე საუბრობს

OpenConnect უშუალოდ ახორციელებს GlobalProtect-ის პროტოკოლს, და პროტოკოლის შენიშვნები აღწერს როგორც გამოძახებას, ისე ორ სერვერულ ინტერფეისს შორის გაყოფას. პორტალი ავრცელებს პარამეტრებს და კარიბჭეების სიას; კარიბჭე ამთავრებს გვირაბს:

openconnect --protocol=gp vpn.example.com
openconnect --protocol=gp --authgroup=staff vpn.example.com

თუ პორტალი გამოტოვებს თქვენთვის საჭირო კარიბჭეს, --usergroup=gateway ან /gateway სიტყვებით დამთავრებული URL გამოტოვებს პორტალის საფეხურს. როცა რამდენიმე კარიბჭე შემოთავაზებულია, --authgroup=NAME ირჩევს მათ შორის. აუთენტიფიკაცია მომხმარებლის სახელი და პაროლია, სურვილისამებრ კლიენტის სერტიფიკატით, ხოლო SAML კარიბჭეები პრაქტიკაში მუშაობს network-manager-openconnect მეშვეობით და არა ხელით აკრეფილი ბრძანების სტრიქონით.

მკაცრი posture პოლიტიკის მქონე კარიბჭემ შეიძლება მოითხოვოს HIP ანგარიშიც, სანამ გვირაბს მოგცემთ. OpenConnect მას შექმნის და გაგზავნას შეძლებს, მაგრამ თუ კარიბჭე ითხოვს ინვენტარს, რომელსაც ის ვერ აწარმოებს, ვერც ერთი დროშა ვერ შეცვლის ამ პოლიტიკას; ეს სერვერის მხარეს მიღებული გადაწყვეტილებაა.

შეამოწმეთ გვირაბი და იცოდეთ, რას არ გაასწორებს openconnect

შეხედეთ, რა გამოიყენა გვირაბმა სინამდვილეში, ნაცვლად წარმატების შეტყობინების ნდობისა. კარიბჭე მარშრუტიზაციას და კონფიგურაციას XML-ად აგზავნის და კლიენტი მათ იყენებს, ამიტომ დაკარგული მარშრუტი კონფიგურაციის ან არჩევანის პრობლემაა და არა კლიენტის ბაგი:

ip -4 addr show
ip route
resolvectl status

MTU ცალკე ყურადღების ღირსია. GlobalProtect-ის კონფიგურაცია ყოველთვის იუწყება ნულოვან MTU-ს, ამიტომ კლიენტი მას ინკაფსულაციის ხარჯიდან აფასებს. დიდი გადაცემები, რომლებიც ჩერდება, სანამ პატარა მოთხოვნები გადის, კლასიკური სიმპტომია, და წამალი კავშირზე ცხადი MTU-ა და არა ბილიკის აღმოჩენის გამორთვა.

IPv6 ისევ ცალკე ამბავია. PAN-მა ის დაამატა GlobalProtect 4.0-ში, და OpenConnect-ის მხარდაჭერა აღწერილია როგორც ექსპერიმენტული 9.0 ვერსიიდან, ამიტომ ნუ ივარაუდებთ, რომ მისამართების ოჯახი IPv4-ივით იქცევა მხოლოდ იმიტომ, რომ გვირაბი ავიდა. და თუ კარიბჭე ითხოვს posture შემოწმებას, რომელსაც ღია კოდის კლიენტი ვერ ასრულებს, გაუშვით ვენდორის კლიენტი მხარდაჭერილ LTS გამოშვებაზე, ვირტუალურ მანქანაში, თუ თქვენი სამუშაო სადგური უკვე წინ წავიდა. ეს სამუშაო მაგიდას ხელუხლებლად ინახავს და ძველ დამოკიდებულებას თქვენ მიერ ხელახლა ასაშენებელ საზღვარში ათავსებს.