SNX på Linux: 32-bit biblioteker og en resolver, der nulstilles

SNX på Linux fejler ved loaderen, rutetabellen eller resolveren, og hver af fejlene ser ud som et loginproblem. Arbejd de fire symptomer igennem i rækkefølge.

Check Points SSL Network Extender fejler på Linux på fire genkendelige måder, og tre af dem læses forkert som et loginproblem. Enten starter binæren ikke, eller den starter og efterlader ingen rute, eller den forbinder og navneopløsningen dør, eller browserportalen virker, mens kommandolinjen ikke gør. Arbejd dem igennem i den rækkefølge, fordi hver af dem er adgangsbetingelsen for den næste.

Symptom et: loaderen afviser før login

Installationsprogrammet, der hentes fra firefallen, lægger en 32-bit binær med setuid-root i /usr/bin/snx. På en 64-bit distribution kører den ikke, før i386-arkitekturen er aktiveret, og de biblioteker, den linkes mod, findes.

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 det efterfølgende. Det præcise pakkesæt flytter sig mellem udgivelser: en fungerende rapport krævede libstdc++5:i386, libx11-6:i386 og libpam0g:i386, en anden krævede også libstdc++6:i386. Læs ldd i stedet for at kopiere en pakkeliste fra en vejledning skrevet til en anden distribution.

Hvis snx slet ikke findes, blev installationsprogrammet aldrig færdigt eller installerede et sted uden for din PATH. Det er en anden fejl, og det er værd at bekræfte den, før du tilføjer arkitekturer til systemet. Kontroller med command -v snx, og kig i den mappe, installationsprogrammet rapporterede. At tilføje i386-pakker til en maskine, hvor binæren simpelthen mangler, retter ingenting.

Symptom to: login lykkes, og intet routes

Et vellykket login opretter tunsnx og redigerer selv rutetabellen, så kontroller, hvad der faktisk findes, før du ændrer noget andet.

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

Brug snx -d til nedtagning. At dræbe processen efterlader interfacet og dets ruter, og det næste forsøg fejler så af en grund, der intet har med legitimationsoplysninger at gøre. Det første login registrerer også en serversignatur under /etc/snx/, og derfor kan et uovervåget script have brug for en interaktiv kørsel, før det overhovedet kan virke. Slet kun den tilstand, når du agter at godkende serveren igen.

Symptom tre: navne opløses, indtil tunnelen kommer op

Det er den, der stille går i stykker. snx skriver skubbede DNS-servere direkte ind i /etc/resolv.conf. Hvor den sti er et symbolsk link ind i /run/systemd/resolve/, kan ændringen gå tabt ved den næste resolverhændelse, og efter en afbrydelse kan de skubbede poster lige så godt blive hængende.

To ordninger virker, og valget bør være bevidst i stedet for hvad end det første søgeresultat foreslog:

  • Overtag filen: erstat det symbolske link med en statisk fil, og installer libnss-resolve plus dens i386-variant, så navnetjenesten stadig har en fallback, når filen bliver skrevet om under den.
  • Behold systemd-resolved som ejer, og registrer tunnel-linket: resolvectl dns tunsnx 10.0.0.10, derefter resolvectl domain tunsnx corp.example, og bekræft med resolvectl status.

Noter navneserverne før VPN, før du forbinder. Redigerer du filen i hånden, er fjernelsen af de skubbede poster bagefter en del af proceduren, ikke valgfri oprydning, fordi en bærbar computer, der beholder virksomhedens DNS efter afbrydelse, ikke kan opløse noget andet.

Symptom fire: portalen virker, og CLI’en gør ikke

Nyere firewall-udgivelser har flyttet middleware ud af browseren til en lokal Java-daemon, så portalen taler med en lokal agent på port 14186. Den adresse kræver en browsercertifikatundtagelse og en kørende proces.

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

Kommandolinjen er en separat vej: snx -s vpn.example.com -u user, hvor ~/.snxrc holder serveren, brugernavnet og indstillingen for gentagen godkendelse. En fungerende portalsession siger intet om, hvorvidt CLI’en er installeret korrekt, og den bare klient håndterer ikke engangskoder.

Container-genvejen, der koster mere, end den sparer

snx tjekker for tun-modulet, indlæser det, når det mangler, opretter et tunnelinterface, omskriver ruter og skubber trafik igennem det. At genskabe det inde i en container betyder at montere /dev og /lib/modules og give brede rettigheder, hvilket giver containeren det meste af værtens netværksadministration.

Når en sandkasse virkelig er nødvendig, er en virtuel maskine den renere grænse: klienten får en kerne, den må ændre, og værten beholder sin rutetabel. Vælg det, før du bruger en eftermiddag på rettigheder, du vil fortryde at give.

Relaterede artikler