vpnc 面对 Check Point 或 Nortel：为什么它会卡住

这个症状很容易被误读：vpnc 启动了，询问组密码，然后就停在一个协商步骤上，直到报告目标没有响应。输出里完全没提网关是哪个产品，而账号在浏览器里又能正常使用，于是最直观的结论就是密码错误或端口被封。多数这类情况里，网关压根不是 IPsec 对端，所以交换根本走不到验证凭据那一步。在改动配置文件里的其他任何一项之前，值得先验证这个模式。

在编辑下一个配置文件字段之前，先确认产品。

故障看起来像凭据错误

vpnc 首先向 UDP 500 发送 IKE，如果对端提供 NAT 穿透，还会向 UDP 4500 发送。终结 SSL 而不是 IPsec 的网关对这两个端口都不作答，于是客户端反复重试，最后以一个笼统的错误放弃。如果同一个账号能通过某个浏览器门户使用，而该门户会加载一个小型辅助程序，那就强烈暗示这条隧道基于 SSL，客户端问错了问题。

这里的失败与用户账号无关，因为网关从头到尾没收到过任何凭据。

确认网关提供的是哪种协议

两分钟的探测就能把 IPsec 对端和 SSL 门户区分开。要在客户端将要使用的同一个网络里执行，并且读的是哪些端口有响应，而不是文档里写了哪些端口。把结果留存下来，因为正是这些端口决定了网关负责人该支持哪个客户端。要从客户端网络探测，而不是从网关旁边的主机探测。

nc -zvu gw.example.com 500
nc -zvu gw.example.com 4500
nc -zvt gw.example.com 443
curl -sI https://gw.example.com/ | head -5
openssl s_client -connect gw.example.com:443 -servername gw.example.com </dev/null | head -20

443 开放、跳转到登录页，而 500 和 4500 沉默，指向 SSL VPN。500 和 4500 开放、443 上又在提供证书，则说明这是一台同时运行 Web 前端的 IPsec 网关，而这正是 vpnc 当初为之设计的情形。

Check Point 的 SSL Network Extender 和 Nortel 的 Aventail 客户端都属于第二类，两者都不接受 IKEv1 组密钥。

vpnc 的配置文件能表达什么、不能表达什么

在底层，vpnc 用组预共享密钥跑 IKEv1，然后通过 XAuth 发送单个用户的凭据。配置文件里的每一项都属于这次交换：网关、组名、组密钥、用户名和用户密码。这些字段只描述一种协议，无论怎么组合都无法让客户端去说另一种协议。

所以扩大加密套件列表或者关掉证书校验，永远修不好这一类故障。这些改动只会削弱一场网关根本不在听的协商。

选择与网关匹配的客户端

对 Check Point 网关，应当使用 为该网关发行版构建的 SNX 软件包，厂商会把它连同远程访问文档一起发布。较旧的 SNX 构建在当前的发行版上经常失败，因为它们依赖已不再安装的 32-bit 库，而给一个被放弃的包打补丁，通常比在受支持的平台上运行受支持的客户端更糟。

Aventail 客户端早已停止支持。在这种网关仍在服役的地方，现实的选择是：组织若启用就用浏览器门户，或者在受支持的操作系统上使用厂商支持的客户端。

向网关负责人询问产品与版本、他们在 Linux 上支持的客户端，以及究竟有没有 IPsec 配置。如果有，请把组标识符和组密钥作为两个独立条目索取，因为它们不是用户密码，而这一对被弄混是隧道失败的另一个常见原因。连接最终成功之后，把协商出的协议记下来，让下一个人从事实出发，而不是重复同一个猜测。