SNX Linux: 32 bitų bibliotekos ir išsiderinantis resolveris

SNX Linux sistemoje žlunga įkroviklyje, maršrutų lentelėje arba resolveryje, ir kiekvienas gedimas atrodo kaip prisijungimo problema. Išnagrinėkite keturis simptomus iš eilės.

Check Point SSL Network Extender Linux sistemoje žlunga keturiais atpažįstamais būdais, ir trys iš jų klaidingai perskaitomi kaip prisijungimo problema. Arba dvejetainis failas nepasileidžia, arba pasileidžia ir nepalieka maršruto, arba prisijungia ir vardų skiriamoji geba miršta, arba naršyklės portalas veikia, o komandų eilutė ne. Išnagrinėkite juos šia tvarka, nes kiekvienas yra kito įėjimo sąlyga.

Pirmas simptomas: įkroviklis atsisako prieš prisijungimą

Iš ugniasienės atsiųstas diegiklis įkelia 32 bitų setuid-root dvejetainį failą į /usr/bin/snx. 64 bitų distribucijoje jis neveikia, kol neįjungta i386 architektūra ir nėra bibliotekų, prie kurių jis susietas.

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"

Tuščias not found sąrašas yra vartai viskam, kas toliau. Tikslus paketų rinkinys keičiasi tarp leidimų: vienai veikiančiai ataskaitai reikėjo libstdc++5:i386, libx11-6:i386 ir libpam0g:i386, kitai taip pat reikėjo libstdc++6:i386. Skaitykite ldd, o ne kopijuokite paketų sąrašą iš mokymo, parašyto kitai distribucijai.

Jei snx visai nerastas, diegiklis niekada nebuvo užbaigtas arba įdiegtas kažkur už jūsų PATH ribų. Tai kitas gedimas, ir verta jį patvirtinti prieš pridedant architektūras į sistemą. Patikrinkite su command -v snx ir pažiūrėkite į katalogą, kurį nurodė diegiklis. i386 paketų pridėjimas prie mašinos, kurioje dvejetainio failo tiesiog nėra, nieko neištaiso.

Antras simptomas: prisijungimas pavyksta, ir niekas nemaršrutizuojama

Sėkmingas prisijungimas sukuria tunsnx ir pats redaguoja maršrutų lentelę, todėl patikrinkite, kas iš tikrųjų egzistuoja, prieš ką nors keisdami.

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

Išmontavimui naudokite snx -d. Proceso nužudymas palieka sąsają ir jos maršrutus, ir kitas bandymas tada žlunga dėl priežasties, neturinčios nieko bendra su prisijungimo duomenimis. Pirmas prisijungimas taip pat įrašo serverio parašą po /etc/snx/, todėl neprižiūrimas scenarijus gali prireikti vieno interaktyvaus paleidimo, kol jis apskritai galės veikti. Ištrinkite tą būseną tik tada, kai ketinate iš naujo patvirtinti serverį.

Trečias simptomas: vardai sprendžiami, kol tunelis nepakyla

Šis tyliai lūžta. snx įrašo stumiamus DNS serverius tiesiai į /etc/resolv.conf. Kai tas kelias yra simbolinė nuoroda į /run/systemd/resolve/, pakeitimas gali būti prarastas kitame resolverio įvykyje, o po atsijungimo stumiami įrašai taip pat gali likti.

Veikia du išdėstymai, ir pasirinkimas turėtų būti sąmoningas, o ne toks, kurį pasiūlė pirmas paieškos rezultatas:

  • Pasiimkite failą: pakeiskite simbolinę nuorodą statiniu failu ir įdiekite libnss-resolve kartu su jo i386 variantu, kad vardų tarnyba vis dar turėtų atsarginį kelią, kai failas bus perrašytas po ja.
  • Palikite systemd-resolved savininku ir užregistruokite tunelio nuorodą: resolvectl dns tunsnx 10.0.0.10, tada resolvectl domain tunsnx corp.example, ir patvirtinkite su resolvectl status.

Užsirašykite prieš VPN buvusius vardų serverius prieš prisijungdami. Jei failą redaguojate rankiniu būdu, stumiamų įrašų pašalinimas vėliau yra procedūros dalis, o ne neprivalomas valymas, nes nešiojamasis kompiuteris, išlaikantis įmonės DNS po atsijungimo, negalės išspręsti nieko kito.

Ketvirtas simptomas: portalas veikia, o CLI ne

Naujausi ugniasienės leidimai perkėlė tarpinę programinę įrangą iš naršyklės į vietinį Java demoną, todėl portalas kalbasi su vietiniu agentu prievade 14186. Tam adresui reikia naršyklės sertifikato išimties ir veikiančio proceso.

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

Komandų eilutė yra atskiras kelias: snx -s vpn.example.com -u user, o ~/.snxrc saugo serverį, vartotojo vardą ir pakartotinio autentifikavimo nuostatą. Veikianti portalo sesija nieko nesako apie tai, ar CLI įdiegtas teisingai, o plikas klientas neapdoroja vienkartinių kodų.

Konteinere naudingesnis sprendimas

snx tikrina tun modulį, jį įkelia, kai jo nėra, sukuria tunelio sąsają, perrašo maršrutus ir varo srautą per jį. Tai atkurti konteineryje reiškia prijungti /dev ir /lib/modules bei suteikti plačius pajėgumus, o tai perduoda konteineriui didžiąją dalį pagrindinio kompiuterio tinklo administravimo.

Kai smėlio dėžė tikrai reikalinga, virtualioji mašina yra švaresnė riba: klientas gauna branduolį, kurį gali keisti, o pagrindinis kompiuteris išlaiko savo maršrutų lentelę. Pasirinkite tai, prieš praleisdami popietę pajėgumams, kurių duoti gailėsitės.

Susiję straipsniai