SNX unter Linux: 32-Bit-Bibliotheken und ein Resolver, der sich zurücksetzt

SNX unter Linux scheitert am Loader, an der Routentabelle oder am Resolver, und jeder dieser Fehler sieht wie ein Anmeldeproblem aus. Arbeiten Sie die vier Symptome der Reihe nach ab.

Check Points SSL Network Extender scheitert unter Linux auf vier erkennbare Arten, und drei davon werden fälschlich als Anmeldeproblem gelesen. Entweder startet das Binary nicht, oder es startet und hinterlässt keine Route, oder es verbindet und die Namensauflösung stirbt, oder das Browserportal funktioniert, während die Kommandozeile es nicht tut. Arbeiten Sie sie in dieser Reihenfolge ab, denn jedes ist die Eintrittsbedingung für das nächste.

Symptom eins: der Loader verweigert vor der Anmeldung

Der von der Firewall geholte Installer legt ein 32-Bit-Binary mit setuid-root unter /usr/bin/snx ab. Auf einer 64-Bit-Distribution läuft es nicht, bis die i386-Architektur aktiviert ist und die Bibliotheken existieren, gegen die es linkt.

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"

Eine leere not found-Liste ist das Tor für alles Weitere. Der genaue Paketsatz verschiebt sich zwischen Releases: ein funktionierender Bericht brauchte libstdc++5:i386, libx11-6:i386 und libpam0g:i386, ein anderer brauchte zusätzlich libstdc++6:i386. Lesen Sie ldd, statt eine Paketliste aus einem Tutorial zu kopieren, das für eine andere Distribution geschrieben wurde.

Wenn snx überhaupt nicht gefunden wird, wurde der Installer nie fertig oder hat irgendwo außerhalb Ihres PATH installiert. Das ist ein anderer Fehler, und es lohnt sich, ihn zu bestätigen, bevor Sie Architekturen zum System hinzufügen. Prüfen Sie mit command -v snx und schauen Sie in das Verzeichnis, das der Installer gemeldet hat. i386-Pakete auf einer Maschine zu installieren, auf der das Binary schlicht fehlt, repariert nichts.

Symptom zwei: die Anmeldung gelingt und nichts wird geroutet

Eine erfolgreiche Anmeldung erzeugt tunsnx und bearbeitet die Routentabelle selbst, prüfen Sie also, was tatsächlich existiert, bevor Sie etwas anderes ändern.

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

Verwenden Sie snx -d zum Abbauen. Das Töten des Prozesses hinterlässt die Schnittstelle und ihre Routen, und der nächste Versuch scheitert dann aus einem Grund, der nichts mit Anmeldedaten zu tun hat. Die erste Anmeldung zeichnet außerdem eine Serversignatur unter /etc/snx/ auf, weshalb ein unbeaufsichtigtes Skript einen interaktiven Lauf brauchen kann, bevor es überhaupt funktioniert. Löschen Sie diesen Zustand nur, wenn Sie den Server erneut genehmigen wollen.

Symptom drei: Namen werden aufgelöst, bis der Tunnel hochkommt

Das ist der, der leise kaputtgeht. snx schreibt geschobene DNS-Server direkt in /etc/resolv.conf. Wo dieser Pfad ein symbolischer Link nach /run/systemd/resolve/ ist, kann die Änderung beim nächsten Resolver-Ereignis verloren gehen, und nach einem Trennen können die geschobenen Einträge ebenso gut zurückbleiben.

Zwei Anordnungen funktionieren, und die Wahl sollte bewusst sein statt das, was das erste Suchergebnis vorschlug:

  • Übernehmen Sie die Datei: ersetzen Sie den symbolischen Link durch eine statische Datei und installieren Sie libnss-resolve samt seiner i386-Variante, damit der Namensdienst noch einen Rückfall hat, wenn die Datei darunter neu geschrieben wird.
  • Behalten Sie systemd-resolved als Eigentümer und registrieren Sie die Tunnelstrecke: resolvectl dns tunsnx 10.0.0.10, dann resolvectl domain tunsnx corp.example, und bestätigen Sie mit resolvectl status.

Notieren Sie die Nameserver vor dem VPN, bevor Sie sich verbinden. Wenn Sie die Datei von Hand bearbeiten, ist das Entfernen der geschobenen Einträge danach Teil des Verfahrens, keine optionale Aufräumarbeit, denn ein Laptop, der nach dem Trennen das Firmen-DNS behält, wird nichts anderes mehr auflösen.

Symptom vier: das Portal funktioniert und die CLI nicht

Neuere Firewall-Releases haben die Middleware aus dem Browser in einen lokalen Java-Daemon verschoben, sodass das Portal mit einem lokalen Agenten auf Port 14186 spricht. Diese Adresse braucht eine Browser-Zertifikatsausnahme und einen laufenden Prozess.

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

Die Kommandozeile ist ein eigener Pfad: snx -s vpn.example.com -u user, wobei ~/.snxrc den Server, den Benutzernamen und die Einstellung zur erneuten Authentifizierung hält. Eine funktionierende Portalsitzung sagt nichts darüber aus, ob die CLI korrekt installiert ist, und der nackte Client verarbeitet keine Einmalcodes.

Die Container-Abkürzung, die mehr kostet, als sie spart

snx prüft auf das tun-Modul, lädt es bei Fehlen, erstellt eine Tunnelschnittstelle, schreibt Routen um und schiebt den Verkehr hindurch. Das in einem Container nachzubauen bedeutet, /dev und /lib/modules einzubinden und weitreichende Fähigkeiten zu gewähren, was dem Container den größten Teil der Netzwerkverwaltung des Hosts übergibt.

Wenn eine Sandbox wirklich nötig ist, ist eine virtuelle Maschine die sauberere Grenze: Der Client bekommt einen Kernel, den er ändern darf, und der Host behält seine Routentabelle. Wählen Sie das, bevor Sie einen Nachmittag mit Fähigkeiten verbringen, die Sie bereuen werden zu vergeben.

Ähnliche Artikel