Check Point VPN no Linux: o SNX não é um download que se instala

Você procura o cliente Check Point para Linux e não encontra uma página de download com um instalador. Essa ausência não é uma falha de empacotamento. O cliente de acesso remoto da Check Point para Linux é o SSL Network Extender, o SNX, e o gateway o entrega a você depois que você se autentica num navegador. Quando isso encaixa, o resto da confusão faz sentido, inclusive por que quase todo texto sobre o assunto tem anos.

O mito: existe um cliente que você baixa e instala

A expectativa vem de todos os outros fornecedores. OpenVPN, WireGuard e a maioria dos clientes comerciais publicam um pacote ou um repositório, e instalar um deles é uma decisão local que você toma sozinho. A Check Point não funciona assim no Linux. Não há instalador autônomo nos downloads oficiais para as versões atuais do gateway, então procurar por um só traz tópicos antigos de fórum e espelhos de terceiros.

Esses espelhos são piores do que inúteis, porque a compilação tem de corresponder ao gateway que a serve.

O que o SNX realmente é, e de onde vem

O SNX é um cliente de linha de comando cujo binário é o snx, e ele é instalado através de uma sessão que você inicia no navegador contra o gateway. Historicamente, um applet Java o baixava e instalava depois que você aceitava o aviso. O mecanismo mudou ao longo dos anos, a origem não. O gateway serve a compilação que corresponde a ele mesmo, por isso as versões de cliente e gateway andam juntas, e por isso um cliente copiado de um pacote antigo só funciona enquanto o gateway ainda fala com ele.

Isso também significa que o gateway precisa estar pronto antes que qualquer trabalho no cliente importe. O Mobile Access Software Blade precisa estar licenciado e configurado, porque sem ele não há portal de onde instalar. Nenhum esforço do lado do cliente produz uma sessão contra um gateway que não oferece uma.

Aponte o cliente para o gateway com o seu usuário e leia o que ele reporta:

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

A restrição é o suporte a distribuições, não o instalador

A lista de distribuições suportadas pelo fornecedor para o SNX é curta e antiga. No artigo publicado, ela para por volta do Ubuntu 17.04, ao lado de algumas versões de openSUSE, Fedora e RHEL da mesma época, e ainda lista o Ubuntu 12.10. Isso diz como a lista envelhece, não o que a sua máquina precisa. Uma distribuição atual simplesmente não está nela.

Espere incompatibilidades de bibliotecas antes de esperar um túnel funcional. As três habituais são bibliotecas de 32 bits ausentes num sistema de 64 bits, uma versão de OpenSSL com a qual o binário nunca foi ligado, e um módulo de kernel que o cliente tenta compilar. Leia os símbolos ausentes em vez de adivinhar pacotes:

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

Depois consulte o artigo de suporte da versão de gateway à qual você realmente se conecta. Uma lista num blog não é uma declaração de compatibilidade, e uma distribuição mais nova não implica um cliente mais novo.

O detalhe do X11 que torna o trabalho sem tela possível

O SNX precisa de bibliotecas X11, mas não de um servidor X em execução. Essa distinção é toda a diferença entre um cliente que funciona por SSH num host sem tela e um que parece travar sem nenhuma saída. Instale o pacote de bibliotecas que a sua distribuição oferece em vez de um conjunto copiado de outra versão, e execute o cliente a partir da sessão que precisa do túnel.

Depois que ele conecta,leia a interface e as rotas antes de confiar em qualquer uma das duas:

ip -brief addr show
ip route show

O SNX cria uma interface de túnel e instala as rotas que o portal define. Essas rotas são decisão do gateway e não sua, então um prefixo ausente é um problema de perfil do lado do gateway e não um erro do cliente. Verifique o DNS ao mesmo tempo, porque perfis com túnel dividido costumam empurrar um resolvedor que você não esperava.

Quando o SNX é completamente a resposta errada

Os gateways da Check Point também podem terminar conexões IPsec eL2TPde cliente para site, e essas funcionam com strongSwan, Libreswan ou o plugin L2TP do NetworkManager. Isso é configuração do gateway, não truque do cliente. Se o gateway publica apenas o portal Mobile Access,um cliente IPsec não tem com o que negociar, e o log mostra um tempo esgotado em vez de uma falha de autenticação. Pergunte quais blades de acesso remoto estão habilitadas antes de instalar qualquer outra coisa.

Toda restrição aqui vive do lado do gateway: a blade, a licença, a compilação do cliente e o perfil de rotas. A CLI funciona há anos. O que quebra é a suposição de que suporte a Linux significa um pacote que você possui e controla.