SNX kwenye Linux: maktaba za 32-bit na kitatuzi kinachojisetisha

SSL Network Extender ya Check Point hushindwa kwenye Linux kwa njia nne zinazotambulika, na tatu kati yao husomwa vibaya kama tatizo la kuingia. Ama faili binary haianzi, au inaanza na haiachi njia yoyote, au inaunganisha na utatuzi wa majina hufa, au portal ya kivinjari inafanya kazi wakati mstari wa amri haufanyi. Shughulikia kwa mpangilio huo, kwa sababu kila moja ni sharti la kuingia kwa linalofuata.

Dalili ya kwanza: kipakiaji kinakataa kabla ya kuingia

Kisakinishaji kinachochukuliwa kutoka kwenye ukuta wa moto huweka binary ya 32-bit yenye setuid-root kwenye /usr/bin/snx. Kwenye usambazaji wa 64-bit haiendeshwi mpaka usanifu wa i386 uwezeshwe na maktaba ambazo inaunganishwa nazo ziwepo.

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"

Orodha tupu ya not found ni lango la kila kitu kinachofuata. Seti kamili ya vifurushi hubadilika kati ya matoleo: ripoti moja iliyofanya kazi ilihitaji libstdc++5:i386, libx11-6:i386 na libpam0g:i386, nyingine ilihitaji pia libstdc++6:i386. Soma ldd badala ya kunakili orodha ya vifurushi kutoka mafunzo yaliyoandikwa kwa usambazaji mwingine.

Ikiwa snx haipatikani kabisa, kisakinishaji hakikamilika kamwe au kilijisakinisha mahali pengine nje ya PATH yako. Hiyo ni hitilafu tofauti, na inafaa kuithibitisha kabla ya kuongeza usanifu kwenye mfumo. Angalia kwa command -v snx na uangalie kwenye saraka ambayo kisakinishaji kiliripoti. Kuongeza vifurushi vya i386 kwenye mashine ambayo binary haipo kabisa hakurekebishi chochote.

Dalili ya pili: kuingia kunafanikiwa na hakuna kinachoelekezwa

Kuingia kwa mafanikio huunda tunsnx na huhariri jedwali la njia lenyewe, kwa hiyo angalia kilicho kweli kabla ya kubadilisha kitu kingine.

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

Tumia snx -d kuvunja. Kuua mchakato huacha kiolesura na njia zake, na jaribio lifuatalo hushindwa kwa sababu isiyo na uhusiano wowote na vitambulisho. Kuingia kwa kwanza pia hurekodi saini ya seva chini ya /etc/snx/, ndiyo sababu script isiyosimamiwa inaweza kuhitaji mwendo mmoja wa mwingiliano kabla ya kufanya kazi kabisa. Futa hali hiyo tu unapokusudia kuidhinisha seva tena.

Dalili ya tatu: majina hutatuliwa mpaka handaki linapanda

Hili ndilo linalovunjika kwa utulivu. snx huandika seva za DNS zilizosukumwa moja kwa moja kwenye /etc/resolv.conf. Pale njia hiyo ilipo kiungo cha mfano ndani ya /run/systemd/resolve/, uhariri unaweza kupotea kwenye tukio la kitatuzi lifuatalo, na baada ya kukatwa maingizo yaliyosukumwa yanaweza vilevile kubaki.

Mipangilio miwili inafanya kazi, na chaguo linapaswa kuwa la kukusudia na si lile lililopendekezwa na tokeo la kwanza la utafutaji:

• Chukua faili: badilisha kiungo cha mfano na faili tuli na usakinishe libnss-resolve pamoja na lahaja yake ya i386, ili huduma ya majina iwe na mbadala faili linapoandikwa upya chini yake.
• Weka systemd-resolved kama mmiliki na usajili kiungo cha handaki: resolvectl dns tunsnx 10.0.0.10, kisha resolvectl domain tunsnx corp.example, na uthibitishe kwa resolvectl status.

Andika seva za majina za kabla ya VPN kabla ya kuunganisha. Ikiwa unahariri faili kwa mkono, kuondoa maingizo yaliyosukumwa baadaye ni sehemu ya utaratibu, si usafishaji wa hiari, kwa sababu laptop inayobakiza DNS ya shirika baada ya kukatwa haitaweza kutatua kitu kingine.

Dalili ya nne: portal inafanya kazi na CLI haifanyi

Matoleo ya hivi karibuni ya ukuta wa moto yamehamisha middleware kutoka kwenye kivinjari hadi daemon ya Java ya ndani, kwa hiyo portal huzungumza na wakala wa ndani kwenye bandari ya 14186. Anwani hiyo inahitaji msamaha wa cheti cha kivinjari na mchakato unaoendelea.

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

Mstari wa amri ni njia tofauti: snx -s vpn.example.com -u user, huku ~/.snxrc ikihifadhi seva, jina la mtumiaji na upendeleo wa uthibitishaji upya. Kipindi cha portal kinachofanya kazi hakisemi chochote kuhusu kama CLI imesakinishwa ipasavyo, na mteja tupu hashughulikii misimbo ya matumizi ya mara moja.

Njia ya mkato ya kontena inayogharimu zaidi kuliko inavyookoa

snx hukagua moduli ya tun, huipakia inapokosekana, huunda kiolesura cha handaki, huandika upya njia na kusukuma trafiki kupitia humo. Kuiga hilo ndani ya kontena kunamaanisha kuweka /dev na /lib/modules na kutoa uwezo mpana, jambo ambalo hukabidhi kontena sehemu kubwa ya usimamizi wa mtandao wa mwenyeji.

Wakati sanduku la mchanga linahitajika kweli, mashine pepe ndio mpaka safi zaidi: mteja hupata kernel anayoweza kuibadilisha, na mwenyeji huhifadhi jedwali lake la njia. Chagua hilo kabla ya kutumia mchana kwenye uwezo ambao utajutia kuutoa.