Linux 上的 Check Point VPN：SNX 不是下载后安装的东西

你去找 Check Point 的 Linux 客户端，却找不到任何带安装程序的下载页面。这种缺失不是打包疏漏。Check Point 在 Linux 上的远程接入客户端是 SSL Network Extender，也就是 SNX，你在浏览器里完成身份验证后，网关会把它交给你。想通这一点，剩下的困惑就说得通了，包括为什么几乎每篇相关文章都是多年前的。

误区：有一个下载后安装的客户端

这种期待来自其他所有厂商。OpenVPN、WireGuard 和多数商业客户端都会发布软件包或软件仓库，安装是你独自做出的本地决定。Check Point 在 Linux 上不是这样。当前网关版本的官方下载里没有独立安装程序，所以搜来搜去只会翻出旧论坛帖子和第三方镜像。

那些镜像比没用更有害，因为构建必须与提供它的网关相匹配。

SNX 到底是什么，从哪里来

SNX 是命令行客户端，二进制文件名为 snx，安装过程发生在你于浏览器中针对网关建立的会话里。历史上由一个 Java 小程序在你同意提示后下载并安装它。机制这些年变过，来源没变。网关提供与自身匹配的构建，所以客户端与网关版本始终同步，也因此从旧软件包里复制来的客户端只在网关仍与它对话时才能用。

这也意味着，在客户端上做任何工作之前，网关必须先就位。Mobile Access Software Blade 必须获得授权并完成配置，因为没它就没有可安装的门户。网关不提供会话时，客户端这边再努力也建不起会话。

用你的用户名把客户端指向网关，然后读它的报告：

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

限制在发行版支持，而不在安装程序

厂商为 SNX 列出的受支持发行版既短又旧。在已发布的文章里，它停在 Ubuntu 17.04 附近，同期的几个 openSUSE、Fedora 和 RHEL 版本陪在旁边，而且仍然列着 Ubuntu 12.10。这说明的是清单如何变旧，不是你的机器需要什么。当前发行版根本不在其中。

先预料到库不匹配，再谈可用的隧道。常见的三种是 64 位系统上缺少 32 位库、二进制从未链接过的 OpenSSL 版本，以及客户端试图编译的内核模块。与其猜软件包，不如读缺失的符号：

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

然后去查你实际连接的那个网关版本的支撑文章。博客上的清单不是兼容性声明，更新的发行版也不等于更新的客户端。

让无图形界面也能工作的 X11 细节

SNX 需要 X11 库，但不需要运行中的 X 服务器。这个区别正是通过 SSH 在无头主机上工作的客户端，与看起来毫无输出地卡住的客户端之间的全部差别。请安装你自己发行版提供的库软件包，而不是从别的版本拷来的整包，并从需要隧道的那个会话里运行客户端。

连上之后，先读接口和路由，再决定信哪一个：

ip -brief addr show
ip route show

SNX 会创建隧道接口并安装门户定义的路由。那些路由是网关的决定而不是你的，所以缺失的前缀是网关侧的配置问题，不是客户端的缺陷。同时检查 DNS，因为拆分隧道配置常常推给你一个没预料到的解析器。

当 SNX 根本就是错的答案

Check Point 网关也能终止 IPsec 和L2TP的客户端到站点连接，那些用 strongSwan、Libreswan 或 NetworkManager 的 L2TP 插件就能工作。这是网关配置，不是客户端技巧。如果网关只发布 Mobile Access 门户，IPsec 客户端就没有可协商的对象，日志里显示的是超时而不是认证失败。在装别的东西之前，先问清启用了哪些远程接入 blade。

这里的每条限制都在网关侧：blade、授权、客户端构建和路由配置。CLI 多年来一直好用。真正崩掉的是那个假设：Linux 支持就意味着一个你拥有并掌控的软件包。