Check Point VPN en Linux: SNX no es una descarga que se instala

Buscas el cliente de Check Point para Linux y no encuentras una página de descarga con un instalador. Esa ausencia no es un hueco de empaquetado. El cliente de acceso remoto de Check Point para Linux es SSL Network Extender, SNX, y la pasarela te lo entrega después de que te autentiques en un navegador. Cuando eso encaja, el resto de la confusión tiene sentido, incluido por qué casi todos los artículos sobre el tema tienen años.

El mito: hay un cliente que descargas e instalas

La expectativa viene de todos los demás proveedores. OpenVPN, WireGuard y la mayoría de los clientes comerciales publican un paquete o un repositorio, e instalar uno es una decisión local que tomas tú solo. Check Point no funciona así en Linux. No hay instalador autónomo en las descargas oficiales para las versiones actuales de la pasarela, así que buscar uno solo devuelve hilos antiguos de foros y espejos de terceros.

Esos espejos son peores que inútiles, porque la compilación tiene que coincidir con la pasarela que la sirve.

Qué es realmente SNX y de dónde sale

SNX es un cliente de línea de órdenes cuyo binario es snx, y se instala a través de una sesión que inicias en el navegador contra la pasarela. Históricamente lo descargaba e instalaba un applet de Java después de que aceptaras el aviso. El mecanismo ha cambiado con los años, la fuente no. La pasarela sirve la compilación que le corresponde, y por eso las versiones del cliente y de la pasarela van a la par, y por eso un cliente copiado de un paquete antiguo solo funciona mientras la pasarela sigue hablando con él.

Eso también significa que la pasarela tiene que estar lista antes de que cualquier trabajo en el cliente importe. Mobile Access Software Blade debe estar licenciado y configurado, porque sin él no hay portal desde el que instalar. Ningún esfuerzo del lado del cliente produce una sesión contra una pasarela que no ofrece ninguna.

Apunta el cliente a la pasarela con tu usuario y lee lo que informa:

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

La restricción es el soporte de distribuciones, no el instalador

La lista de distribuciones compatibles del proveedor para SNX es corta y antigua. En el artículo publicado se detiene hacia Ubuntu 17.04, junto a unas cuantas versiones de openSUSE, Fedora y RHEL de la misma época, y todavía incluye Ubuntu 12.10. Eso te dice cómo envejece la lista, no qué necesita tu máquina. Una distribución actual simplemente no está en ella.

Espera desajustes de bibliotecas antes de esperar un túnel funcional. Los tres habituales son bibliotecas de 32 bits que faltan en un sistema de 64 bits, una versión de OpenSSL contra la que el binario nunca se enlazó, y un módulo del núcleo que el cliente intenta compilar. Lee los símbolos que faltan en vez de adivinar paquetes:

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

Luego consulta el artículo de soporte de la versión de pasarela a la que te conectas de verdad. Una lista de un blog no es una declaración de compatibilidad, y una distribución más nueva no implica un cliente más nuevo.

El detalle de X11 que hace posible trabajar sin pantalla

SNX necesita bibliotecas X11 pero no un servidor X en ejecución. Esa distinción es toda la diferencia entre un cliente que funciona por SSH en un equipo sin pantalla y uno que parece colgarse sin ninguna salida. Instala el paquete de bibliotecas que ofrece tu distribución en lugar de un lote copiado de otra versión, y ejecuta el cliente desde la sesión que necesita el túnel.

Después de que conecte,lee la interfaz y las rutas antes de fiarte de cualquiera de las dos:

ip -brief addr show
ip route show

SNX crea una interfaz de túnel e instala las rutas que define el portal. Esas rutas son decisión de la pasarela y no tuya, así que un prefijo que falta es un problema de perfil en el lado de la pasarela y no un fallo del cliente. Comprueba el DNS al mismo tiempo, porque los perfiles con túnel dividido suelen empujar un resolutor que no esperabas.

Cuando SNX es del todo la respuesta equivocada

Las pasarelas de Check Point también pueden terminar conexiones IPsec yL2TPde cliente a sitio, y esas funcionan con strongSwan, Libreswan o el complemento L2TP de NetworkManager. Eso es configuración de la pasarela, no un truco del cliente. Si la pasarela solo publica el portal Mobile Access,un cliente IPsec no tiene con qué negociar, y el registro muestra un tiempo de espera en lugar de un fallo de autenticación. Pregunta qué blades de acceso remoto están activadas antes de instalar cualquier otra cosa.

Todas las restricciones de aquí viven en el lado de la pasarela: la blade, la licencia, la compilación del cliente y el perfil de rutas. La CLI funciona desde hace años. Lo que se rompe es la suposición de que el soporte para Linux significa un paquete que posees y controlas.