SNX no Linux: bibliotecas de 32 bits e um resolver que se reinicia

O SSL Network Extender da Check Point falha no Linux de quatro formas reconhecíveis, e três delas são lidas erradamente como um problema de login. Ou o binário não arranca, ou arranca e não deixa nenhuma rota, ou liga-se e a resolução de nomes morre, ou o portal do navegador funciona enquanto a linha de comandos não. Trate-os por essa ordem, porque cada um é a condição de entrada do seguinte.

Sintoma um: o carregador recusa antes do login

O instalador obtido da firewall coloca um binário de 32 bits com setuid-root em /usr/bin/snx. Numa distribuição de 64 bits não corre até a arquitetura i386 estar ativa e existirem as bibliotecas contra as quais é ligado.

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"

Uma lista not found vazia é a porta para tudo o que se segue. O conjunto exato de pacotes muda entre versões: um relato funcional precisava de libstdc++5:i386, libx11-6:i386 e libpam0g:i386, outro precisava também de libstdc++6:i386. Leia ldd em vez de copiar uma lista de pacotes de um tutorial escrito para outra distribuição.

Se snx não for encontrado de todo, o instalador nunca foi concluído ou instalou-se algures fora do seu PATH. Isso é outra falha, e vale a pena confirmá-la antes de acrescentar arquiteturas ao sistema. Verifique com command -v snx e veja no diretório que o instalador reportou. Acrescentar pacotes i386 a uma máquina onde o binário simplesmente não existe não corrige nada.

Sintoma dois: o login tem sucesso e nada é encaminhado

Um login bem-sucedido cria tunsnx e edita a tabela de rotas ele próprio, por isso verifique o que existe realmente antes de mudar qualquer outra coisa.

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

Use snx -d para desmontar. Matar o processo deixa a interface e as suas rotas para trás, e a tentativa seguinte falha então por uma razão que nada tem a ver com credenciais. O primeiro login também regista uma assinatura do servidor em /etc/snx/, e é por isso que um script não vigiado pode precisar de uma execução interativa antes de funcionar de todo. Apague esse estado apenas quando pretende reaprovar o servidor.

Sintoma três: os nomes resolvem-se até o túnel subir

Este é o que se parte em silêncio. O snx escreve os servidores DNS empurrados diretamente em /etc/resolv.conf. Onde esse caminho é uma ligação simbólica dentro de /run/systemd/resolve/, a edição pode perder-se no evento seguinte do resolver, e depois de uma desconexão as entradas empurradas podem igualmente ficar.

Funcionam duas disposições, e a escolha deve ser deliberada em vez de aquilo que o primeiro resultado de pesquisa sugeriu:

• Tome conta do ficheiro: substitua a ligação simbólica por um ficheiro estático e instale libnss-resolve mais a sua variante i386, para que o serviço de nomes tenha ainda uma alternativa quando o ficheiro for reescrito por baixo.
• Mantenha o systemd-resolved como proprietário e registe a ligação do túnel: resolvectl dns tunsnx 10.0.0.10, depois resolvectl domain tunsnx corp.example, e confirme com resolvectl status.

Anote os servidores de nomes anteriores à VPN antes de se ligar. Se editar o ficheiro à mão, remover depois as entradas empurradas faz parte do procedimento, não é limpeza opcional, porque um portátil que mantém o DNS corporativo após a desconexão não conseguirá resolver mais nada.

Sintoma quatro: o portal funciona e a CLI não

As versões recentes da firewall mudaram o middleware do navegador para um daemon Java local, por isso o portal fala com um agente local na porta 14186. Esse endereço precisa de uma exceção de certificado no navegador e de um processo em execução.

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

A linha de comandos é um caminho separado: snx -s vpn.example.com -u user, com ~/.snxrc a guardar o servidor, o nome de utilizador e a preferência de reautenticação. Uma sessão de portal a funcionar não diz nada sobre se a CLI está instalada corretamente, e o cliente nu não trata códigos de uso único.

O atalho do contentor que custa mais do que poupa

O snx verifica o módulo tun, carrega-o quando falta, cria uma interface de túnel, reescreve as rotas e empurra o tráfego através dela. Reproduzir isso dentro de um contentor significa montar /dev e /lib/modules e conceder capacidades amplas, o que entrega ao contentor a maior parte da administração de rede do anfitrião.

Quando é realmente necessário um sandbox, uma máquina virtual é a fronteira mais limpa: o cliente recebe um kernel que pode modificar, e o anfitrião conserva a sua tabela de rotas. Escolha isso antes de passar uma tarde em capacidades que vai lamentar ter concedido.