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 пасля адключэння, не зможа разбіраць нічога іншага.

Сімптом чацвёрты: партал працуе, а камандны радок не

Нядаўнія выпускі файрвола перанеслі прамежкавае ПЗ з браўзера ў лакальны дэман Java, таму партал размаўляе з лакальным агентам на порце 14186. Гэты адрас патрабуе выключэння для сертыфіката ў браўзеры і працуючага працэсу.

ps ax | grep cshell
/usr/bin/cshell/launcher

Камандны радок — асобны шлях: snx -s vpn.example.com -u user, а ~/.snxrc захоўвае сервер, імя карыстальніка і настройку паўторнай аўтэнтыфікацыі. Працоўная сесія партала нічога не кажа пра тое, ці правільна ўсталяваны камандны радок, і голы кліент не апрацоўвае аднаразовыя коды.

Кантэйнерны кароткі шлях, які каштуе больш, чым эканоміць

snx правярае модуль tun, загружае яго, калі яго няма, стварае інтэрфейс тунеля, перапісвае маршруты і гоніць трафік праз яго. Адпаўтарыць гэта ўнутры кантэйнера значыць змантаваць /dev і /lib/modules ды даць шырокія магчымасці, што перадае кантэйнеру большую частку сеткавага адміністравання хаста.

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

Падобныя артыкулы