SNX Linuxis: 32-bitised teegid ja lähtestuv nimeresolver

SNX Linuxis nurjub laadijas, marsruutimistabelis või nimeresolveris ja iga tõrge näeb välja nagu sisselogimisprobleem. Töötage neli sümptomit järjekorras läbi.

Check Pointi SSL Network Extender nurjub Linuxis neljal äratuntaval viisil ja kolme neist loetakse ekslikult sisselogimisprobleemiks. Kas binaarfail ei käivitu, või käivitub ja ei jäta ühtki marsruuti, või ühendub ja nimeotsing sureb, või brauseriportaal töötab, samal ajal kui käsurida ei tööta. Töötage need selles järjekorras läbi, sest igaüks on järgmise jaoks sisenemistingimus.

Sümptom üks: laadija keeldub enne sisselogimist

Tulemüürist tõmmatud paigaldaja jätab 32-bitise setuid-root binaarfaili asukohta /usr/bin/snx. 64-bitises distributsioonis ei käivitu see enne, kui i386 arhitektuur on lubatud ja teegid, mille vastu see lingitakse, on olemas.

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"

Tühi not found nimekiri on värav kõigele järgnevale. Täpne paketivalik muutub väljalasete vahel: üks töötav raport vajas libstdc++5:i386, libx11-6:i386 ja libpam0g:i386, teine vajas ka libstdc++6:i386. Lugege ldd, selle asemel et kopeerida paketinimekiri teise distributsiooni jaoks kirjutatud õpetusest.

Kui snx ei leita üldse, ei lõpetatud paigaldust kunagi või paigaldati see kuhugi väljapoole teie PATH-i. See on teistsugune tõrge ja seda tasub kinnitada enne, kui lisate süsteemi arhitektuure. Kontrollige command -v snx abil ja vaadake kataloogi, mille paigaldaja teatas. i386 pakettide lisamine masinale, kus binaarfail lihtsalt puudub, ei paranda midagi.

Sümptom kaks: sisselogimine õnnestub ja miski ei marsruutu

Õnnestunud sisselogimine loob tunsnx ja muudab marsruutimistabelit ise, seega kontrollige, mis tegelikult olemas on, enne kui midagi muud muudate.

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

Kasutage lammutamiseks snx -d. Protsessi tapmine jätab liidese ja selle marsruudid maha ning järgmine katse nurjub siis põhjusel, millel pole volitustega midagi pistmist. Esimene sisselogimine salvestab ka serveri allkirja asukohta /etc/snx/, mistõttu võib järelevalveta skript vajada enne üldse töötamist ühte interaktiivset käivitust. Kustutage see olek ainult siis, kui kavatsete serveri uuesti heaks kiita.

Sümptom kolm: nimed lahenevad, kuni tunnel tõuseb

See on see, mis vaikselt katki läheb. snx kirjutab lükatud DNS-serverid otse faili /etc/resolv.conf. Kui see tee on sümboolne link kausta /run/systemd/resolve/, võib muudatus järgmisel resolveri sündmusel kaduda ja pärast katkestamist võivad lükatud kirjed sama hästi alles jääda.

Kaks korraldust töötavad ja valik peaks olema teadlik, mitte see, mida pakkus esimene otsingutulemus:

  • Võtke fail üle: asendage sümboolne link staatilise failiga ja paigaldage libnss-resolve koos selle i386 variandiga, et nimeserveril oleks endiselt varuvõimalus, kui fail selle all ümber kirjutatakse.
  • Jätke systemd-resolved omanikuks ja registreerige tunneli link: resolvectl dns tunsnx 10.0.0.10, seejärel resolvectl domain tunsnx corp.example, ja kinnitage resolvectl status abil.

Märkige üles VPN-i eelsed nimeserverid enne ühendamist. Kui muudate faili käsitsi, on lükatud kirjete eemaldamine hiljem protseduuri osa, mitte valikuline koristamine, sest sülearvuti, mis hoiab pärast katkestamist ettevõtte DNS-i, ei suuda enam midagi muud lahendada.

Sümptom neli: portaal töötab ja CLI ei tööta

Hiljutised tulemüüri väljalasked on vahetarkvara brauserist kohalikku Java-deemonisse viinud, nii et portaal räägib kohaliku agendiga pordil 14186. See aadress vajab brauseri sertifikaadi erandit ja töötavat protsessi.

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

Käsurida on eraldi tee: snx -s vpn.example.com -u user, kusjuures ~/.snxrc hoiab serverit, kasutajanime ja uuesti autentimise eelistust. Töötav portaalisessioon ei ütle midagi selle kohta, kas CLI on õigesti paigaldatud, ja paljas klient ei käsitle ühekordseid koode.

Konteineri otsetee, mis maksab rohkem kui säästab

snx kontrollib tun-moodulit, laadib selle puudumisel, loob tunneliliidese, kirjutab marsruudid ümber ja surub liikluse sellest läbi. Selle konteineris taasesitamine tähendab /dev ja /lib/modules monteerimist ning laiade õiguste andmist, mis annab konteinerile suurema osa hosti võrguhaldusest.

Kui liivakast on tõesti vajalik, on virtuaalmasin puhtam piir: klient saab kerneli, mida ta võib muuta, ja host hoiab oma marsruutimistabelit. Valige see enne, kui kulutate pärastlõuna õigustele, mida kahetsete andnud olevat.

Seotud artiklid