SNX a Linux: biblioteques de 32 bits i un resolutor que es reinicia

L’SSL Network Extender de Check Point falla a Linux de quatre maneres recognoscibles, i tres d’elles es llegeixen malament com un problema d’inici de sessió. O el binari no arrenca, o arrenca i no deixa cap ruta, o es connecta i la resolució de noms mor, o el portal del navegador funciona mentre que la línia d’ordres no. Tracteu-los en aquest ordre, perquè cadascun és la condició d’entrada del següent.

Símptoma u: el carregador refusa abans de l’inici de sessió

L’instal·lador baixat del tallafoc deixa un binari de 32 bits amb setuid-root a /usr/bin/snx. En una distribució de 64 bits no s’executa fins que s’habilita l’arquitectura i386 i existeixen les biblioteques amb què enllaça.

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"

Una llista not found buida és la porta per a tot el que ve després. El conjunt exacte de paquets canvia entre versions: un informe que funcionava necessitava libstdc++5:i386, libx11-6:i386 i libpam0g:i386, un altre també necessitava libstdc++6:i386. Llegiu ldd en lloc de copiar una llista de paquets d’un tutorial escrit per a una altra distribució.

Si snx no es troba en absolut, l’instal·lador no es va completar mai o es va instal·lar en algun lloc fora del vostre PATH. Aquesta és una fallada diferent, i val la pena confirmar-la abans d’afegir arquitectures al sistema. Comproveu-ho amb command -v snx i mireu al directori que va informar l’instal·lador. Afegir paquets i386 en una màquina on el binari simplement no hi és no arregla res.

Símptoma dos: la sessió s’inicia i no s’encamina res

Un inici de sessió correcte crea tunsnx i edita la taula d’encaminament ell mateix, així que comproveu què existeix realment abans de canviar res més.

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

Feu servir snx -d per desmuntar-ho. Matar el procés deixa la interfície i les seves rutes enrere, i el següent intent falla llavors per una raó que no té res a veure amb les credencials. El primer inici de sessió també registra una signatura del servidor a /etc/snx/, i per això un script no atès pot necessitar una execució interactiva abans de poder funcionar. Esborreu aquest estat només quan vulgueu tornar a aprovar el servidor.

Símptoma tres: els noms es resolen fins que puja el túnel

Aquest és el que es trenca en silenci. snx escriu els servidors DNS empenyats directament a /etc/resolv.conf. On aquest camí és un enllaç simbòlic dins de /run/systemd/resolve/, l’edició es pot perdre en el següent esdeveniment del resolutor, i després d’una desconnexió les entrades empenyades també poden quedar-s’hi.

Funcionen dos arranjaments, i l’elecció hauria de ser deliberada i no la que va suggerir el primer resultat de cerca:

• Quedeu-vos el fitxer: substituïu l’enllaç simbòlic per un fitxer estàtic i instal·leu libnss-resolve més la seva variant i386, perquè el servei de noms encara tingui un recurs alternatiu quan el fitxer es reescrigui a sota.
• Manteniu systemd-resolved com a propietari i registreu l’enllaç del túnel: resolvectl dns tunsnx 10.0.0.10, després resolvectl domain tunsnx corp.example, i confirmeu-ho amb resolvectl status.

Anoteu els servidors de noms previs a la VPN abans de connectar-vos. Si editeu el fitxer a mà, treure les entrades empenyades després forma part del procediment, no és una neteja opcional, perquè un portàtil que conserva el DNS corporatiu després de desconnectar-se no podrà resoldre res més.

Símptoma quatre: el portal funciona i la CLI no

Les versions recents del tallafoc han traslladat el middleware del navegador a un dimoni Java local, així que el portal parla amb un agent local al port 14186. Aquesta adreça necessita una excepció de certificat al navegador i un procés en marxa.

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

La línia d’ordres és un camí a part: snx -s vpn.example.com -u user, amb ~/.snxrc guardant el servidor, el nom d’usuari i la preferència de reautenticació. Una sessió de portal que funciona no diu res sobre si la CLI està instal·lada correctament, i el client nu no gestiona codis d’un sol ús.

La drecera del contenidor que costa més del que estalvia

snx comprova el mòdul tun, el carrega quan falta, crea una interfície de túnel, reescriu les rutes i hi fa passar el trànsit. Reproduir això dins d’un contenidor vol dir muntar /dev i /lib/modules i concedir capacitats àmplies, cosa que lliura al contenidor bona part de l’administració de xarxa de l’amfitrió.

Quan cal de veritat una caixa de proves, una màquina virtual és la frontera més neta: el client rep un nucli que pot modificar, i l’amfitrió conserva la seva taula de rutes. Trieu això abans de passar una tarda en capacitats que lamentareu haver concedit.