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.

Запишіть сервери імен, що були до 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 та надати широкі можливості, що передає контейнеру більшу частину мережевого адміністрування хоста.

Коли пісочниця справді потрібна, віртуальна машина — чистіша межа: клієнт отримує ядро, яке може змінювати, а хост зберігає свою таблицю маршрутизації. Виберіть це, перш ніж витратити півдня на можливості, про надання яких пошкодуєте.

Схожі статті