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

SNX en Linux falla no cargador, na táboa de rutas ou no resolutor, e cada un deses fallos parece un problema de inicio de sesión. Aborde os catro síntomas por orde.

O SSL Network Extender de Check Point falla en Linux de catro maneiras recoñecibles, e tres delas lense mal como un problema de inicio de sesión. Ou o binario non arrinca, ou arrinca e non deixa ningunha ruta, ou conéctase e morre a resolución de nomes, ou o portal do navegador funciona mentres a liña de ordes non. Abórdaos nesa orde, porque cada un é a condición de entrada do seguinte.

Síntoma un: o cargador négase antes do inicio de sesión

O instalador descargado da devasa deixa un binario de 32 bits con setuid-root en /usr/bin/snx. Nunha distribución de 64 bits non se executa ata que se habilita a arquitectura i386 e existen as bibliotecas contra as que liga.

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"

Unha lista not found baleira é a porta para todo o que segue. O conxunto exacto de paquetes cambia entre versións: un informe que funcionaba necesitaba libstdc++5:i386, libx11-6:i386 e libpam0g:i386, outro tamén necesitaba libstdc++6:i386. Lea ldd en lugar de copiar unha lista de paquetes dun titorial escrito para outra distribución.

Se snx non aparece en absoluto, o instalador nunca rematou ou instalouse nalgún lugar fóra do seu PATH. Ese é outro fallo, e paga a pena confirmalo antes de engadir arquitecturas ao sistema. Comprobe con command -v snx e mire no directorio que informou o instalador. Engadir paquetes i386 nunha máquina onde o binario simplemente non está non arranxa nada.

Síntoma dous: o inicio de sesión ten éxito e nada se encamiña

Un inicio de sesión correcto crea tunsnx e edita a táboa de rutas por si mesmo, así que comprobe que existe realmente antes de cambiar calquera outra cousa.

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

Use snx -d para desmontalo. Matar o proceso deixa atrás a interface e as súas rutas, e o seguinte intento falla entón por unha razón que non ten nada que ver coas credenciais. O primeiro inicio de sesión tamén rexistra unha sinatura do servidor en /etc/snx/, polo que un script desatendido pode necesitar unha execución interactiva antes de poder funcionar. Borre ese estado só cando teña a intención de volver aprobar o servidor.

Síntoma tres: os nomes resólvense ata que sobe o túnel

Este é o que se rompe en silencio. snx escribe os servidores DNS empurrados directamente en /etc/resolv.conf. Onde esa ruta é unha ligazón simbólica dentro de /run/systemd/resolve/, a edición pode perderse no seguinte evento do resolutor, e despois dunha desconexión as entradas empurradas tamén poden quedar.

Funcionan dous arranxos, e a elección debería ser deliberada e non a que suxeriu o primeiro resultado de busca:

  • Quede co ficheiro: substitúa a ligazón simbólica por un ficheiro estático e instale libnss-resolve máis a súa variante i386, para que o servizo de nomes siga tendo unha alternativa cando o ficheiro se reescriba por debaixo.
  • Manteña systemd-resolved como propietario e rexistre a ligazón do túnel: resolvectl dns tunsnx 10.0.0.10, despois resolvectl domain tunsnx corp.example, e confirme con resolvectl status.

Anote os servidores de nomes anteriores á VPN antes de conectarse. Se edita o ficheiro a man, quitar as entradas empurradas despois forma parte do procedemento, non é unha limpeza opcional, porque un portátil que conserva o DNS corporativo tras desconectarse non poderá resolver nada máis.

Síntoma catro: o portal funciona e a CLI non

As versións recentes da devasa trasladaron o middleware do navegador a un demonio Java local, así que o portal fala cun axente local no porto 14186. Ese enderezo necesita unha excepción de certificado no navegador e un proceso en execución.

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

A liña de ordes é unha ruta aparte: snx -s vpn.example.com -u user, con ~/.snxrc gardando o servidor, o nome de usuario e a preferencia de reautenticación. Unha sesión de portal que funciona non di nada sobre se a CLI está instalada correctamente, e o cliente espido non xestiona códigos dun só uso.

O atallo do contedor que custa máis do que aforra

snx comproba o módulo tun, cárgao cando falta, crea unha interface de túnel, reescribe as rutas e empurra o tráfico a través dela. Reproducir iso dentro dun contedor significa montar /dev e /lib/modules e conceder capacidades amplas, o que entrega ao contedor boa parte da administración de rede do anfitrión.

Cando de verdade se necesita unha contorna illada, unha máquina virtual é a fronteira máis limpa: o cliente recibe un núcleo que pode modificar, e o anfitrión conserva a súa táboa de rutas. Escóllao antes de pasar unha tarde en capacidades que lamentará ter concedido.

Artigos relacionados