SNX op Linux: 32-bits bibliotheken en een resolver die zich reset

SNX op Linux faalt bij de loader, de routetabel of de resolver, en elk van die fouten lijkt op een inlogprobleem. Werk de vier symptomen op volgorde af.

De SSL Network Extender van Check Point faalt op Linux op vier herkenbare manieren, en drie ervan worden verkeerd gelezen als een inlogprobleem. Ofwel de binary start niet, ofwel hij start en laat geen route achter, ofwel hij verbindt en naamresolutie sterft, ofwel het browserportaal werkt terwijl de opdrachtregel dat niet doet. Werk ze in die volgorde af, want elk is de toegangsvoorwaarde voor de volgende.

Symptoom een: de loader weigert vóór het inloggen

De installateur die van de firewall wordt gehaald, plaatst een 32-bits binary met setuid-root in /usr/bin/snx. Op een 64-bits distributie draait hij niet voordat de i386-architectuur is ingeschakeld en de bibliotheken waartegen hij linkt bestaan.

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"

Een lege not found-lijst is de poort voor alles daarna. De exacte pakketreeks verschuift tussen releases: een werkend rapport had libstdc++5:i386, libx11-6:i386 en libpam0g:i386 nodig, een ander had ook libstdc++6:i386 nodig. Lees ldd in plaats van een pakketlijst te kopiëren uit een handleiding die voor een andere distributie is geschreven.

Als snx helemaal niet wordt gevonden, is de installateur nooit voltooid of heeft hij zich ergens buiten je PATH geïnstalleerd. Dat is een andere fout, en het is de moeite waard om die te bevestigen voordat je architecturen aan het systeem toevoegt. Controleer met command -v snx en kijk in de map die de installateur meldde. i386-pakketten toevoegen aan een machine waar de binary simpelweg ontbreekt, lost niets op.

Symptoom twee: het inloggen slaagt en niets wordt gerouteerd

Een geslaagde login maakt tunsnx aan en bewerkt zelf de routetabel, dus controleer wat er werkelijk bestaat voordat je iets anders verandert.

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

Gebruik snx -d om af te breken. Het doden van het proces laat de interface en zijn routes achter, en de volgende poging mislukt dan om een reden die niets met inloggegevens te maken heeft. De eerste login registreert ook een serversignatuur onder /etc/snx/, waardoor een onbeheerd script één interactieve run nodig kan hebben voordat het überhaupt werkt. Verwijder die toestand alleen als je de server opnieuw wilt goedkeuren.

Symptoom drie: namen worden opgelost tot de tunnel omhoog komt

Dit is degene die stil kapotgaat. snx schrijft geduwde DNS-servers rechtstreeks in /etc/resolv.conf. Waar dat pad een symbolische link in /run/systemd/resolve/ is, kan de wijziging verloren gaan bij de volgende resolver-gebeurtenis, en na een verbreking kunnen de geduwde vermeldingen net zo goed blijven staan.

Twee regelingen werken, en de keuze moet bewust zijn in plaats van wat het eerste zoekresultaat voorstelde:

  • Neem het bestand over: vervang de symbolische link door een statisch bestand en installeer libnss-resolve plus de i386-variant, zodat de naamdienst nog een terugval heeft wanneer het bestand eronder opnieuw wordt geschreven.
  • Houd systemd-resolved als eigenaar en registreer de tunnelkoppeling: resolvectl dns tunsnx 10.0.0.10, dan resolvectl domain tunsnx corp.example, en bevestig met resolvectl status.

Noteer de nameservers van vóór de VPN voordat je verbindt. Als je het bestand met de hand bewerkt, is het achteraf verwijderen van de geduwde vermeldingen deel van de procedure, geen optionele opruiming, want een laptop die na het verbreken de bedrijfs-DNS houdt, kan niets anders meer oplossen.

Symptoom vier: het portaal werkt en de CLI niet

Recente firewall-releases hebben de middleware uit de browser naar een lokale Java-daemon verplaatst, zodat het portaal met een lokale agent op poort 14186 praat. Dat adres heeft een browsercertificaat-uitzondering en een draaiend proces nodig.

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

De opdrachtregel is een apart pad: snx -s vpn.example.com -u user, waarbij ~/.snxrc de server, de gebruikersnaam en de voorkeur voor herauthenticatie vasthoudt. Een werkende portaalsessie zegt niets over of de CLI correct is geïnstalleerd, en de kale client verwerkt geen eenmalige codes.

De containerkortere weg die meer kost dan hij bespaart

snx controleert de tun-module, laadt die als hij ontbreekt, maakt een tunnelinterface, herschrijft routes en duwt verkeer erdoorheen. Dat in een container nabouwen betekent /dev en /lib/modules mounten en brede mogelijkheden geven, wat de container het grootste deel van het netwerkbeheer van de host geeft.

Wanneer een sandbox echt nodig is, is een virtuele machine de schonere grens: de client krijgt een kernel die hij mag wijzigen, en de host behoudt zijn routetabel. Kies dat voordat je een middag besteedt aan mogelijkheden die je zult betreuren.

Gerelateerde artikelen