SNX på Linux: 32-bitars bibliotek og ein resolver som nullstiller seg

SNX på Linux feilar ved lastaren, rutetabellen eller resolveren, og kvar av feila ser ut som eit påloggingsproblem. Arbeid deg gjennom dei fire symptoma i rekkefølgje.

Check Point sin SSL Network Extender feilar på Linux på fire gjenkjennelege måtar, og tre av dei vert lesne feil som eit påloggingsproblem. Anten startar ikkje binæren, eller han startar og etterlét ingen rute, eller han koplar til og namneoppslaget døyr, eller nettlesarportalen verkar medan kommandolinja ikkje gjer det. Arbeid deg gjennom dei i den rekkefølgja, fordi kvar av dei er inngangsvilkåret for den neste.

Symptom éin: lastaren nektar før pålogginga

Installasjonsprogrammet som vert henta frå brannmuren, legg ein 32-bitars binær med setuid-root i /usr/bin/snx. På ein 64-bitars distribusjon køyrer han ikkje før i386-arkitekturen er aktivert og biblioteka han lenkjar mot finst.

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"

Ei tom not found-liste er porten for alt som følgjer. Det nøyaktige pakkesettet endrar seg mellom utgivingar: éin fungerande rapport trong libstdc++5:i386, libx11-6:i386 og libpam0g:i386, ein annan trong også libstdc++6:i386. Les ldd i staden for å kopiere ei pakkeliste frå ei rettleiing skriven for ein annan distribusjon.

Viss snx ikkje finst i det heile, vart installasjonen aldri fullført eller han installerte ein stad utanfor PATH-en din. Det er ein annan feil, og han er verd å stadfeste før du legg arkitekturar til systemet. Kontroller med command -v snx og sjå i katalogen installasjonsprogrammet rapporterte. Å leggje i386-pakkar til ein maskin der binæren rett og slett manglar, rettar ingenting.

Symptom to: pålogginga lukkast og ingenting vert ruta

Ei vellukka pålogging opprettar tunsnx og redigerer rutetabellen sjølv, så kontroller kva som faktisk finst før du endrar noko anna.

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

Bruk snx -d for å rive ned. Å drepe prosessen etterlét grensesnittet og rutene, og det neste forsøket feilar då av ein grunn som ikkje har noko med påloggingsdata å gjere. Den første pålogginga registrerer også ein serversignatur under /etc/snx/, og difor kan eit uovervaka skript trenge éi interaktiv køyring før det i det heile kan verke. Slett berre den tilstanden når du har tenkt å godkjenne serveren på nytt.

Symptom tre: namn vert løyste opp til tunnelen kjem opp

Dette er den som stille går i stykke. snx skriv dytta DNS-tenarar rett inn i /etc/resolv.conf. Der den stien er ei symbolsk lenkje inn i /run/systemd/resolve/, kan endringa gå tapt ved neste resolver-hending, og etter ein fråkobling kan dei dytta oppføringane like godt verte ståande.

To ordningar verkar, og valet bør vere medvite i staden for det første søkjeresultatet føreslo:

  • Overta fila: byt ut den symbolske lenkja med ei statisk fil og installer libnss-resolve pluss i386-varianten, slik at namnetenesta framleis har ein reserve når fila vert skriven på nytt under henne.
  • Hald systemd-resolved som eigar og registrer tunnel-lenkja: resolvectl dns tunsnx 10.0.0.10, deretter resolvectl domain tunsnx corp.example, og stadfest med resolvectl status.

Noter namnetenarane frå før VPN-en før du koplar til. Viss du redigerer fila for hand, er det å fjerne dei dytta oppføringane etterpå ein del av prosedyren, ikkje valfri opprydding, fordi ein berbar datamaskin som held på bedrifts-DNS-en etter fråkobling, ikkje kan slå opp noko anna.

Symptom fire: portalen verkar og CLI-en gjer det ikkje

Nylege brannmur-utgivingar har flytta mellomvaren frå nettlesaren til ein lokal Java-demon, så portalen snakkar med ein lokal agent på port 14186. Den adressa treng eit nettlesarsertifikat-unntak og ein køyrande prosess.

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

Kommandolinja er ein eigen sti: snx -s vpn.example.com -u user, der ~/.snxrc held serveren, brukarnamnet og innstillinga for gjenteken autentisering. Ei fungerande portalløkt seier ingenting om korvidt CLI-en er rett installert, og den bare klienten handterer ikkje eingongskodar.

Snarvegen med container som kostar meir enn han sparer

snx sjekkar tun-modulen, lastar han når han manglar, opprettar eit tunnelsenitt, skriv om ruter og dyttar trafikk gjennom det. Å gjenskape det i ein container tyder å montere /dev og /lib/modules og gje breie rettar, noko som gjev containeren det meste av nettverksadministrasjonen til verten.

Når ein sandkasse verkeleg er naudsynt, er ein virtuell maskin den reinaste grensa: klienten får ein kjerne han kan endre, og verten held på rutetabellen sin. Vel det før du brukar ein ettermiddag på rettar du vil angre på at du gav.

Relaterte artiklar