SNX në Linux: bibliotekat 32-bit dhe një zgjidhës që rivendoset

SSL Network Extender i Check Point dështon në Linux në katër mënyra të dallueshme, dhe tre prej tyre lexohen gabimisht si problem hyrjeje. Ose binari nuk niset, ose niset dhe nuk lë asnjë rrugë, ose lidhet dhe zgjidhja e emrave vdes, ose portali i shfletuesit funksionon ndërsa rreshti i komandës jo. Punoni me atë radhë, sepse secili është kushti i hyrjes për tjetrin.

Simptoma e parë: ngarkuesi refuzon para hyrjes

Instaluesi i tërhequr nga muri i zjarrit vendos një binare 32-bit me setuid-root në /usr/bin/snx. Në një shpërndarje 64-bit nuk ekzekutohet derisa arkitektura i386 të aktivizohet dhe bibliotekat me të cilat lidhet të ekzistojnë.

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"

Një listë not found bosh është porta për çdo gjë që vjen pas. Bashkësia e saktë e paketave ndryshon midis botimeve: një raport funksional kërkonte libstdc++5:i386, libx11-6:i386 dhe libpam0g:i386, një tjetër kërkonte gjithashtu libstdc++6:i386. Lexoni ldd në vend që të kopjoni një listë paketash nga një mësim i shkruar për një shpërndarje tjetër.

Nëse snx nuk gjendet fare, instaluesi nuk përfundoi kurrë ose u instalua diku jashtë PATH-it tuaj. Ky është një dështim tjetër, dhe ia vlen të konfirmohet përpara se të shtoni arkitektura në sistem. Kontrolloni me command -v snx dhe shikoni në drejtorinë që raportoi instaluesi. Shtimi i paketave i386 në një makinë ku binari thjesht mungon nuk rregullon asgjë.

Simptoma e dytë: hyrja ka sukses dhe asgjë nuk rrugëzohet

Një hyrje e suksesshme krijon tunsnx dhe e redakton vetë tabelën e rrugëzimit, prandaj kontrolloni çfarë ekziston vërtet përpara se të ndryshoni diçka tjetër.

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

Përdorni snx -d për çmontim. Vrasja e procesit lë pas ndërfaqen dhe rrugët e saj, dhe përpjekja tjetër pastaj dështon për një arsye që nuk ka asnjë lidhje me kredencialet. Hyrja e parë regjistron gjithashtu një nënshkrim serveri nën /etc/snx/, prandaj një skript pa mbikëqyrje mund të ketë nevojë për një ekzekutim interaktiv përpara se të funksionojë fare. Fshini atë gjendje vetëm kur synoni të riaprovoni serverin.

Simptoma e tretë: emrat zgjidhen derisa tuneli ngrihet

Ky është ai që thyhet në heshtje. snx i shkruan serverët DNS të shtyrë drejtpërdrejt në /etc/resolv.conf. Aty ku kjo rrugë është një lidhje simbolike brenda /run/systemd/resolve/, redaktimi mund të humbasë në ngjarjen tjetër të zgjidhësit, dhe pas një shkëputjeje edhe hyrjet e shtyra mund të mbeten.

Funksionojnë dy rregullime, dhe zgjedhja duhet të jetë e qëllimshme e jo ajo që sugjeroi rezultati i parë i kërkimit:

• Merrni skedarin: zëvendësoni lidhjen simbolike me një skedar statik dhe instaloni libnss-resolve bashkë me variantin e tij i386, që shërbimi i emrave të ketë ende një alternativë kur skedari rishkruhet poshtë tij.
• Mbani systemd-resolved si pronar dhe regjistroni lidhjen e tunelit: resolvectl dns tunsnx 10.0.0.10, pastaj resolvectl domain tunsnx corp.example, dhe konfirmoni me resolvectl status.

Shkruani serverët e emrave para VPN-së përpara se të lidheni. Nëse e redaktoni skedarin me dorë, heqja e hyrjeve të shtyra më pas është pjesë e procedurës, jo pastrim opsional, sepse një laptop që mban DNS-në e korporatës pas shkëputjes nuk do të mund të zgjidhë asgjë tjetër.

Simptoma e katërt: portali funksionon dhe CLI jo

Botimet e fundit të murit të zjarrit e kanë zhvendosur ndërmjetësin nga shfletuesi në një demon lokal Java, kështu që portali flet me një agjent lokal në portën 14186. Ajo adresë kërkon një përjashtim certifikate në shfletues dhe një proces që punon.

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

Rreshti i komandës është një rrugë e veçantë: snx -s vpn.example.com -u user, ku ~/.snxrc mban serverin, emrin e përdoruesit dhe preferencën e riautentikimit. Një sesion portali që funksionon nuk thotë asgjë nëse CLI është instaluar saktë, dhe klienti i thjeshtë nuk trajton kode njëpërdorimshme.

Shkurtesa e kontejnerit që kushton më shumë sesa kursen

snx kontrollon modulin tun, e ngarkon kur mungon, krijon një ndërfaqe tuneli, rishkruan rrugët dhe e shtyn trafikun përmes saj. Rikrijimi i kësaj brenda një kontejneri do të thotë të montoni /dev dhe /lib/modules dhe të jepni aftësi të gjera, gjë që i jep kontejnerit pjesën më të madhe të administrimit të rrjetit të strehuesit.

Kur kërkohet vërtet një sandbox, një makinë virtuale është kufiri më i pastër: klienti merr një kernel që mund ta ndryshojë, dhe strehuesi mban tabelën e tij të rrugëzimit. Zgjidhni atë përpara se të kaloni një pasdite në aftësi që do të pendoheni se i dhatë.