Check Point VPN Linux-ზე: SNX ჩამოსატვირთი ინსტალატორი არ არის

ეძებთ Check Point-ის Linux კლიენტს და ვერ პოულობთ ჩამოტვირთვის გვერდს ინსტალატორით. ეს არქონა შეფუთვის ხარვეზი არ არის. Check Point-ის Linux-ის დისტანციური წვდომის კლიენტია SSL Network Extender, ანუ SNX, და გეითვეი მას გაძლევთ მას შემდეგ, რაც ბრაუზერში ავთენტიფიკაციას გაივლით. როცა ეს ადგილზე დალაგდება, დანარჩენი დაბნეულობაც აზრს იძენს, მათ შორის ის, თუ რატომ არის მასზე თითქმის ყველა ტექსტი წლების წინანდელი.

მითი: არსებობს კლიენტი, რომელსაც ჩამოტვირთავთ და დააყენებთ

ეს მოლოდინი ყველა სხვა მომწოდებლისგან მოდის. OpenVPN, WireGuard და კომერციული კლიენტების უმეტესობა აქვეყნებენ პაკეტს ან რეპოზიტორს, და მისი დაყენება ლოკალური გადაწყვეტილებაა, რომელსაც მარტო იღებთ. Check Point Linux-ზე ასე არ მუშაობს. მიმდინარე გეითვეის ვერსიების ოფიციალურ ჩამოტვირთვებში ცალკე ინსტალატორი არ არის, ამიტომ მისი ძებნა მხოლოდ ძველ ფორუმის თემებსა და მესამე მხარის სარკეებს იძლევა.

ეს სარკეები უსარგებლოზე უარესია, რადგან აწყობა უნდა შეესაბამებოდეს იმ გეითვეის, რომელიც მას ემსახურება.

რა არის სინამდვილეში SNX და საიდან მოდის

SNX არის ბრძანების ხაზის კლიენტი, რომლის ბინარული ფაილია snx, და ის დგინდება იმ სესიის მეშვეობით, რომელსაც ბრაუზერში გეითვეის წინააღმდეგ იწყებთ. ისტორიულად Java აპლეტი ჩამოტვირთავდა და აყენებდა მას მას შემდეგ, რაც მოთხოვნას დაეთანხმებოდით. მექანიზმი წლების განმავლობაში შეიცვალა, წყარო — არა. გეითვეი ემსახურება იმ აწყობას, რომელიც შეესაბამება თავის თავს, ამიტომ კლიენტისა და გეითვეის ვერსიები ერთად მიდიან და ამიტომ ძველი პაკეტიდან კოპირებული კლიენტი მუშაობს მხოლოდ მანამ, სანამ გეითვეი ჯერ კიდევ ელაპარაკება მას.

ეს ასევე ნიშნავს, რომ გეითვეი მზად უნდა იყოს მანამ, სანამ კლიენტზე ნებისმიერი სამუშაო მნიშვნელობას შეიძენს. Mobile Access Software Blade უნდა იყოს ლიცენზირებული და კონფიგურირებული, რადგან მის გარეშე დასაყენებელი პორტალი არ არსებობს. კლიენტის მხარეს არც ერთი ძალისხმევა არ ქმნის სესიას იმ გეითვეის წინააღმდეგ, რომელიც მას არ სთავაზობს.

მიმართეთ კლიენტი გეითვეიზე თქვენი მომხმარებლით და წაიკითხეთ, რას იუწყება ის:

snx -s vpn.example.com -u your.name

შეზღუდვა ინსტალატორი არ არის, არამედ დისტრიბუტივების მხარდაჭერა

SNX-ისთვის მომწოდებლის მხარდაჭერილი დისტრიბუტივების სია მოკლე და ძველია. გამოქვეყნებულ სტატიაში ის დაახლოებით Ubuntu 17.04-ზე ჩერდება, იმავე ეპოქის რამდენიმე openSUSE, Fedora და RHEL გამოშვებასთან ერთად, და ჯერ კიდევ ჩამოთვლის Ubuntu 12.10-ს. ეს გეუბნებათ, როგორ ბერდება სია, და არა ის, რა სჭირდება თქვენს მანქანას. მიმდინარე დისტრიბუტივი მასში უბრალოდ არ არის.

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

ldd $(command -v snx) | grep "not found"

შემდეგ ნახეთ იმ გეითვეის გამოშვების მხარდაჭერის სტატია, რომელსაც რეალურად ერთვებით. ბლოგის სია თავსებადობის განცხადება არ არის, და უფრო ახალი დისტრიბუტივი უფრო ახალ კლიენტს არ ნიშნავს.

X11-ის ის დეტალი, რომელიც ეკრანის გარეშე მუშაობას შესაძლებელს ხდის

SNX-ს სჭირდება X11 ბიბლიოთეკები, მაგრამ არა მომუშავე X სერვერი. ეს განსხვავება არის მთელი განსხვავება ეკრანის გარეშე ჰოსტზე SSH-ით მომუშავე კლიენტსა და იმას შორის, რომელიც გამოსავლის გარეშე ჩამოკიდებულად გამოიყურება. დააყენეთ თქვენი დისტრიბუტივის მიერ მოწოდებული ბიბლიოთეკის პაკეტი და არა სხვა გამოშვებიდან კოპირებული ნაკრები, და გაუშვით კლიენტი იმ სესიიდან, რომელსაც გვირაბი სჭირდება.

დაკავშირების შემდეგწაიკითხეთ ინტერფეისი და მარშრუტები, სანამ რომელიმეს ენდობით:

ip -brief addr show
ip route show

SNX ქმნის გვირაბის ინტერფეისს და აყენებს პორტალის მიერ განსაზღვრულ მარშრუტებს. ეს მარშრუტები გეითვეის გადაწყვეტილებაა და არა თქვენი, ამიტომ დაკარგული პრეფიქსი გეითვეის მხარეს პროფილის პრობლემაა და არა კლიენტის შეცდომა. ამავდროულად შეამოწმეთ DNS, რადგან split-tunnel პროფილები ხშირად თავს გიკადრებენ რეზოლვერს, რომელსაც არ ელოდით.

როცა SNX სრულიად არასწორი პასუხია

Check Point-ის გეითვეებს ასევე შეუძლიათ IPsec დაL2TPკლიენტიდან საიტამდე კავშირების დასრულება, და ისინი მუშაობენ strongSwan-ით, Libreswan-ით ან NetworkManager-ის L2TP დანამატით. ეს გეითვეის კონფიგურაციაა, არა კლიენტის ხრიკი. თუ გეითვეი მხოლოდ Mobile Access პორტალს აქვეყნებს,IPsec კლიენტს სალაპარაკო არაფერი აქვს, და ჟურნალი ავთენტიფიკაციის ჩავარდნის ნაცვლად დროის ამოწურვას აჩვენებს. იკითხეთ, რომელი დისტანციური წვდომის ბლეიდებია ჩართული, სანამ რამე სხვას დააყენებთ.

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