Check Point VPN a Linux: SNX no és una descàrrega que instal·leu

Cerqueu el client de Check Point per a Linux i no trobeu cap pàgina de descàrrega amb un instal·lador. Aquesta absència no és un buit d'empaquetament. El client d'accés remot de Check Point per a Linux és SSL Network Extender, SNX, i la passarel·la us el lliura després que us autentiqueu en un navegador. Quan això encaixa, la resta de la confusió té sentit, inclòs per què gairebé tots els articles sobre el tema tenen anys.

El mite: hi ha un client que descarregueu i instal·leu

L'expectativa ve de tots els altres proveïdors. OpenVPN, WireGuard i la majoria de clients comercials publiquen un paquet o un repositori, i instal·lar-ne un és una decisió local que preneu sols. Check Point no funciona així a Linux. No hi ha instal·lador autònom a les descàrregues oficials per a les versions actuals de la passarel·la, així que buscar-ne un només porta a fils antics de fòrums i a miralls de tercers.

Aquests miralls són pitjor que inútils, perquè la compilació ha de coincidir amb la passarel·la que la serveix.

Què és realment SNX i d'on surt

SNX és un client de línia d'ordres el binari del qual és snx, i s'instal·la a través d'una sessió que inicieu al navegador contra la passarel·la. Històricament un miniaplicatiu Java el descarregava i l'instal·lava després que acceptéssiu el missatge. El mecanisme ha canviat amb els anys, la font no. La passarel·la serveix la compilació que li correspon, i per això les versions del client i de la passarel·la van juntes, i per això un client copiat d'un paquet antic només funciona mentre la passarel·la encara hi parla.

Això també vol dir que la passarel·la ha d'estar a punt abans que qualsevol feina al client tingui sentit. Mobile Access Software Blade ha d'estar llicenciat i configurat, perquè sense això no hi ha portal des d'on instal·lar. Cap esforç a la banda del client produeix una sessió contra una passarel·la que no n'ofereix cap.

Apunteu el client a la passarel·la amb el vostre usuari i llegiu què reporta:

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

La restricció és el suport de distribucions, no l'instal·lador

La llista de distribucions suportades pel proveïdor per a SNX és curta i antiga. A l'article publicat s'atura cap a l'Ubuntu 17.04, al costat d'unes quantes versions d'openSUSE, Fedora i RHEL de la mateixa època, i encara llista l'Ubuntu 12.10. Això us diu com envelleix la llista, no què necessita la vostra màquina. Una distribució actual simplement no hi és.

Espereu desajustos de biblioteques abans d'esperar un túnel funcional. Els tres habituals són biblioteques de 32 bits que falten en un sistema de 64 bits, una versió d'OpenSSL amb la qual el binari mai no es va enllaçar, i un mòdul del nucli que el client intenta compilar. Llegiu els símbols que falten en comptes d'endevinar paquets:

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

Després consulteu l'article de suport de la versió de passarel·la a què us connecteu realment. Una llista d'un blog no és una declaració de compatibilitat, i una distribució més nova no implica un client més nou.

El detall d'X11 que fa possible treballar sense pantalla

SNX necessita biblioteques X11, però no un servidor X en execució. Aquesta distinció és tota la diferència entre un client que funciona per SSH en un host sense pantalla i un que sembla penjar-se sense cap sortida. Instal·leu el paquet de biblioteques que ofereix la vostra distribució en lloc d'un paquet copiat d'una altra versió, i executeu el client des de la sessió que necessita el túnel.

Després que es connecti,llegiu la interfície i les rutes abans de confiar en cap de les dues:

ip -brief addr show
ip route show

SNX crea una interfície de túnel i instal·la les rutes que defineix el portal. Aquestes rutes són decisió de la passarel·la i no vostra, així que un prefix que falta és un problema de perfil a la banda de la passarel·la i no un error del client. Comproveu el DNS alhora, perquè els perfils amb túnel dividit sovint empenyen un resolutor que no esperàveu.

Quan SNX és del tot la resposta equivocada

Les passarel·les de Check Point també poden acabar connexions IPsec iL2TPde client a lloc, i aquestes funcionen amb strongSwan, Libreswan o el connector L2TP del NetworkManager. Això és configuració de la passarel·la, no un truc del client. Si la passarel·la només publica el portal Mobile Access,un client IPsec no té amb què negociar, i el registre mostra un temps d'espera en lloc d'un error d'autenticació. Pregunteu quines blades d'accés remot estan activades abans d'instal·lar res més.

Totes les restriccions d'aquí viuen a la banda de la passarel·la: la blade, la llicència, la compilació del client i el perfil de rutes. La CLI funciona des de fa anys. El que es trenca és la suposició que el suport per a Linux significa un paquet que posseïu i controleu.