Check Point VPN su Linux: SNX non è un download da installare

Cerchi il client Check Point per Linux e non trovi una pagina di download con un programma di installazione. Quell'assenza non è una lacuna nel packaging. Il client di accesso remoto di Check Point per Linux è SSL Network Extender, SNX, e il gateway te lo consegna dopo che ti sei autenticato in un browser. Una volta chiarito questo, il resto della confusione ha senso, compreso perché quasi ogni articolo sull'argomento abbia anni.

Il mito: c'è un client che scarichi e installi

L'aspettativa viene da ogni altro fornitore. OpenVPN, WireGuard e la maggior parte dei client commerciali pubblicano un pacchetto o un repository, e installarlo è una decisione locale che prendi da solo. Check Point non funziona così su Linux. Non c'è un programma di installazione autonomo nei download ufficiali per le versioni attuali del gateway, quindi cercarlo restituisce solo vecchi thread di forum e mirror di terze parti.

Quei mirror sono peggio che inutili, perché la build deve corrispondere al gateway che la serve.

Che cos'è davvero SNX, e da dove viene

SNX è un client a riga di comando il cui binario è snx, e si installa tramite una sessione che avvii nel browser contro il gateway. Storicamente un'applet Java lo scaricava e lo installava dopo che avevi accettato la richiesta. Il meccanismo è cambiato negli anni, la fonte no. Il gateway serve la build che corrisponde a se stesso, per questo le versioni del client e del gateway si seguono, e per questo un client copiato da un vecchio pacchetto funziona solo finché il gateway gli parla ancora.

Ciò significa anche che il gateway deve essere pronto prima che qualsiasi lavoro sul client conti. Mobile Access Software Blade deve essere licenziato e configurato, perché senza di esso non c'è portale da cui installare. Nessuno sforzo lato client produce una sessione contro un gateway che non ne offre una.

Punta il client verso il gateway con il tuo utente, e leggi cosa riporta:

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

Il vincolo è il supporto delle distribuzioni, non l'installer

L'elenco delle distribuzioni supportate dal fornitore per SNX è breve e vecchio. Nell'articolo pubblicato si ferma intorno a Ubuntu 17.04, accanto ad alcune release openSUSE, Fedora e RHEL della stessa epoca, e cita ancora Ubuntu 12.10. Questo ti dice come invecchia l'elenco, non di cosa ha bisogno la tua macchina. Una distribuzione attuale semplicemente non c'è.

Aspettati disallineamenti di librerie prima di aspettarti un tunnel funzionante. I tre soliti sono librerie a 32 bit mancanti su un sistema a 64 bit, una versione di OpenSSL con cui il binario non è mai stato collegato, e un modulo del kernel che il client prova a compilare. Leggi i simboli mancanti invece di indovinare i pacchetti:

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

Poi controlla l'articolo di supporto per la release del gateway a cui ti colleghi davvero. Un elenco su un blog non è una dichiarazione di compatibilità, e una distribuzione più recente non implica un client più recente.

Il dettaglio X11 che rende possibile il lavoro senza schermo

SNX ha bisogno delle librerie X11 ma non di un server X in esecuzione. Questa distinzione è tutta la differenza tra un client che funziona via SSH su un host senza schermo e uno che sembra bloccarsi senza alcun output. Installa il pacchetto di librerie fornito dalla tua distribuzione invece di un pacchetto copiato da un'altra release, ed esegui il client dalla sessione che ha bisogno del tunnel.

Dopo che si connette,leggi l'interfaccia e le rotte prima di fidarti di entrambe:

ip -brief addr show
ip route show

SNX crea un'interfaccia di tunnel e installa le rotte definite dal portale. Quelle rotte sono una decisione del gateway e non tua, quindi un prefisso mancante è un problema di profilo lato gateway e non un bug del client. Controlla il DNS nello stesso momento, perché i profili con tunnel diviso spesso spingono un resolver che non ti aspettavi.

Quando SNX è del tutto la risposta sbagliata

I gateway Check Point possono anche terminare connessioni IPsec eL2TPda client a sito, e quelle funzionano con strongSwan, Libreswan o il plugin L2TP di NetworkManager. Questa è configurazione del gateway, non un trucco del client. Se il gateway pubblica solo il portale Mobile Access,un client IPsec non ha nulla con cui negoziare, e il log mostra un timeout invece di un errore di autenticazione. Chiedi quali blade di accesso remoto sono abilitate prima di installare qualsiasi altra cosa.

Ogni vincolo qui vive lato gateway: la blade, la licenza, la build del client e il profilo delle rotte. La CLI funziona da anni. Ciò che si rompe è l'assunto che il supporto Linux significhi un pacchetto che possiedi e controlli.