SNX sous Linux : bibliothèques 32 bits et un résolveur qui se réinitialise

SNX sous Linux échoue au chargeur, à la table de routage ou au résolveur, et chacun de ces échecs ressemble à un problème de connexion. Traitez les quatre symptômes dans l’ordre.

L’SSL Network Extender de Check Point échoue sous Linux de quatre manières reconnaissables, et trois d’entre elles sont lues à tort comme un problème de connexion. Soit le binaire ne démarre pas, soit il démarre et ne laisse aucune route, soit il se connecte et la résolution de noms meurt, soit le portail du navigateur fonctionne tandis que la ligne de commande non. Traitez-les dans cet ordre, car chacun est la condition d’entrée du suivant.

Symptôme un : le chargeur refuse avant la connexion

L’installateur récupéré depuis le pare-feu dépose un binaire 32 bits avec setuid-root dans /usr/bin/snx. Sur une distribution 64 bits, il ne s’exécute pas tant que l’architecture i386 n’est pas activée et que les bibliothèques contre lesquelles il est lié n’existent pas.

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"

Une liste not found vide est la porte pour tout ce qui suit. L’ensemble exact des paquets évolue entre les versions : un rapport qui fonctionnait exigeait libstdc++5:i386, libx11-6:i386 et libpam0g:i386, un autre exigeait aussi libstdc++6:i386. Lisez ldd au lieu de copier une liste de paquets depuis un tutoriel écrit pour une autre distribution.

Si snx est totalement introuvable, l’installateur ne s’est jamais terminé ou s’est installé quelque part hors de votre PATH. C’est une autre panne, et il vaut la peine de la confirmer avant d’ajouter des architectures au système. Vérifiez avec command -v snx et regardez dans le répertoire signalé par l’installateur. Ajouter des paquets i386 sur une machine où le binaire est simplement absent ne répare rien.

Symptôme deux : la connexion réussit et rien n’est routé

Une connexion réussie crée tunsnx et modifie elle-même la table de routage, alors vérifiez ce qui existe réellement avant de changer autre chose.

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

Utilisez snx -d pour démonter. Tuer le processus laisse l’interface et ses routes derrière lui, et la tentative suivante échoue alors pour une raison qui n’a rien à voir avec les identifiants. La première connexion enregistre aussi une signature de serveur sous /etc/snx/, ce qui explique qu’un script non surveillé puisse avoir besoin d’une exécution interactive avant de pouvoir fonctionner. Ne supprimez cet état que lorsque vous comptez réapprouver le serveur.

Symptôme trois : les noms se résolvent jusqu’à ce que le tunnel monte

C’est celui qui casse en silence. snx écrit les serveurs DNS poussés directement dans /etc/resolv.conf. Là où ce chemin est un lien symbolique vers /run/systemd/resolve/, la modification peut se perdre au prochain événement du résolveur, et après une déconnexion les entrées poussées peuvent tout aussi bien rester.

Deux arrangements fonctionnent, et le choix doit être délibéré plutôt que celui suggéré par le premier résultat de recherche :

  • Reprenez le fichier : remplacez le lien symbolique par un fichier statique et installez libnss-resolve ainsi que sa variante i386, afin que le service de noms conserve un repli lorsque le fichier est réécrit en dessous.
  • Gardez systemd-resolved comme propriétaire et enregistrez le lien du tunnel : resolvectl dns tunsnx 10.0.0.10, puis resolvectl domain tunsnx corp.example, et confirmez avec resolvectl status.

Notez les serveurs de noms d’avant le VPN avant de vous connecter. Si vous modifiez le fichier à la main, retirer ensuite les entrées poussées fait partie de la procédure, ce n’est pas un nettoyage facultatif, car un portable qui conserve le DNS d’entreprise après la déconnexion ne pourra plus rien résoudre d’autre.

Symptôme quatre : le portail fonctionne et la CLI non

Les versions récentes du pare-feu ont déplacé l’intergiciel du navigateur vers un démon Java local, si bien que le portail parle à un agent local sur le port 14186. Cette adresse exige une exception de certificat dans le navigateur et un processus en cours d’exécution.

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

La ligne de commande est un chemin distinct : snx -s vpn.example.com -u user, avec ~/.snxrc qui conserve le serveur, le nom d’utilisateur et la préférence de réauthentification. Une session de portail qui fonctionne ne dit rien sur le fait que la CLI soit correctement installée, et le client nu ne gère pas les codes à usage unique.

Le raccourci conteneur qui coûte plus qu’il n’économise

snx vérifie le module tun, le charge lorsqu’il manque, crée une interface de tunnel, réécrit les routes et y pousse le trafic. Reproduire cela dans un conteneur signifie monter /dev et /lib/modules et accorder de larges capacités, ce qui confie au conteneur l’essentiel de l’administration réseau de l’hôte.

Lorsqu’un bac à sable est vraiment nécessaire, une machine virtuelle est la frontière la plus propre : le client reçoit un noyau qu’il peut modifier, et l’hôte conserve sa table de routage. Choisissez cela avant de passer un après-midi sur des capacités que vous regretterez d’avoir accordées.

Articles similaires