Check Point VPN unter Linux: SNX ist kein Download, den man installiert

Sie suchen den Check-Point-Client für Linux und finden keine Downloadseite mit einem Installer. Dieses Fehlen ist keine Lücke im Packaging. Der Linux-Client für den Fernzugriff von Check Point ist SSL Network Extender, SNX, und das Gateway übergibt ihn Ihnen, nachdem Sie sich in einem Browser authentifiziert haben. Sobald das sitzt, ergibt der Rest der Verwirrung Sinn, auch die Frage, warum fast jeder Beitrag dazu Jahre alt ist.

Der Mythos: es gibt einen Client, den man herunterlädt und installiert

Die Erwartung kommt von allen anderen Anbietern. OpenVPN, WireGuard und die meisten kommerziellen Clients veröffentlichen ein Paket oder ein Repository, und die Installation ist eine lokale Entscheidung, die Sie allein treffen. Check Point funktioniert unter Linux nicht so. In den offiziellen Downloads für aktuelle Gateway-Versionen gibt es keinen eigenständigen Installer, daher fördert die Suche danach nur alte Forenthreads und Spiegel Dritter zutage.

Diese Spiegel sind schlimmer als nutzlos, weil der Build zum Gateway passen muss, das ihn ausliefert.

Was SNX eigentlich ist und woher es kommt

SNX ist ein Kommandozeilenclient, dessen Binärdatei snx heißt, und er wird über eine Sitzung installiert, die Sie im Browser gegen das Gateway starten. Historisch lud ein Java-Applet ihn herunter und installierte ihn, nachdem Sie der Aufforderung zugestimmt hatten. Der Mechanismus hat sich über die Jahre geändert, die Quelle nicht. Das Gateway liefert den Build aus, der zu ihm selbst passt, weshalb Client- und Gateway-Versionen einander folgen und weshalb ein aus einem alten Paket kopierter Client nur funktioniert, solange das Gateway noch mit ihm spricht.

Das bedeutet auch, dass das Gateway bereit sein muss, bevor irgendeine Arbeit am Client zählt. Mobile Access Software Blade muss lizenziert und konfiguriert sein, denn ohne es gibt es kein Portal, von dem aus installiert werden könnte. Kein noch so großer Aufwand auf Clientseite erzeugt eine Sitzung gegen ein Gateway, das keine anbietet.

Richten Sie den Client mit Ihrem Benutzer auf das Gateway und lesen Sie, was er meldet:

snx -s vpn.example.com -u your.name

Die Einschränkung ist die Distributionsunterstützung, nicht der Installer

Die Liste der unterstützten Distributionen des Herstellers für SNX ist kurz und alt. Im veröffentlichten Artikel endet sie um Ubuntu 17.04, zusammen mit einigen openSUSE-, Fedora- und RHEL-Versionen aus derselben Zeit, und sie führt immer noch Ubuntu 12.10 auf. Das sagt Ihnen, wie die Liste altert, nicht was Ihr Rechner braucht. Eine aktuelle Distribution steht schlicht nicht darauf.

Rechnen Sie mit Bibliothekskonflikten, bevor Sie mit einem funktionierenden Tunnel rechnen. Die üblichen drei sind fehlende 32-Bit-Bibliotheken auf einem 64-Bit-System, eine OpenSSL-Version, gegen die die Binärdatei nie gelinkt wurde, und ein Kernelmodul, das der Client zu bauen versucht. Lesen Sie die fehlenden Symbole, statt bei Paketen zu raten:

ldd $(command -v snx) | grep "not found"

Prüfen Sie dann den Supportartikel für die Gateway-Version, mit der Sie sich tatsächlich verbinden. Eine Liste in einem Blog ist keine Kompatibilitätserklärung, und eine neuere Distribution bedeutet keinen neueren Client.

Das X11-Detail, das kopfloses Arbeiten möglich macht

SNX braucht X11-Bibliotheken, aber keinen laufenden X-Server. Dieser Unterschied ist der ganze Unterschied zwischen einem Client, der über SSH auf einem Host ohne Bildschirm funktioniert, und einem, der ohne Ausgabe zu hängen scheint. Installieren Sie das Bibliothekspaket Ihrer Distribution statt eines aus einer anderen Version kopierten Bündels und starten Sie den Client aus der Sitzung, die den Tunnel braucht.

Nachdem er verbunden ist,lesen Sie die Schnittstelle und die Routen, bevor Sie einer von beiden trauen:

ip -brief addr show
ip route show

SNX erstellt eine Tunnelschnittstelle und installiert die Routen, die das Portal vorgibt. Diese Routen sind die Entscheidung des Gateways und nicht Ihre, ein fehlendes Präfix ist also ein Profilproblem auf der Gateway-Seite und kein Clientfehler. Prüfen Sie gleichzeitig DNS, denn Split-Tunnel-Profile schieben oft einen Resolver unter, den Sie nicht erwartet haben.

Wenn SNX die völlig falsche Antwort ist

Check-Point-Gateways können auch IPsec- undL2TP-Client-zu-Standort-Verbindungen terminieren, und diese funktionieren mit strongSwan, Libreswan oder dem L2TP-Plugin von NetworkManager. Das ist eine Gateway-Konfiguration, kein Client-Trick. Wenn das Gateway nur das Mobile-Access-Portal veröffentlicht,hat ein IPsec-Client nichts auszuhandeln, und das Protokoll zeigt einen Timeout statt eines Authentifizierungsfehlers. Fragen Sie, welche Fernzugriffs-Blades aktiviert sind, bevor Sie irgendetwas anderes installieren.

Jede Einschränkung hier liegt auf der Gateway-Seite: das Blade, die Lizenz, der Client-Build und das Routenprofil. Die CLI funktioniert seit Jahren. Was bricht, ist die Annahme, Linux-Unterstützung bedeute ein Paket, das man besitzt und kontrolliert.