SNX sur Linux: 32-bitaj bibliotekoj kaj solvilo, kiu reŝarĝiĝas

SNX sur Linux malsukcesas ĉe la ŝargilo, la enkursiga tabelo aŭ la solvilo, kaj ĉiu malsukceso aspektas kiel ensaluta problemo. Traktu la kvar simptomojn laŭ ordo.

La SSL Network Extender de Check Point malsukcesas sur Linux laŭ kvar rekoneblaj manieroj, kaj tri el ili estas mislegataj kiel ensaluta problemo. Aŭ la binara dosiero ne ekfunkcias, aŭ ĝi ekfunkcias kaj lasas neniun itineron, aŭ ĝi konektiĝas kaj la nomresolvo mortas, aŭ la retumila portalo funkcias dum la komandlinio ne. Traktu ilin en tiu ordo, ĉar ĉiu estas la enira kondiĉo por la sekva.

Simptomo unu: la ŝargilo rifuzas antaŭ la ensaluto

La instalilo elŝutita de la fajroŝirmilo metas 32-bitan binaran dosieron kun setuid-root ĉe /usr/bin/snx. Sur 64-bita distribuo ĝi ne funkcias ĝis la arkitekturo i386 estas ŝaltita kaj la bibliotekoj, kontraŭ kiuj ĝi ligiĝas, ekzistas.

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"

Malplena listo not found estas la pordego por ĉio sekva. La preciza pakaĵaro ŝanĝiĝas inter eldonoj: unu funkcianta raporto bezonis libstdc++5:i386, libx11-6:i386 kaj libpam0g:i386, alia ankaŭ bezonis libstdc++6:i386. Legu ldd anstataŭ kopii pakaĵliston el lernilo verkita por alia distribuo.

Se snx tute ne troviĝas, la instalilo neniam finiĝis aŭ instaliĝis ie ekster via PATH. Tio estas alia fiasko, kaj indas konfirmi ĝin antaŭ ol aldoni arkitekturojn al la sistemo. Kontrolu per command -v snx kaj rigardu en la dosierujon, kiun la instalilo raportis. Aldoni pakaĵojn i386 al maŝino, kie la binara dosiero simple mankas, riparas nenion.

Simptomo du: la ensaluto sukcesas kaj nenio enkursiĝas

Sukcesa ensaluto kreas tunsnx kaj redaktas la enkursigan tabelon mem, do kontrolu, kio fakte ekzistas, antaŭ ol ŝanĝi ion ajn alian.

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

Uzu snx -d por malmunti. Mortigi la procezon lasas la interfacon kaj ĝiajn itinerojn malantaŭe, kaj la sekva provo tiam fiaskas pro kialo, kiu havas nenion komunan kun akreditaĵoj. La unua ensaluto ankaŭ registras servilan subskribon sub /etc/snx/, kaj tial aŭtomata skripto eble bezonas unu interagan ruladon antaŭ ol ĝi entute povas funkcii. Forigu tiun staton nur kiam vi intencas reaprrobi la servilon.

Simptomo tri: nomoj solviĝas ĝis la tunelo supreniĝas

Ĉi tio estas la unu, kiu silente rompiĝas. snx skribas puŝitajn DNS-servilojn rekte en /etc/resolv.conf. Kie tiu vojo estas simbola ligilo en /run/systemd/resolve/, la redakto povas perdiĝi ĉe la sekva solvila okazaĵo, kaj post malkonekto la puŝitaj enskriboj same bone povas resti.

Du aranĝoj funkcias, kaj la elekto devus esti intenca, ne tio, kion sugestis la unua serĉrezulto:

  • Prenu la dosieron: anstataŭigu la simbolan ligilon per statika dosiero kaj instalu libnss-resolve plus ĝian varianton por i386, por ke la nomservo ankoraŭ havu rezervon, kiam la dosiero estos reskribita sub ĝi.
  • Tenu systemd-resolved kiel posedanton kaj registru la tunelan ligilon: resolvectl dns tunsnx 10.0.0.10, poste resolvectl domain tunsnx corp.example, kaj konfirmu per resolvectl status.

Notu la DNS-servilojn antaŭ la VPN antaŭ ol konekti. Se vi redaktas la dosieron permane, forigi la puŝitajn enskribojn poste estas parto de la procedo, ne laŭvola purigado, ĉar tekkomputilo, kiu tenas la firmaan DNS post malkonekto, malsukcesos solvi ion ajn alian.

Simptomo kvar: la portalo funkcias kaj la CLI ne

Lastatempaj fajroŝirmilaj eldonoj movis la mezan programaron el la retumilo en lokan Java-demomon, do la portalo parolas kun loka agento ĉe haveno 14186. Tiu adreso bezonas retumilan atestilan escepton kaj ruliĝantan procezon.

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

La komandlinio estas aparta vojo: snx -s vpn.example.com -u user, kun ~/.snxrc tenanta la servilon, la uzantnomon kaj la preferon pri reaŭtentigo. Funkcianta portalosesio diras nenion pri tio, ĉu la CLI estas ĝuste instalita, kaj la nuda kliento ne traktas unufojajn kodojn.

La uja mallongigo, kiu kostas pli ol ĝi ŝparas

snx kontrolas la modulon tun, ŝargas ĝin kiam ĝi mankas, kreas tunelan interfacon, reskribas itinerojn kaj puŝas trafikon tra ĝi. Reprodukti tion ene de ujo signifas munti /dev kaj /lib/modules kaj doni larĝajn kapablojn, kio transdonas al la ujo la plimulton de la reta administrado de la gastiganto.

Kiam sablujo estas vere necesa, virtuala maŝino estas la pli pura limo: la kliento ricevas kernon, kiun ĝi rajtas modifi, kaj la gastiganto konservas sian enkursigan tabelon. Elektu tion antaŭ ol pasigi posttagmezon ĉe kapabloj, kiujn vi bedaŭros esti doninta.

Rilataj artikoloj