SNX v Linuxe: 32-bitové knižnice a resolver, ktorý sa resetuje

SNX v Linuxe zlyháva v zavádzači, smerovacej tabuľke alebo v resolveri, a každá z týchto porúch vyzerá ako problém s prihlásením. Prejdite štyri príznaky v poradí.

SSL Network Extender od Check Pointu zlyháva v Linuxe štyrmi rozpoznateľnými spôsobmi a tri z nich sa nesprávne čítajú ako problém s prihlásením. Buď sa binárka nespustí, alebo sa spustí a nezanechá žiadnu trasu, alebo sa pripojí a rozklad mien zomrie, alebo portál v prehliadači funguje, zatiaľ čo príkazový riadok nie. Prejdite ich v tomto poradí, pretože každý je vstupnou podmienkou pre ďalší.

Príznak prvý: zavádzač odmietne pred prihlásením

Inštalátor stiahnutý z firewallu umiestni 32-bitovú binárku so setuid-root do /usr/bin/snx. Na 64-bitovej distribúcii sa nespustí, kým nie je povolená architektúra i386 a kým neexistujú knižnice, proti ktorým sa 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ázdny zoznam not found je bránou pre všetko, čo nasleduje. Presná sada balíkov sa medzi vydaniami mení: jeden funkčný záznam potreboval libstdc++5:i386, libx11-6:i386 a libpam0g:i386, iný potreboval aj libstdc++6:i386. Čítajte ldd namiesto kopírovania zoznamu balíkov z návodu písaného pre inú distribúciu.

Ak snx chýba úplne, inštalátor sa nikdy nedokončil alebo sa nainštaloval niekam mimo vášho PATH. To je iná porucha a vyplatí sa ju potvrdiť pred pridaním architektúr do systému. Overte to pomocou command -v snx a pozrite sa do adresára, ktorý inštalátor uviedol. Pridanie balíkov i386 na stroj, kde binárka jednoducho chýba, nič nenapraví.

Príznak druhý: prihlásenie uspeje a nič sa nesmeruje

Úspešné prihlásenie vytvorí tunsnx a samo upraví smerovaciu tabuľku, preto si pred akoukoľvek ďalšou zmenou overte, čo skutočne existuje.

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

Na odstránenie použite snx -d. Zabitie procesu zanechá rozhranie aj jeho trasy a ďalší pokus potom zlyhá z dôvodu, ktorý nemá nič spoločné s prihlasovacími údajmi. Prvé prihlásenie tiež zapíše podpis servera do /etc/snx/, a preto môže neinteraktívny skript potrebovať jedno interaktívne spustenie, kým vôbec začne fungovať. Ten stav mažte len vtedy, keď chcete server znova schváliť.

Príznak tretí: mená sa rozkladajú, kým sa tunel nezvedne

Toto je ten, ktorý sa potichu pokazí. snx zapisuje vnútené DNS servery priamo do /etc/resolv.conf. Kde je táto cesta symbolickým odkazom do /run/systemd/resolve/, môže sa úprava stratiť pri ďalšej udalosti resolvera a po odpojení môžu vnútené záznamy rovnako dobre zostať.

Fungujú dve usporiadania a voľba by mala byť vedomá, nie taká, akú navrhol prvý výsledok hľadania:

  • Prevezmite súbor: nahraďte symbolický odkaz statickým súborom a nainštalujte libnss-resolve plus jeho variant pre i386, aby služba mien mala zálohu, keď sa súbor pod ňou prepíše.
  • Nechajte systemd-resolved ako vlastníka a zaregistrujte spojenie tunela: resolvectl dns tunsnx 10.0.0.10, potom resolvectl domain tunsnx corp.example, a potvrďte pomocou resolvectl status.

Zapíšte si menné servery pred VPN, než sa pripojíte. Ak súbor upravujete ručne, odstránenie vnútených záznamov potom je súčasťou postupu, nie voliteľné čistenie, pretože notebook, ktorý si po odpojení ponechá firemný DNS, nebude schopný rozložiť nič iné.

Príznak štvrtý: portál funguje a CLI nie

Nedávne vydania firewallu presunuli middleware z prehliadača do lokálneho démona Java, takže portál komunikuje s lokálnym agentom na porte 14186. Tá adresa potrebuje výnimku certifikátu v prehliadači a bežiaci proces.

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

Príkazový riadok je samostatná cesta: snx -s vpn.example.com -u user, pričom ~/.snxrc uchováva server, používateľské meno a nastavenie opätovného overenia. Fungujúca relácia portálu nič nehovorí o tom, či je CLI správne nainštalované, a holý klient nezvláda jednorazové kódy.

Skratka s kontajnerom, ktorá stojí viac, než ušetrí

snx skontroluje modul tun, pri jeho neprítomnosti ho načíta, vytvorí rozhranie tunela, prepíše trasy a ženie cez neho prevádzku. Reprodukovať to v kontajneri znamená pripojiť /dev a /lib/modules a udeliť široké možnosti, čo kontajneru odovzdá väčšinu správy siete hostiteľa.

Keď je pieskovisko naozaj potrebné, virtuálny stroj je čistejšia hranica: klient dostane jadro, ktoré smie meniť, a hostiteľ si ponechá svoju smerovaciu tabuľku. Vyberte to skôr, než strávite popoludnie na možnostiach, ktorých udelenie budete ľutovať.

Súvisiace články