SNX Linux-da: 32 bitlik kitabxanalar və sıfırlanan həlledici

Check Point-in SSL Network Extender-i Linux-da dörd tanınan şəkildə uğursuz olur və onlardan üçü giriş problemi kimi səhv oxunur. Ya ikili fayl başlamır, ya başlayır və heç bir marşrut qoymur, ya qoşulur və ad həlli ölür, ya da brauzer portalı işləyir, əmr sətri isə işləmir. Onları bu sıra ilə işləyin, çünki hər biri növbətinin giriş şərtidir.

Simptom bir: yükləyici girişdən əvvəl imtina edir

Firewalldan çəkilən quraşdırıcı 32 bitlik, setuid-root ikili faylı /usr/bin/snx ünvanına qoyur. 64 bitlik paylamada i386 arxitekturası aktivləşdirilməyincə və faylın link etdiyi kitabxanalar mövcud olmayınca işləmir.

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ş not found siyahısı ondan sonra gələn hər şey üçün qapıdır. Dəqiq paket dəsti buraxılışlar arasında dəyişir: bir işləyən hesabat libstdc++5:i386, libx11-6:i386 və libpam0g:i386 tələb edirdi, digəri isə libstdc++6:i386 da tələb edirdi. Fərqli paylama üçün yazılmış dərslikdən paket siyahısı kopyalamaq əvəzinə ldd oxuyun.

Əgər snx ümumiyyətlə tapılmırsa, quraşdırıcı heç vaxt tamamlanmayıb və ya PATH-inizdən kənarda quraşdırılıb. Bu fərqli bir nasazlıqdır və sistemə arxitekturalar əlavə etməzdən əvvəl bunu təsdiqləməyə dəyər. command -v snx ilə yoxlayın və quraşdırıcının bildirdiyi qovluğa baxın. İkili faylın sadəcə olmadığı maşına i386 paketləri əlavə etmək heç nəyi düzəltmir.

Simptom iki: giriş uğurludur və heç nə marşrutlaşmır

Uğurlu giriş tunsnx yaradır və marşrut cədvəlini özü redaktə edir, ona görə başqa bir şeyi dəyişməzdən əvvəl həqiqətən nəyin mövcud olduğunu yoxlayın.

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

Sökmə üçün snx -d istifadə edin. Prosesi öldürmək interfeysi və onun marşrutlarını geridə qoyur və növbəti cəhd sonra etimadnamə ilə heç bir əlaqəsi olmayan səbəbdən uğursuz olur. İlk giriş həmçinin /etc/snx/ altında server imzası qeyd edir, buna görə nəzarətsiz skript ümumiyyətlə işləməzdən əvvəl bir interaktiv işə ehtiyac duya bilər. Bu vəziyyəti yalnız serveri yenidən təsdiqləmək niyyətində olduqda silin.

Simptom üç: tunel qalxana qədər adlar həll olunur

Bu, səssizcə pozulan haldır. snx itələnmiş DNS serverlərini birbaşa /etc/resolv.conf faylına yazır. Bu yol /run/systemd/resolve/ içinə simvolik keçid olduqda, redaktə növbəti həlledici hadisəsində itə bilər və əlaqə kəsləndikdən sonra itələnmiş qeydlər eyni dərəcədə geridə qala bilər.

İki tənzim işləyir və seçim ilk axtarış nəticəsinin təklif etdiyi şey deyil, qəsdən olmalıdır:

• Faylı ələ keçirin: simvolik keçidi statik faylla əvəz edin və libnss-resolve və onun i386 variantını quraşdırın ki, fayl altınızdan yenidən yazıldıqda ad xidmətinin hələ də ehtiyat yolu olsun.
• systemd-resolved-i sahib kimi saxlayın və tunel keçidini qeyd edin: resolvectl dns tunsnx 10.0.0.10, sonra resolvectl domain tunsnx corp.example, və resolvectl status ilə təsdiqləyin.

Qoşulmazdan əvvəl VPN-dən əvvəlki ad serverlərini qeyd edin. Faylı əl ilə redaktə etsəniz, sonra itələnmiş qeydləri silmək prosedurun bir hissəsidir, könüllü təmizlik deyil, çünki əlaqə kəsləndikdən sonra korporativ DNS-i saxlayan noutbuk başqa heç nəyi həll edə bilməyəcək.

Simptom dörd: portal işləyir, CLI isə yox

Son firewall buraxılışları ara proqramı brauzerdən yerli Java demonuna köçürdü, buna görə portal 14186 portunda yerli agentlə danışır. Bu ünvan brauzer sertifikatı istisnası və işləyən proses tələb edir.

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

Əmr sətri ayrı bir yoldur: snx -s vpn.example.com -u user, serveri, istifadəçi adını və yenidən doğrulama seçimini ~/.snxrc saxlayır. İşləyən portal sessiyası CLI-nin düzgün quraşdırıldığı barədə heç nə demir və sadə klient birdəfəlik kodları idarə etmir.

Daha çox itirən konteyner qısayolu

snx tun modulunu yoxlayır, olmadıqda onu yükləyir, tunel interfeysi yaradır, marşrutları yenidən yazır və trafiki onun içindən keçirir. Bunu konteyner daxilində təkrarlamaq /dev və /lib/modules qovluqlarını mount etməyi və geniş imkanlar verməyi tələb edir ki, bu da konteynerə hostun şəbəkə idarəetməsinin çoxunu verir.

Sandbox həqiqətən tələb olunduqda, virtual maşın daha təmiz sərhəddir: klient dəyişdirə biləcəyi bir nüvə alır, host isə marşrut cədvəlini saxlayır. Verməyə peşman olacağınız imkanlara bir gün sərf etməzdən əvvəl bunu seçin.