Check Point VPN op Linux: SNX is geen download die je installeert

Je zoekt de Check Point-client voor Linux en vindt geen downloadpagina met een installer. Dat ontbreken is geen gat in de verpakking. De Linux-client voor remote access van Check Point is SSL Network Extender, SNX, en de gateway overhandigt hem aan je nadat je je in een browser hebt aangemeld. Als dat eenmaal valt, is de rest van de verwarring logisch, inclusief waarom bijna elk bericht erover jaren oud is.

De mythe: er is een client die je downloadt en installeert

Die verwachting komt van elke andere leverancier. OpenVPN, WireGuard en de meeste commerciële clients publiceren een pakket of een repository, en installeren is een lokale beslissing die je alleen neemt. Check Point werkt op Linux niet zo. In de officiële downloads voor huidige gatewayversies staat geen zelfstandige installer, dus zoeken levert alleen oude forumthreads en spiegels van derden op.

Die spiegels zijn erger dan nutteloos, want de build moet passen bij de gateway die hem serveert.

Wat SNX werkelijk is, en waar het vandaan komt

SNX is een commandoregelclient waarvan het binaire bestand snx heet, en hij wordt geïnstalleerd via een sessie die je in de browser tegen de gateway start. Historisch laadde en installeerde een Java-applet hem nadat je de prompt had aanvaard. Het mechanisme is in de loop der jaren veranderd, de bron niet. De gateway serveert de build die bij hemzelf past, daarom lopen client- en gatewayversies gelijk op, en daarom werkt een client die uit een oud pakket is gekopieerd alleen zolang de gateway nog met hem praat.

Dat betekent ook dat de gateway klaar moet zijn voordat enig werk aan de client iets uitmaakt. Mobile Access Software Blade moet gelicentieerd en geconfigureerd zijn, want zonder dat is er geen portaal om vanaf te installeren. Geen enkele inspanning aan de kant van de client levert een sessie op tegen een gateway die er geen biedt.

Richt de client met je gebruiker op de gateway, en lees wat hij meldt:

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

De beperking is distributieondersteuning, niet de installer

De lijst met ondersteunde distributies van de leverancier voor SNX is kort en oud. In het gepubliceerde artikel stopt hij rond Ubuntu 17.04, naast een paar openSUSE-, Fedora- en RHEL-releases uit dezelfde tijd, en hij vermeldt nog steeds Ubuntu 12.10. Dat zegt hoe de lijst veroudert, niet wat je machine nodig heeft. Een actuele distributie staat er simpelweg niet op.

Verwacht bibliotheekconflicten voordat je een werkende tunnel verwacht. De gebruikelijke drie zijn ontbrekende 32-bits bibliotheken op een 64-bits systeem, een OpenSSL-versie waartegen het binaire bestand nooit is gelinkt, en een kernelmodule die de client probeert te bouwen. Lees de ontbrekende symbolen in plaats van te gokken op pakketten:

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

Controleer daarna het supportartikel voor de gatewayrelease waarmee je echt verbindt. Een lijst in een blog is geen compatibiliteitsverklaring, en een nieuwere distributie betekent geen nieuwere client.

Het X11-detail dat werk zonder scherm mogelijk maakt

SNX heeft X11-bibliotheken nodig maar geen draaiende X-server. Dat onderscheid is het hele verschil tussen een client die via SSH op een host zonder scherm werkt en een die zonder enige uitvoer lijkt te hangen. Installeer het bibliotheekpakket van je eigen distributie in plaats van een bundel uit een andere release, en start de client vanuit de sessie die de tunnel nodig heeft.

Nadat hij is verbonden,lees de interface en de routes voordat je een van beide vertrouwt:

ip -brief addr show
ip route show

SNX maakt een tunnelinterface en installeert de routes die het portaal bepaalt. Die routes zijn een beslissing van de gateway en niet van jou, dus een ontbrekende prefix is een profielprobleem aan de gatewaykant en geen bug in de client. Controleer tegelijk DNS, want split-tunnelprofielen duwen vaak een resolver naar voren die je niet verwachtte.

Wanneer SNX volstrekt het verkeerde antwoord is

Check Point-gateways kunnen ook IPsec- enL2TPclient-naar-site-verbindingen beëindigen, en die werken met strongSwan, Libreswan of de L2TP-plug-in van NetworkManager. Dat is een gatewayconfiguratie, geen truc van de client. Als de gateway alleen het Mobile Access-portaal publiceert,heeft een IPsec-client niets om over te onderhandelen, en het log toont een time-out in plaats van een authenticatiefout. Vraag welke remote-access-blades aanstaan voordat je iets anders installeert.

Elke beperking hier zit aan de gatewaykant: de blade, de licentie, de clientbuild en het routeprofiel. De CLI werkt al jaren. Wat breekt, is de aanname dat Linux-ondersteuning een pakket betekent dat je bezit en beheert.