Linux-те SNX: 32 биттік кітапханалар және өзін қайта қосатын шешуші

Linux-те SNX жүктеушіде, маршрут кестесінде немесе шешушіде сәтсіз аяқталады, және әрқайсысы кіру мәселесі сияқты көрінеді. Төрт симптомды ретімен өңдеңіз.

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 қосу және кең мүмкіндіктер беру дегенді білдіреді, бұл хосттың желілік әкімшілендіруінің көбін контейнерге береді.

Шынымен құмсалғыш қажет болғанда, виртуалды машина таза шекара: клиент өзі өзгерте алатын ядро алады, ал хост өз маршрут кестесін сақтайды. Бергеніңізге өкінетін мүмкіндіктерге түстен кейінгі уақытты жұмсамас бұрын соны таңдаңыз.

Қатысты мақалалар