SNX Linuxon: 32 bites könyvtárak és egy újrainduló feloldó

Az SNX Linuxon a betöltőnél, a routingtáblánál vagy a feloldónál hiúsul meg, és mindegyik hiba bejelentkezési problémának látszik. Dolgozza fel a négy tünetet sorrendben.

A Check Point SSL Network Extenderje négy felismerhető módon hiúsul meg Linuxon, és ezek közül hármat tévesen bejelentkezési problémának olvasnak. Vagy el sem indul a bináris, vagy elindul és nem hagy maga után útvonalat, vagy csatlakozik és a névfeloldás meghal, vagy a böngészőportál működik, miközben a parancssor nem. Ebben a sorrendben dolgozza fel őket, mert mindegyik a következő belépési feltétele.

Első tünet: a betöltő a bejelentkezés előtt elutasít

A tűzfaltól lekért telepítő 32 bites, setuid-root binárist tesz a /usr/bin/snx helyre. 64 bites disztribúción nem fut, amíg az i386 architektúra nincs engedélyezve, és amíg nem léteznek a könyvtárak, amelyekhez linkelődik.

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"

Az üres not found lista a kapu minden utána következőhöz. A pontos csomagkészlet kiadásonként változik: az egyik működő jelentéshez libstdc++5:i386, libx11-6:i386 és libpam0g:i386 kellett, a másikhoz libstdc++6:i386 is kellett. Olvassa a ldd kimenetét ahelyett, hogy egy másik disztribúcióhoz írt útmutatóból másolná a csomaglistát.

Ha a snx egyáltalán nem található, a telepítő soha nem fejeződött be, vagy a PATH-n kívül telepített. Ez más hiba, és érdemes megerősíteni, mielőtt architektúrákat ad a rendszerhez. Ellenőrizze a command -v snx segítségével, és nézze meg a telepítő által jelzett könyvtárat. Az i386 csomagok hozzáadása olyan gépen, ahol a bináris egyszerűen hiányzik, semmit nem javít.

Második tünet: a bejelentkezés sikerül, és semmi nem routolódik

A sikeres bejelentkezés létrehozza a tunsnx-ot, és maga szerkeszti a routingtáblát, ezért ellenőrizze, mi létezik valójában, mielőtt bármi mást megváltoztat.

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

A lebontáshoz használja a snx -d parancsot. A folyamat megölése maga után hagyja az interfészt és annak útvonalait, és a következő kísérlet aztán olyan okból hiúsul meg, amelynek semmi köze a hitelesítő adatokhoz. Az első bejelentkezés egy kiszolgáló-aláírást is rögzít a /etc/snx/ alatt, ezért egy felügyelet nélküli szkriptnek szüksége lehet egy interaktív futásra, mielőtt egyáltalán működne. Ezt az állapotot csak akkor törölje, ha újra jóvá kívánja hagyni a kiszolgálót.

Harmadik tünet: a nevek feloldódnak, amíg az alagút fel nem jön

Ez az, amelyik csendben elromlik. Az snx a leküldött DNS-kiszolgálókat egyenesen a /etc/resolv.conf fájlba írja. Ahol ez az útvonal szimbolikus hivatkozás a /run/systemd/resolve/ könyvtárba, a módosítás elveszhet a következő feloldóeseménynél, és a kapcsolat bontása után a leküldött bejegyzések ugyanúgy megmaradhatnak.

Két elrendezés működik, és a választás szándékos legyen, ne az, amit az első keresési találat javasolt:

  • Vegye át a fájlt: cserélje a szimbolikus hivatkozást statikus fájlra, és telepítse a libnss-resolve csomagot a i386 változatával együtt, hogy a névszolgáltatásnak még legyen tartaléka, amikor a fájlt alatta újraírják.
  • Tartsa meg a systemd-resolved-et tulajdonosként, és regisztrálja az alagút kapcsolatát: resolvectl dns tunsnx 10.0.0.10, majd resolvectl domain tunsnx corp.example, és erősítse meg a resolvectl status segítségével.

Jegyezze fel a VPN előtti névkiszolgálókat, mielőtt csatlakozik. Ha kézzel szerkeszti a fájlt, a leküldött bejegyzések utólagos eltávolítása az eljárás része, nem választható takarítás, mert egy laptop, amely a kapcsolat bontása után megtartja a vállalati DNS-t, semmi mást nem tud feloldani.

Negyedik tünet: a portál működik, a CLI nem

A közelmúlt tűzfalkiadványai a köztes szoftvert a böngészőből egy helyi Java-démonba helyezték át, így a portál egy helyi ügynökkel beszél a 14186-os porton. Ehhez a címhez böngésző-tanúsítványkivétel és futó folyamat kell.

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

A parancssor külön útvonal: snx -s vpn.example.com -u user, ahol a ~/.snxrc tárolja a kiszolgálót, a felhasználónevet és az újrahitelesítési beállítást. Egy működő portálmunkamenet semmit nem mond arról, hogy a CLI megfelelően telepítve van-e, és a csupasz kliens nem kezeli az egyszeri kódokat.

A konténeres rövidítés, amely többe kerül, mint amennyit megtakarít

Az snx ellenőrzi a tun modult, hiányában betölti, alagútinterfészt hoz létre, átírja az útvonalakat, és átnyomja rajta a forgalmat. Ennek konténeren belüli reprodukálása a /dev és a /lib/modules felcsatolását és széles jogosultságok megadását jelenti, ami a gazdagép hálózati adminisztrációjának nagy részét a konténernek adja.

Amikor valóban homokozóra van szükség, a virtuális gép a tisztább határ: az ügyfél olyan kernelt kap, amelyet módosíthat, a gazdagép pedig megtartja a routingtábláját. Ezt válassza, mielőtt egy délutánt olyan jogosultságokra szánna, amelyeket megbán, hogy megadott.

Kapcsolódó cikkek