SNX op Linux: 32-bit bibleteken en in resolver dy’t himsels weromset

SNX op Linux mislearret by de lader, de rûtetabel of de resolver, en elk fan dy flaters liket in ynlochprobleem. Wurkje de fjouwer symptomen yn folchoarder ôf.

De SSL Network Extender fan Check Point mislearret op Linux op fjouwer werkenbere manieren, en trije dêrfan wurde ferkeard lêzen as in ynlochprobleem. Of de binary start net, of hy start en lit gjin rûte efter, of hy ferbynt en namme-oplossing stjert, of it browserportaal wurket wylst de kommandorigel dat net docht. Wurkje se yn dy folchoarder ôf, want elk is de yngongsbetingst foar de folgjende.

Symptoom ien: de lader wegeret foar it ynloggen

De ynstallearder dy’t fan de firewall helle wurdt, lit in 32-bit binary mei setuid-root efter by /usr/bin/snx. Op in 64-bit distribúsje rint er net oant de i386-arsjitektuer oansetten is en de bibleteken dêr’t er tsjin keppele is, bestean.

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"

In lege not found-list is de poarte foar alles dêrnei. De krekte pakketset ferskoot tusken útjeften: ien wurkjend rapport hie libstdc++5:i386, libx11-6:i386 en libpam0g:i386 nedich, in oar hie ek libstdc++6:i386 nedich. Lês ldd ynstee fan in pakketlist te kopiearjen út in hantlieding skreaun foar in oare distribúsje.

As snx hielendal net fûn wurdt, hat de ynstallearder nea foltôge of hat er earne bûten dyn PATH ynstallearre. Dat is in oare flater, en it is de muoite wurdich om dy te befêstigjen foardatst arsjitektueren oan it systeem tafoegest. Kontrolearje mei command -v snx en sjoch yn de map dy’t de ynstallearder meldde. i386-pakketten tafoegje oan in masine dêr’t de binary gewoan ôfwêzich is, makket neat goed.

Symptoom twa: it ynloggen slagget en neat wurdt rûte

In slagge ynloggen makket tunsnx oan en bewurket sels de rûtetabel, dus kontrolearje wat der echt bestiet foardatst eat oars feroarest.

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

Brûk snx -d foar it ôfbrekken. It fermoardzjen fan it proses lit de ynterface en syn rûtes efter, en de folgjende poging mislearret dan om in reden dy’t neat mei ynloggegevens te krijen hat. De earste ynloggen skriuwt ek in tsjinnerhanttekening ûnder /etc/snx/, en dêrom kin in net-bewekke skript ien ynteraktive run nedich hawwe foardat it hielendal wurkje kin. Wiskje dy steat allinnich as do fan doel bist de tsjinner opnij goed te keuren.

Symptoom trije: nammen wurde oplost oant de tunnel omheech komt

Dit is dejinge dy’t stil brekt. snx skriuwt trochdûne DNS-tsjinners streekrjocht yn /etc/resolv.conf. Wêr’t dat paad in symboalyske keppeling yn /run/systemd/resolve/ is, kin de bewurking by it folgjende resolver-evenemint ferlern gean, en nei in ôfbrekking kinne de trochdûne yngongen likegoed efterbliuwe.

Twa regelingen wurkje, en de kar moat bewust wêze ynstee fan wat it earste sykresultaat foarstelde:

  • Nim it bestân oer: ferfange de symboalyske keppeling troch in statysk bestân en ynstallearje libnss-resolve plus syn i386-fariant, sadat de nammedienst noch in efterfal hat as it bestân derûnder opnij skreaun wurdt.
  • Hâld systemd-resolved as eigner en registrearje de tunnelkeppeling: resolvectl dns tunsnx 10.0.0.10, dan resolvectl domain tunsnx corp.example, en befêstigje mei resolvectl status.

Notearje de nammetsjinners fan foar de VPN foardatst ferbynt. As do it bestân mei de hân bewurkest, is it fuortheljen fan de trochdûne yngongen dêrnei part fan de proseduere, net opsjoneel opromjen, want in laptop dy’t nei ôfbrekking it bedriuws-DNS hâldt, sil neat oars mear oplosse kinne.

Symptoom fjouwer: it portaal wurket en de CLI net

Resinte firewall-útjeften hawwe de middleware út de browser nei in lokale Java-daemon ferpleatst, sadat it portaal mei in lokale agent op poarte 14186 praat. Dat adres hat in browser-sertifikaatútsûndering en in rinnend proses nedich.

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

De kommandorigel is in apart paad: snx -s vpn.example.com -u user, mei ~/.snxrc dy’t de tsjinner, de brûkersnamme en de foarkar foar opnij autentisearjen hâldt. In wurkjende portaal-sesje seit neat oer de fraach oft de CLI goed ynstallearre is, en de keale kliïnt behannelet gjin ienmalige koades.

De kontener-shortcut dy’t mear kostet as er besparret

snx kontrolearret op de tun-module, laden as dy ûntbrekt, makket in tunnel-ynterface, skriuwt rûtes opnij en triuwt ferkear der trochhinne. Dat yn in kontener reprodusearje betsjut /dev en /lib/modules munte en brede kapasiteiten jaan, wat de kontener it measte fan it netwurkbehear fan de host jout.

As in sânbak echt nedich is, is in firtuele masine de skjinne grins: de kliïnt krijt in kearn dy’t er feroarje mei, en de host hâldt syn rûtetabel. Kies dat foardatst in middei oan kapasiteiten besteegest dy’tst spyt krije silst datst se jûn hast.

Relatearre artikelen