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

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

Повезани чланци