Linux 上的 SNX：32 位库与会自动重置的解析器

Check Point 的 SSL Network Extender 在 Linux 上有四种可辨别的失败方式，其中三种常被误读为登录问题。要么二进制无法启动，要么启动后没有留下路由，要么连上了但域名解析死掉，要么浏览器门户能用而命令行不能用。请按这个顺序处理，因为每一个都是下一个的前置条件。

症状一：加载器在登录前就拒绝

从防火墙下载的安装程序会把32 位、setuid-root 的二进制放到 /usr/bin/snx。在 64 位发行版上，除非启用 i386 架构并且它链接的库都存在，否则不会运行。

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"

空的 not found 列表是后续一切的前提。确切的软件包集合随版本变化：一份成功的报告需要 libstdc++5:i386、libx11-6:i386 和 libpam0g:i386，另一份还需要 libstdc++6:i386。请阅读 ldd，而不是照抄为另一个发行版写的教程里的软件包列表。

如果完全找不到 snx，说明安装程序从未完成，或装到了 PATH 之外。那是另一种故障，值得在给系统添加架构之前先确认。用 command -v snx 检查，并查看安装程序报告的目录。给根本没有该二进制的机器添加 i386 软件包修不好任何问题。

症状二：登录成功，却没有任何路由

成功登录会创建 tunsnx 并自己修改路由表，所以在改动其他任何东西之前，先确认实际存在什么。

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

用 snx -d 卸载。直接杀掉进程会留下接口及其路由，下一次尝试就会因为与凭据无关的原因失败。首次登录还会在 /etc/snx/ 下记录服务器签名，这就是为什么无人值守脚本可能需要先交互运行一次才能工作。只有打算重新批准该服务器时才删除这个状态。

症状三：域名一直能解析，直到隧道起来

这是那个悄悄坏掉的问题。snx 会把下发的 DNS 服务器直接写进 /etc/resolv.conf。当该路径是指向 /run/systemd/resolve/ 的符号链接时，修改可能在一次解析器事件时丢失，断开之后下发的条目也可能同样留在原地。

有两种可行安排，选择应当是有意的，而不是第一次搜索给出的建议：

• 接管文件：把符号链接换成静态文件，并安装 libnss-resolve 及其 i386 版本，这样文件在底下被重写时，名称服务仍有后备。
• 保留 systemd-resolved 作为所有者并注册隧道链路：resolvectl dns tunsnx 10.0.0.10，然后 resolvectl domain tunsnx corp.example，再用 resolvectl status 确认。

连接前先记录 VPN 之前的名称服务器。如果你手动编辑该文件，事后删除下发的条目是流程的一部分，而不是可选的清理，因为断开连接后仍保留企业 DNS 的笔记本将无法解析其他任何东西。

症状四：门户能用，命令行不能

近期的防火墙版本把中间件从浏览器移到了本地 Java 守护进程，所以门户与 14186 端口上的本地代理通信。该地址需要浏览器证书例外和一个运行中的进程。

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

命令行是另一条路径：snx -s vpn.example.com -u user，其中 ~/.snxrc 保存服务器、用户名和重新认证偏好。门户会话能用，并不能说明命令行装得对不对，而裸客户端不处理一次性代码。

看似省事其实更贵的容器捷径

snx 会检查 tun 模块，缺失时加载它，创建隧道接口，改写路由并把流量从其中送出去。要在容器里复现，就得挂载 /dev 和 /lib/modules 并授予宽泛的能力，这等于把宿主机的大部分网络管理权交给容器。

当确实需要沙箱时，虚拟机是更干净的边界：客户端拿到可以修改的内核，宿主机保留自己的路由表。在你花一个下午处理将来会后悔授予的能力之前，先选它。