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 и да се дадат широки можности, што на контејнерот му го предава најголемиот дел од мрежната администрација на домаќинот.

Кога песочна кутија е навистина потребна, виртуелната машина е почиста граница: клиентот добива јадро што смее да го менува, а домаќинот ја задржува својата табела со рути. Изберете го тоа пред да потрошите попладне на можности за кои ќе зажалите што сте ги дале.

Поврзани статии