SNX en Linux: bibliotecas de 32 bits y un resolutor que se reinicia

El SSL Network Extender de Check Point falla en Linux de cuatro maneras reconocibles, y tres de ellas se leen mal como un problema de inicio de sesión. O el binario no arranca, o arranca y no deja ninguna ruta, o se conecta y muere la resolución de nombres, o el portal del navegador funciona mientras la línea de comandos no. Abórdelos en ese orden, porque cada uno es la condición de entrada del siguiente.

Síntoma uno: el cargador se niega antes del inicio de sesión

El instalador descargado del cortafuegos deja un binario de 32 bits con setuid-root en /usr/bin/snx. En una distribución de 64 bits no se ejecuta hasta que se habilita la arquitectura i386 y existen las bibliotecas contra las que enlaza.

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 lista not found vacía es la puerta para todo lo que sigue. El conjunto exacto de paquetes cambia entre versiones: un informe que funcionaba necesitaba libstdc++5:i386, libx11-6:i386 y libpam0g:i386, otro también necesitaba libstdc++6:i386. Lea ldd en lugar de copiar una lista de paquetes de un tutorial escrito para otra distribución.

Si snx no aparece en absoluto, el instalador nunca terminó o se instaló en algún lugar fuera de su PATH. Ese es otro fallo, y vale la pena confirmarlo antes de añadir arquitecturas al sistema. Compruébelo con command -v snx y mire en el directorio que informó el instalador. Añadir paquetes i386 a una máquina donde el binario simplemente no está no arregla nada.

Síntoma dos: el inicio de sesión tiene éxito y nada se enruta

Un inicio de sesión correcto crea tunsnx y edita la tabla de rutas por sí mismo, así que compruebe qué existe realmente antes de cambiar cualquier otra cosa.

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

Use snx -d para desmontarlo. Matar el proceso deja atrás la interfaz y sus rutas, y el siguiente intento falla entonces por una razón que no tiene nada que ver con las credenciales. El primer inicio de sesión también registra una firma del servidor en /etc/snx/, por lo que un script desatendido puede necesitar una ejecución interactiva antes de poder funcionar. Borre ese estado solo cuando tenga la intención de volver a aprobar el servidor.

Síntoma tres: los nombres se resuelven hasta que sube el túnel

Este es el que se rompe en silencio. snx escribe los servidores DNS empujados directamente en /etc/resolv.conf. Donde esa ruta es un enlace simbólico dentro de /run/systemd/resolve/, la edición puede perderse en el siguiente evento del resolutor, y después de una desconexión las entradas empujadas también pueden quedarse.

Funcionan dos arreglos, y la elección debería ser deliberada y no la que sugirió el primer resultado de búsqueda:

• Quede con el archivo: sustituya el enlace simbólico por un archivo estático e instale libnss-resolve más su variante i386, para que el servicio de nombres siga teniendo un respaldo cuando el archivo se reescriba por debajo.
• Mantenga systemd-resolved como propietario y registre el enlace del túnel: resolvectl dns tunsnx 10.0.0.10, luego resolvectl domain tunsnx corp.example, y confirme con resolvectl status.

Anote los servidores de nombres anteriores a la VPN antes de conectarse. Si edita el archivo a mano, quitar las entradas empujadas después forma parte del procedimiento, no es una limpieza opcional, porque un portátil que conserva el DNS corporativo tras desconectarse no podrá resolver nada más.

Síntoma cuatro: el portal funciona y la CLI no

Las versiones recientes del cortafuegos han trasladado el middleware del navegador a un demonio Java local, así que el portal habla con un agente local en el puerto 14186. Esa dirección necesita una excepción de certificado en el navegador y un proceso en ejecución.

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

La línea de comandos es una ruta aparte: snx -s vpn.example.com -u user, con ~/.snxrc guardando el servidor, el nombre de usuario y la preferencia de reautenticación. Una sesión de portal que funciona no dice nada sobre si la CLI está instalada correctamente, y el cliente desnudo no maneja códigos de un solo uso.

El atajo del contenedor que cuesta más de lo que ahorra

snx comprueba el módulo tun, lo carga cuando falta, crea una interfaz de túnel, reescribe las rutas y empuja el tráfico a través de ella. Reproducir eso dentro de un contenedor significa montar /dev y /lib/modules y conceder capacidades amplias, lo que entrega al contenedor buena parte de la administración de red del anfitrión.

Cuando de verdad se necesita un entorno aislado, una máquina virtual es la frontera más limpia: el cliente recibe un núcleo que puede modificar, y el anfitrión conserva su tabla de rutas. Elíjalo antes de pasar una tarde en capacidades que lamentará haber concedido.