SNX под Linux: 32-битови библиотеки и резолвер, който се нулира

SNX под Linux се проваля при зареждача, таблицата с маршрути или резолвера и всяка от тези повреди изглежда като проблем с влизането. Работете четирите симптома по ред.

SSL Network Extender на Check Point се проваля под 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.

Запишете DNS сървърите преди 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 и предоставяне на широки възможности, което дава на контейнера по-голямата част от мрежовата администрация на хоста.

Когато наистина е нужна пясъчна среда, виртуалната машина е по-чистата граница: клиентът получава ядро, което може да променя, а хостът запазва таблицата си с маршрути. Изберете това, преди да прекарате следобед върху възможности, които ще съжалявате, че сте дали.

Подобни статии