SNX Linux-ზე: 32-ბიტიანი ბიბლიოთეკები და გადატვირთული რეზოლვერი

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

სიმპტომი ერთი: ჩამტვირთავი შესვლამდე უარს ამბობს

ქსელური ფარიდან ჩამოტვირთული ინსტალატორი 32-ბიტიან setuid-root ბინარულს /usr/bin/snx-ში დებს. 64-ბიტიან დისტრიბუციაზე ის არ მუშაობს, სანამ i386 არქიტექტურა ჩართული არ იქნება და ბიბლიოთეკები, რომლებთანაც ლინკდება, არ არსებობს.

sudo dpkg --add-architecture i386
sudo apt update
sudo apt install libstdc++5:i386 libstdc++6:i386 libx11-6:i386 libpam0g:i386
ldd /usr/bin/snx | grep "not found"

ცარიელი not found სია ყველაფრის კარიბჭეა, რაც შემდეგ მოდის. პაკეტების ზუსტი ნაკრები გამოშვებებს შორის იცვლება: ერთ მუშა ანგარიშს სჭირდებოდა libstdc++5:i386, libx11-6:i386 და libpam0g:i386, მეორეს კი libstdc++6:i386-იც. წაიკითხეთ ldd იმის ნაცვლად, რომ პაკეტების სია სხვა დისტრიბუციისთვის დაწერილი გაკვეთილიდან დააკოპიროთ.

თუ snx საერთოდ არ მოიძებნა, ინსტალატორი არასოდეს დასრულებულა ან თქვენი PATH-ის გარეთ დაყენდა. ეს სხვა უკმარისობაა, და ღირს მისი დადასტურება სანამ სისტემას არქიტექტურებს დაუმატებთ. შეამოწმეთ command -v snx-ით და შეხედეთ იმ საქაღალდეში, რომელიც ინსტალატორმა მიუთითა. i386 პაკეტების დამატება მანქანაზე, სადაც ბინარული უბრალოდ არ არის, არაფერს ასწორებს.

სიმპტომი ორი: შესვლა წარმატებულია და არაფერი მარშრუტიზდება

წარმატებული შესვლა ქმნის tunsnx-ს და თავად არედაქტირებს მარშრუტიზაციის ცხრილს, ამიტომ სანამ სხვა რამეს შეცვლით, შეამოწმეთ რა არსებობს სინამდვილეში.

ip -br addr show tunsnx
ip route | grep tunsnx
snx -d

დაშლისთვის გამოიყენეთ snx -d. პროცესის მოკვლა ტოვებს ინტერფეისს და მის მარშრუტებს, და შემდეგი ცდა შემდეგ ისე ვარდება, რომ მიზეზს არაფერი აქვს საერთო სერთიფიკატებთან. პირველი შესვლა ასევე იწერს სერვერის ხელმოწერას /etc/snx/-ში, ამიტომ უყურადღებო სკრიპტს შეიძლება დასჭირდეს ერთი ინტერაქტიული გაშვება მანამ, სანამ ის საერთოდ იმუშავებს. წაშალეთ ეს მდგომარეობა მხოლოდ მაშინ, როცა სერვერის ხელახლა დამტკიცებას აპირებთ.

სიმპტომი სამი: სახელები იხსნება მანამ, სანამ გვირაბი ამოვა

ეს არის ის, რაც ჩუმად ტყდება. snx გაგზავნილ DNS სერვერებს პირდაპირ /etc/resolv.conf-ში წერს. სადაც ეს გზა სიმბოლური ბმულია /run/systemd/resolve/-ში, ცვლილება შეიძლება დაიკარგოს რეზოლვერის შემდეგ მოვლენაზე, და გათიშვის შემდეგ გაგზავნილი ჩანაწერები ისევე შეიძლება დარჩეს.

ორი წყობა მუშაობს, და არჩევანი განზრახ უნდა იყოს და არა ის, რაც პირველმა ძიების შედეგმა შემოგვთავაზა:

• აიღეთ ფაილი: შეცვალეთ სიმბოლური ბმული სტატიკური ფაილით და დააყენეთ libnss-resolve თავისი i386 ვარიანტით, რათა სახელების სერვისს ჯერ კიდევ ჰქონდეს სარეზერვო გზა, როცა ფაილი მის ქვემოთ გადაიწერება.
• დატოვეთ systemd-resolved მფლობელად და დაარეგისტრირეთ გვირაბის ბმული: resolvectl dns tunsnx 10.0.0.10, შემდეგ resolvectl domain tunsnx corp.example, და დაადასტურეთ resolvectl status-ით.

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

სიმპტომი ოთხი: პორტალი მუშაობს და CLI არა

ბოლო ქსელური ფარის გამოშვებებმა შუამავალი პროგრამა ბრაუზერიდან ლოკალურ Java დემონში გადაიტანეს, ამიტომ პორტალი 14186 პორტზე ლოკალურ აგენტს ელაპარაკება. ამ მისამართს სჭირდება ბრაუზერის სერტიფიკატის გამონაკლისი და მომუშავე პროცესი.

ps ax | grep cshell
/usr/bin/cshell/launcher

ბრძანების ხაზი ცალკე გზაა: snx -s vpn.example.com -u user, სადაც ~/.snxrc ინახავს სერვერს, მომხმარებლის სახელს და ხელახალი ავტორიზაციის უპირატესობას. მომუშავე პორტალის სესია არაფერს ამბობს იმაზე, სწორად არის თუ არა CLI დაყენებული, და შიშველი კლიენტი ერთჯერად კოდებს არ ამუშავებს.

კონტეინერის მოკლე გზა, რომელიც ზოგავს ნაკლებს, ვიდრე ხარჯავს

snx ამოწმებს tun მოდულს, აკლებისას ტვირთავს მას, ქმნის გვირაბის ინტერფეისს, გადაწერს მარშრუტებს და ტრაფიკს მის გავლით უშვებს. ამის კონტეინერში გამეორება ნიშნავს /dev-ისა და /lib/modules-ის მიმაგრებას და ფართო შესაძლებლობების მინიჭებას, რაც კონტეინერს ჰოსტის ქსელური ადმინისტრირების უმეტეს ნაწილს გადასცემს.

როცა ქვიშის ყუთი ნამდვილად საჭიროა, ვირტუალური მანქანა უფრო სუფთა საზღვარია: კლიენტი იღებს ბირთვს, რომლის შეცვლაც შეუძლია, და ჰოსტი ინარჩუნებს თავის მარშრუტიზაციის ცხრილს. აირჩიეთ ეს, სანამ შუადღეს დახარჯავთ შესაძლებლობებზე, რომელთა მიცემასაც ინანებთ.