Linuxda SNX: 32 bitli kutubxonalar va o’zini qayta sozlovchi rezolver

Check Point'ning SSL Network Extender Linuxda to’rtta tanib olinadigan usulda ishlamay qoladi va ulardan uchtasi noto’g’ri ravishda kirish muammosi deb o’qiladi. Yo ikkilik fayl ishga tushmaydi, yo ishga tushib hech qanday marshrut qoldirmaydi, yo ulanadi va nom hal qilish o’ladi, yoki brauzer portali ishlaydi, ammo buyruq satri ishlamaydi. Ularni shu tartibda ko’rib chiqing, chunki har biri keyingisining kirish shartidir.

Birinchi alomat: yuklagich kirishdan oldin rad etadi

Xavfsizlik devoridan olingan o’rnatuvchi 32 bitli, setuid-root ikkilik faylni /usr/bin/snx ichiga qo’yadi. 64 bitli distribyutsiyada u i386 arxitekturasi yoqilmaguncha va u bog’lanadigan kutubxonalar mavjud bo’lmaguncha ishlamaydi.

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"

Bo’sh not found ro’yxati keyingi hamma narsa uchun darvozadir. Aniq paketlar to’plami nashrlar orasida o’zgaradi: bitta ishlagan hisobotga libstdc++5:i386, libx11-6:i386 va libpam0g:i386 kerak bo’ldi, boshqasiga libstdc++6:i386 ham kerak edi. Boshqa distribyutsiya uchun yozilgan qo’llanmadan paketlar ro’yxatini ko’chirish o’rniga ldd o’qing.

Agar snx umuman topilmasa, o’rnatuvchi hech qachon tugallanmagan yoki PATHingizdan tashqarida o’rnatilgan. Bu boshqa nosozlik va tizimga arxitekturalar qo’shishdan oldin uni tasdiqlashga arziydi. command -v snx bilan tekshiring va o’rnatuvchi xabar bergan katalogga qarang. Ikkilik fayl umuman bo’lmagan mashinaga i386 paketlarini qo’shish hech narsani tuzatmaydi.

Ikkinchi alomat: kirish muvaffaqiyatli va hech narsa marshrutlanmaydi

Muvaffaqiyatli kirish tunsnx ni yaratadi va marshrut jadvalini o’zi tahrirlaydi, shuning uchun boshqa narsani o’zgartirishdan oldin aslida nima borligini tekshiring.

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

Demontaj uchun snx -d dan foydalaning. Jarayonni o’ldirish interfeys va uning marshrutlarini qoldiradi, keyingi urinish esa hisob ma’lumotlariga hech qanday aloqasi bo’lmagan sababdan muvaffaqiyatsiz bo’ladi. Birinchi kirish /etc/snx/ ostida server imzosini ham yozadi, shuning uchun nazoratsiz skript umuman ishlashi uchun bitta interaktiv ishga tushirishni talab qilishi mumkin. Bu holatni faqat serverni qayta tasdiqlamoqchi bo’lganingizda o’chiring.

Uchinchi alomat: tunnel ko’tarilmaguncha nomlar hal qilinadi

Bu jimgina buziladigan holat. snx itarilgan DNS serverlarini to’g’ridan-to’g’ri /etc/resolv.conf ichiga yozadi. Bu yo’l /run/systemd/resolve/ ichiga ramziy havola bo’lsa, tahrir keyingi rezolver hodisasida yo’qolishi mumkin va uzilgandan keyin itarilgan yozuvlar ham xuddi shunday qolishi mumkin.

Ikki tartib ishlaydi va tanlov birinchi qidiruv natijasi taklif qilgani emas, ongli bo’lishi kerak:

• Faylni o’zingiz oling: ramziy havolani statik fayl bilan almashtiring va libnss-resolve hamda uning i386 variantini o’rnating, fayl ostidan qayta yozilganda ham nom xizmatiga zaxira yo’l qolsin.
• systemd-resolved ni egasi sifatida qoldiring va tunnel havolasini ro’yxatdan o’tkazing: resolvectl dns tunsnx 10.0.0.10, keyin resolvectl domain tunsnx corp.example, va resolvectl status bilan tasdiqlang.

Ulanishdan oldin VPN oldidagi nom serverlarini yozib oling. Agar faylni qo’lda tahrirlasangiz, keyin itarilgan yozuvlarni olib tashlash protseduraning bir qismi, ixtiyoriy tozalash emas, chunki uzilgandan keyin korporativ DNS ni saqlab qolgan noutbuk boshqa hech narsani hal qila olmaydi.

To’rtinchi alomat: portal ishlaydi, CLI ishlamaydi

So’nggi xavfsizlik devori nashrlari o’rta dasturiy ta’minotni brauzerdan mahalliy Java demoniga ko’chirdi, shuning uchun portal 14186 portidagi mahalliy agent bilan gaplashadi. Bu manzilga brauzer sertifikati istisnosi va ishlab turgan jarayon kerak.

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

Buyruq satri alohida yo’l: snx -s vpn.example.com -u user, unda ~/.snxrc serverni, foydalanuvchi nomini va qayta autentifikatsiya afzalligini saqlaydi. Ishlayotgan portal sessiyasi CLI to’g’ri o’rnatilgani haqida hech narsa demaydi va yalang’och mijoz bir martalik kodlarni boshqarmaydi.

Tejagandan qimmatroq bo’lgan konteyner yo’li

snx tun modulini tekshiradi, yo’q bo’lsa yuklaydi, tunnel interfeysini yaratadi, marshrutlarni qayta yozadi va trafikni uning ichidan o’tkazadi. Buni konteyner ichida qayta yaratish /dev va /lib/modules ni ulash va keng imkoniyatlar berish demakdir, bu esa xostning tarmoq boshqaruvining ko’p qismini konteynerga beradi.

Haqiqatan ham sandbox kerak bo’lganda, virtual mashina tozaroq chegara: mijoz o’zi o’zgartira oladigan yadro oladi va xost o’z marshrut jadvalini saqlaydi. Berganingizga pushaymon bo’ladigan imkoniyatlarga tushdan keyin vaqt sarflashdan oldin shuni tanlang.