SNX på Linux: 32-biters biblioteker og en resolver som nullstilles

SNX på Linux feiler ved lasteren, rutetabellen eller resolveren, og hver av feilene ser ut som et påloggingsproblem. Arbeid deg gjennom de fire symptomene i rekkefølge.

Check Points SSL Network Extender feiler på Linux på fire gjenkjennelige måter, og tre av dem leses feil som et påloggingsproblem. Enten starter ikke binæren, eller den starter og etterlater ingen rute, eller den kobler til og navneoppslaget dør, eller nettleserportalen virker mens kommandolinjen ikke gjør det. Arbeid deg gjennom dem i den rekkefølgen, fordi hver av dem er inngangsbetingelsen for den neste.

Symptom én: lasteren nekter før påloggingen

Installasjonsprogrammet som hentes fra brannmuren, legger en 32-biters binær med setuid-root i /usr/bin/snx. På en 64-biters distribusjon kjører den ikke før i386-arkitekturen er aktivert og bibliotekene den lenker mot finnes.

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"

En tom not found-liste er porten for alt som følger. Det nøyaktige pakkesettet endrer seg mellom utgivelser: én fungerende rapport trengte libstdc++5:i386, libx11-6:i386 og libpam0g:i386, en annen trengte også libstdc++6:i386. Les ldd i stedet for å kopiere en pakkeliste fra en veiledning skrevet for en annen distribusjon.

Hvis snx ikke finnes i det hele tatt, ble installasjonen aldri fullført eller den installerte et sted utenfor PATH-en din. Det er en annen feil, og den er verdt å bekrefte før du legger arkitekturer til systemet. Kontroller med command -v snx og se i katalogen installasjonsprogrammet rapporterte. Å legge i386-pakker til en maskin der binæren rett og slett mangler, retter ingenting.

Symptom to: påloggingen lykkes og ingenting rutes

En vellykket pålogging oppretter tunsnx og redigerer rutetabellen selv, så kontroller hva som faktisk finnes før du endrer noe annet.

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

Bruk snx -d for å rive ned. Å drepe prosessen etterlater grensesnittet og rutene, og det neste forsøket feiler da av en grunn som ikke har noe med påloggingsdata å gjøre. Den første påloggingen registrerer også en serversignatur under /etc/snx/, og derfor kan et uovervåket skript trenge én interaktiv kjøring før det i det hele tatt kan virke. Slett bare den tilstanden når du har tenkt å godkjenne serveren på nytt.

Symptom tre: navn løses opp til tunnelen kommer opp

Dette er den som stille går i stykker. snx skriver dyttede DNS-servere rett inn i /etc/resolv.conf. Der den stien er en symbolsk lenke inn i /run/systemd/resolve/, kan endringen gå tapt ved neste resolver-hendelse, og etter en frakobling kan de dyttede oppføringene like godt bli stående.

To ordninger virker, og valget bør være bevisst i stedet for det første søkeresultatet foreslo:

  • Overta filen: erstatt den symbolske lenken med en statisk fil og installer libnss-resolve pluss i386-varianten, slik at navnetjenesten fortsatt har en reserve når filen skrives på nytt under den.
  • Behold systemd-resolved som eier og registrer tunnel-lenken: resolvectl dns tunsnx 10.0.0.10, deretter resolvectl domain tunsnx corp.example, og bekreft med resolvectl status.

Noter navneserverne fra før VPN-en før du kobler til. Hvis du redigerer filen for hånd, er det å fjerne de dyttede oppføringene etterpå en del av prosedyren, ikke valgfri opprydding, fordi en bærbar datamaskin som beholder bedrifts-DNS-en etter frakobling, ikke kan slå opp noe annet.

Symptom fire: portalen virker og CLI-en gjør det ikke

Nylige brannmur-utgivelser har flyttet mellomvaren fra nettleseren til en lokal Java-demon, så portalen snakker med en lokal agent på port 14186. Den adressen trenger et nettlesersertifikat-unntak og en kjørende prosess.

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

Kommandolinjen er en egen sti: snx -s vpn.example.com -u user, der ~/.snxrc holder serveren, brukernavnet og innstillingen for gjentatt autentisering. En fungerende portalløkt sier ingenting om hvorvidt CLI-en er riktig installert, og den bare klienten håndterer ikke engangskoder.

Snarveien med container som koster mer enn den sparer

snx sjekker tun-modulen, laster den når den mangler, oppretter et tunnelgrensesnitt, skriver om ruter og dytter trafikk gjennom det. Å gjenskape det i en container betyr å montere /dev og /lib/modules og gi brede rettigheter, noe som gir containeren det meste av vertens nettverksadministrasjon.

Når en sandkasse virkelig er nødvendig, er en virtuell maskin den renere grensen: klienten får en kjerne den kan endre, og verten beholder rutetabellen sin. Velg det før du bruker en ettermiddag på rettigheter du vil angre på at du ga.

Relaterte artikler