Check Point VPN sous Linux : SNX n'est pas un téléchargement à installer

Vous cherchez le client Check Point pour Linux et vous ne trouvez aucune page de téléchargement avec un installeur. Cette absence n'est pas un trou d'empaquetage. Le client d'accès distant de Check Point pour Linux est SSL Network Extender, SNX, et la passerelle vous le remet après que vous vous êtes authentifié dans un navigateur. Une fois cela posé, le reste de la confusion s'explique, y compris pourquoi presque tous les articles à ce sujet datent de plusieurs années.

Le mythe : il existerait un client que l'on télécharge et installe

L'attente vient de tous les autres éditeurs. OpenVPN, WireGuard et la plupart des clients commerciaux publient un paquet ou un dépôt, et installer l'un d'eux est une décision locale que vous prenez seul. Check Point ne fonctionne pas ainsi sous Linux. Il n'y a pas d'installeur autonome dans les téléchargements officiels pour les versions actuelles de passerelle, donc chercher cet installeur ne ramène que de vieux fils de forum et des miroirs tiers.

Ces miroirs sont pires qu'inutiles, car la compilation doit correspondre à la passerelle qui la sert.

Ce qu'est réellement SNX, et d'où il vient

SNX est un client en ligne de commande dont le binaire est snx, et il s'installe via une session que vous démarrez dans le navigateur contre la passerelle. Historiquement, une applet Java le téléchargeait et l'installait après que vous aviez accepté l'invite. Le mécanisme a changé au fil des ans, la source non. La passerelle sert la compilation qui lui correspond, c'est pourquoi les versions du client et de la passerelle vont de pair, et pourquoi un client copié depuis un vieux paquet ne fonctionne que tant que la passerelle lui parle encore.

Cela signifie aussi que la passerelle doit être prête avant que tout travail côté client ait un sens. Mobile Access Software Blade doit être licencié et configuré, car sans lui il n'y a pas de portail d'installation. Aucun effort côté client ne produit de session contre une passerelle qui n'en propose pas.

Pointez le client vers la passerelle avec votre utilisateur, et lisez ce qu'il rapporte :

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

La contrainte, c'est la prise en charge des distributions, pas l'installeur

La liste des distributions prises en charge par l'éditeur pour SNX est courte et ancienne. Dans l'article publié, elle s'arrête vers Ubuntu 17.04, aux côtés de quelques versions openSUSE, Fedora et RHEL de la même époque, et elle liste encore Ubuntu 12.10. Cela vous dit comment la liste vieillit, pas ce dont votre machine a besoin. Une distribution actuelle n'y figure tout simplement pas.

Attendez-vous à des incompatibilités de bibliothèques avant d'attendre un tunnel fonctionnel. Les trois habituelles sont des bibliothèques 32 bits manquantes sur un système 64 bits, une version d'OpenSSL avec laquelle le binaire n'a jamais été lié, et un module noyau que le client tente de compiler. Lisez les symboles manquants au lieu de deviner des paquets :

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

Consultez ensuite l'article de support de la version de passerelle à laquelle vous vous connectez réellement. Une liste sur un blog n'est pas une déclaration de compatibilité, et une distribution plus récente n'implique pas un client plus récent.

Le détail X11 qui rend le travail sans écran possible

SNX a besoin des bibliothèques X11 mais pas d'un serveur X en cours d'exécution. Cette distinction fait toute la différence entre un client qui fonctionne en SSH sur un hôte sans écran et un autre qui semble se figer sans aucune sortie. Installez le paquet de bibliothèques fourni par votre distribution plutôt qu'un lot copié d'une autre version, et lancez le client depuis la session qui a besoin du tunnel.

Une fois connecté,lisez l'interface et les routes avant de faire confiance à l'une ou à l'autre:

ip -brief addr show
ip route show

SNX crée une interface de tunnel et installe les routes définies par le portail. Ces routes relèvent de la passerelle et non de vous, donc un préfixe manquant est un problème de profil côté passerelle et non un bug du client. Vérifiez le DNS en même temps, car les profils à tunnel divisé poussent souvent un résolveur que vous n'attendiez pas.

Quand SNX est complètement la mauvaise réponse

Les passerelles Check Point peuvent aussi terminer des connexions IPsec etL2TPde client à site, et celles-ci fonctionnent avec strongSwan, Libreswan ou le greffon L2TP de NetworkManager. C'est une configuration de passerelle, pas une astuce de client. Si la passerelle ne publie que le portail Mobile Access,un client IPsec n'a rien avec quoi négocier, et le journal montre un délai d'attente au lieu d'un échec d'authentification. Demandez quelles lames d'accès distant sont activées avant d'installer quoi que ce soit d'autre.

Chaque contrainte ici vit côté passerelle : la lame, la licence, la compilation du client et le profil de routes. La CLI fonctionne depuis des années. Ce qui casse, c'est l'hypothèse que le support de Linux signifie un paquet que vous possédez et contrôlez.