SNX sa Linux: 32-bit na mga library at resolver na nagre-reset

Nabibigo ang SSL Network Extender ng Check Point sa Linux sa apat na makikilalang paraan, at tatlo sa mga ito ay maling binabasa bilang problema sa pag-login. Alinman sa hindi bumubukas ang binary, o bumubukas at walang iniwang ruta, o kumokonekta at namamatay ang paglutas ng pangalan, o gumagana ang portal sa browser habang hindi gumagana ang command line. Isa-isahin ang mga ito sa ganoong pagkakasunod-sunod, dahil bawat isa ay pasukan na kondisyon para sa susunod.

Sintomas isa: tumatanggi ang loader bago ang pag-login

Inilalagay ng installer na hinihila mula sa firewall ang 32-bit na binary na may setuid-root sa /usr/bin/snx. Sa 64-bit na distribusyon hindi ito tumatakbo hanggang sa ma-enable ang i386 na arkitektura at umiral ang mga library na kinalalagyan nito.

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"

Ang walang lamang listahan ng not found ay ang tarangkahan para sa lahat ng susunod. Nagbabago ang eksaktong set ng pakete sa pagitan ng mga release: isang gumaganang ulat ang nangailangan ng libstdc++5:i386, libx11-6:i386 at libpam0g:i386, ang isa pa ay nangailangan din ng libstdc++6:i386. Basahin ang ldd sa halip na kopyahin ang listahan ng pakete mula sa tutorial na isinulat para sa ibang distribusyon.

Kung talagang hindi mahanap ang snx, hindi kailanman natapos ang installer o nag-install ito sa isang lugar sa labas ng iyong PATH. Iba iyon na pagkabigo, at sulit itong kumpirmahin bago magdagdag ng mga arkitektura sa sistema. Suriin gamit ang command -v snx at tingnan sa direktoryo na iniulat ng installer. Ang pagdaragdag ng mga paketeng i386 sa makina kung saan talagang wala ang binary ay walang naaayos.

Sintomas dalawa: nagtagumpay ang pag-login at walang nairuruta

Ang matagumpay na pag-login ay gumagawa ng tunsnx at ito mismo ang nag-e-edit ng routing table, kaya suriin kung ano talaga ang umiiral bago baguhin ang anumang iba.

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

Gamitin ang snx -d para sa pagtatanggal. Kapag pinatay ang proseso, naiiwan ang interface at ang mga ruta nito, at ang susunod na pagtatangka ay mabibigo dahil sa dahilang walang kinalaman sa mga kredensyal. Ang unang pag-login ay nagtatala rin ng lagda ng server sa ilalim ng /etc/snx/, kaya maaaring kailanganin ng hindi binabantayang script ng isang interactive na pagtakbo bago ito gumana. Burahin lamang ang estadong iyon kapag balak mong aprubahan muli ang server.

Sintomas tatlo: nalulutas ang mga pangalan hanggang umangat ang tunnel

Ito ang tahimik na nasisira. Isinusulat ng snx ang mga itinulak na DNS server nang direkta sa /etc/resolv.conf. Kung saan ang landas na iyon ay simbolikong link sa loob ng /run/systemd/resolve/, maaaring mawala ang pag-edit sa susunod na kaganapan ng resolver, at pagkatapos ng pagkadiskonekta ang mga itinulak na entry ay maaari ring manatili.

Dalawang kaayusan ang gumagana, at ang pagpili ay dapat sinadya at hindi ang iminungkahi ng unang resulta ng paghahanap:

• Kunin ang file: palitan ang simbolikong link ng statikong file at i-install ang libnss-resolve kasama ang i386 na variant nito, upang ang serbisyo ng pangalan ay mayroon pa ring alternatibo kapag ang file ay muling isinulat sa ilalim nito.
• Panatilihin ang systemd-resolved bilang may-ari at irehistro ang link ng tunnel: resolvectl dns tunsnx 10.0.0.10, pagkatapos ay resolvectl domain tunsnx corp.example, at kumpirmahin gamit ang resolvectl status.

Itala ang mga nameserver bago ang VPN bago kumonekta. Kung ine-edit mo ang file sa pamamagitan ng kamay, ang pagtanggal ng mga itinulak na entry pagkatapos ay bahagi ng pamamaraan, hindi opsyonal na paglilinis, dahil ang laptop na nagpapanatili ng corporate DNS pagkatapos ng pagkadiskonekta ay hindi makakalutas ng anupaman.

Sintomas apat: gumagana ang portal at hindi ang CLI

Inilipat ng mga kamakailang release ng firewall ang middleware mula sa browser patungo sa lokal na Java daemon, kaya nakikipag-usap ang portal sa lokal na ahente sa port 14186. Ang address na iyon ay nangangailangan ng exception sa sertipiko ng browser at tumatakbong proseso.

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

Ang command line ay hiwalay na landas: snx -s vpn.example.com -u user, kung saan hawak ng ~/.snxrc ang server, username at kagustuhan sa muling pagpapatunay. Ang gumaganang sesyon ng portal ay walang sinasabi tungkol sa kung wasto ang pagkaka-install ng CLI, at ang hubad na client ay hindi humahawak ng isang-beses-gamiting code.

Ang shortcut ng container na mas mahal kaysa sa natitipid

Sinusuri ng snx ang tun module, nilo-load ito kapag wala, gumagawa ng tunnel interface, nagsusulat muli ng mga ruta at itinutulak ang trapiko sa pamamagitan nito. Ang paggawa niyon sa loob ng container ay nangangahulugang i-mount ang /dev at /lib/modules at magbigay ng malawak na kakayahan, na nagbibigay sa container ng malaking bahagi ng pamamahala ng network ng host.

Kapag talagang kailangan ang sandbox, ang virtual machine ang mas malinis na hangganan: nakakakuha ang client ng kernel na maaari niyang baguhin, at pinapanatili ng host ang route table nito. Piliin iyon bago magpalipas ng hapon sa mga kakayahang pagsisisihan mong ibinigay.