SNX su Linux: librerie a 32 bit e un resolver che si ripristina

L’SSL Network Extender di Check Point fallisce su Linux in quattro modi riconoscibili, e tre di essi vengono letti male come un problema di accesso. O il binario non parte, o parte e non lascia alcuna rotta, o si connette e la risoluzione dei nomi muore, o il portale del browser funziona mentre la riga di comando no. Affrontateli in quest’ordine, perché ciascuno è la condizione d’ingresso del successivo.

Sintomo uno: il caricatore rifiuta prima dell’accesso

L’installer scaricato dal firewall lascia un binario a 32 bit con setuid-root in /usr/bin/snx. Su una distribuzione a 64 bit non viene eseguito finché l’architettura i386 non è abilitata e le librerie contro cui è linkato non esistono.

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"

Un elenco not found vuoto è la porta per tutto ciò che segue. L’insieme esatto dei pacchetti cambia tra le versioni: un resoconto funzionante richiedeva libstdc++5:i386, libx11-6:i386 e libpam0g:i386, un altro richiedeva anche libstdc++6:i386. Leggete ldd invece di copiare un elenco di pacchetti da un tutorial scritto per un’altra distribuzione.

Se snx non si trova affatto, l’installer non è mai stato completato o si è installato altrove fuori dal vostro PATH. È un guasto diverso, e vale la pena confermarlo prima di aggiungere architetture al sistema. Verificate con command -v snx e guardate nella directory indicata dall’installer. Aggiungere pacchetti i386 a una macchina in cui il binario è semplicemente assente non ripara nulla.

Sintomo due: l’accesso riesce e nulla viene instradato

Un accesso riuscito crea tunsnx e modifica da solo la tabella di routing, quindi controllate cosa esiste davvero prima di cambiare qualsiasi altra cosa.

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

Usate snx -d per smontare. Uccidere il processo lascia indietro l’interfaccia e le sue rotte, e il tentativo successivo fallisce allora per un motivo che non ha nulla a che vedere con le credenziali. Il primo accesso registra anche una firma del server sotto /etc/snx/, ed è per questo che uno script non presidiato può aver bisogno di un’esecuzione interattiva prima di poter funzionare. Cancellate quello stato solo quando intendete riapprovare il server.

Sintomo tre: i nomi si risolvono finché il tunnel non sale

Questo è quello che si rompe in silenzio. snx scrive i server DNS spinti direttamente in /etc/resolv.conf. Dove quel percorso è un collegamento simbolico dentro /run/systemd/resolve/, la modifica può andare persa al successivo evento del resolver, e dopo una disconnessione le voci spinte possono altrettanto bene restare.

Funzionano due sistemazioni, e la scelta dovrebbe essere deliberata invece di quella suggerita dal primo risultato di ricerca:

• Prendete il file: sostituite il collegamento simbolico con un file statico e installate libnss-resolve più la sua variante i386, così il servizio dei nomi ha ancora un ripiego quando il file viene riscritto sotto di esso.
• Mantenete systemd-resolved come proprietario e registrate il collegamento del tunnel: resolvectl dns tunsnx 10.0.0.10, poi resolvectl domain tunsnx corp.example, e confermate con resolvectl status.

Annotate i server dei nomi precedenti alla VPN prima di connettervi. Se modificate il file a mano, rimuovere le voci spinte dopo fa parte della procedura, non è una pulizia facoltativa, perché un portatile che conserva il DNS aziendale dopo la disconnessione non riuscirà a risolvere nient’altro.

Sintomo quattro: il portale funziona e la CLI no

Le versioni recenti del firewall hanno spostato il middleware dal browser a un demone Java locale, così il portale parla con un agente locale sulla porta 14186. Quell’indirizzo richiede un’eccezione di certificato nel browser e un processo in esecuzione.

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

La riga di comando è un percorso separato: snx -s vpn.example.com -u user, con ~/.snxrc che conserva il server, il nome utente e la preferenza di riautenticazione. Una sessione del portale funzionante non dice nulla sulla correttezza dell’installazione della CLI, e il client nudo non gestisce i codici monouso.

La scorciatoia del container che costa più di quanto risparmia

snx controlla il modulo tun, lo carica quando manca, crea un’interfaccia di tunnel, riscrive le rotte e vi spinge il traffico. Riprodurre tutto ciò dentro un container significa montare /dev e /lib/modules e concedere capacità ampie, il che consegna al container la maggior parte dell’amministrazione di rete dell’host.

Quando serve davvero una sandbox, una macchina virtuale è il confine più pulito: il client riceve un kernel che può modificare, e l’host conserva la sua tabella di routing. Sceglietela prima di passare un pomeriggio su capacità che rimpiangerete di aver concesso.