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

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

Похожие статьи