SNX v Linuxu: 32bitové knihovny a resolver, který se resetuje

SNX v Linuxu selhává u zavaděče, směrovací tabulky nebo resolveru a každá z těchto závad vypadá jako problém s přihlášením. Projděte čtyři příznaky v pořadí.

SSL Network Extender od Check Pointu selhává v Linuxu čtyřmi rozpoznatelnými způsoby a tři z nich se chybně čtou jako problém s přihlášením. Buď se binárka nespustí, nebo se spustí a nezanechá žádnou trasu, nebo se připojí a rozklad jmen zemře, nebo portál v prohlížeči funguje, zatímco příkazový řádek ne. Projděte je v tomto pořadí, protože každý je vstupní podmínkou pro další.

Příznak první: zavaděč odmítne před přihlášením

Instalátor stažený z firewallu položí 32bitovou binárku se setuid-root do /usr/bin/snx. Na 64bitové distribuci se nespustí, dokud není povolena architektura i386 a dokud neexistují knihovny, proti kterým se linkuje.

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"

Prázdný seznam not found je branou pro vše, co následuje. Přesná sada balíčků se mezi vydáními mění: jeden funkční záznam potřeboval libstdc++5:i386, libx11-6:i386 a libpam0g:i386, jiný potřeboval také libstdc++6:i386. Čtěte ldd, místo abyste opisovali seznam balíčků z návodu psaného pro jinou distribuci.

Pokud snx chybí úplně, instalátor se nikdy nedokončil nebo se nainstaloval někam mimo váš PATH. To je jiná závada a vyplatí se ji potvrdit, než do systému přidáte architektury. Ověřte to pomocí command -v snx a podívejte se do adresáře, který instalátor uvedl. Přidání balíčků i386 na stroj, kde binárka prostě chybí, nic nespraví.

Příznak druhý: přihlášení uspěje a nic se nesměruje

Úspěšné přihlášení vytvoří tunsnx a samo upraví směrovací tabulku, takže si před jakoukoli další změnou ověřte, co skutečně existuje.

ip -br addr show tunsnx
ip route | grep tunsnx
snx -d

K odstranění použijte snx -d. Zabít proces zanechá rozhraní i jeho trasy a další pokus pak selže z důvodu, který s přihlašovacími údaji nemá nic společného. První přihlášení také zapíše podpis serveru do /etc/snx/, a proto může neinteraktivní skript potřebovat jedno interaktivní spuštění, než vůbec začne fungovat. Ten stav mažte jen tehdy, když chcete server znovu schválit.

Příznak třetí: jména se rozkládají, dokud se tunel nezvedne

Tohle je ten, který se tiše rozbije. snx zapisuje vnucené DNS servery přímo do /etc/resolv.conf. Kde je tato cesta symbolickým odkazem do /run/systemd/resolve/, může se úprava při další události resolveru ztratit a po odpojení mohou vnucené záznamy stejně dobře zůstat.

Fungují dvě uspořádání a volba by měla být vědomá, ne taková, jakou navrhl první výsledek hledání:

  • Převezměte soubor: nahraďte symbolický odkaz statickým souborem a nainstalujte libnss-resolve plus jeho variantu pro i386, aby služba jmen měla zálohu, když se soubor pod ní přepíše.
  • Nechte systemd-resolved jako vlastníka a zaregistrujte spojení tunelu: resolvectl dns tunsnx 10.0.0.10, pak resolvectl domain tunsnx corp.example, a potvrďte pomocí resolvectl status.

Zapište si jmenné servery před VPN, než se připojíte. Pokud soubor upravujete ručně, odstranění vnucených záznamů potom je součástí postupu, ne volitelné čištění, protože notebook, který si po odpojení ponechá firemní DNS, nebude schopen rozložit nic jiného.

Příznak čtvrtý: portál funguje a CLI ne

Nedávná vydání firewallu přesunula middleware z prohlížeče do místního démona Java, takže portál mluví s místním agentem na portu 14186. Ta adresa potřebuje výjimku certifikátu v prohlížeči a běžící proces.

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

Příkazový řádek je samostatná cesta: snx -s vpn.example.com -u user, přičemž ~/.snxrc uchovává server, uživatelské jméno a volbu opětovného ověření. Funkční relace portálu nic neříká o tom, zda je CLI správně nainstalováno, a holý klient nezvládá jednorázové kódy.

Zkratka s kontejnerem, která stojí víc, než ušetří

snx zkontroluje modul tun, při jeho nepřítomnosti ho načte, vytvoří rozhraní tunelu, přepíše trasy a žene přes něj provoz. Reprodukovat to uvnitř kontejneru znamená připojit /dev a /lib/modules a udělit široké možnosti, což kontejneru předá většinu správy sítě hostitele.

Když je pískoviště opravdu potřeba, virtuální stroj je čistší hranice: klient dostane jádro, které smí měnit, a hostitel si ponechá svou směrovací tabulku. Vyberte to dřív, než strávíte odpoledne na možnostech, kterých budete litovat.

Související články