旧的 IOS SSL VPN：客户端包、配置文件、网关与会话

你在路由器的闪存里找到一个客户端安装程序，就断定 SSL VPN 已经配置好了。它只是四个部件中的一个，另外三个才决定有没有人真能连上。在旧版 IOS SSL VPN 里，这些部件是彼此独立的对象：头端客户端包、可选的客户端配置文件、负责终结 TLS 的 WebVPN 网关，以及保存认证与会话设置的上下文和组策略。漏掉哪一个，从外面看到的故障都一模一样。

思科的 IOS SSL VPN 配置示例构建在 IOS 15.3 与 AnyConnect 3.1 之上，它之所以有用，正是因为这四个对象在里面是分开的。请把它当作对那个较早实现的描述，而不是部署那些版本的推荐。

第一，客户端包：它是什么，不是什么

头端包只为一个平台提供客户端软件。它既不是配置文件，也不是监听器，而 一个躺在闪存里的文件 只能证明有人上传过东西。它不能证明某个会话用过它、平台与用户设备匹配，也不能证明网关引用过它。

确认准确的文件名、它面向的平台，以及配置在哪里指向它。Windows 包说明不了手机的情况，而没有任何网关对象提到的上传文件只是存储，不是配置。与平台匹配但从未与服务关联的包不会提供给任何用户；文件名与配置期望值不一致的包同样如此。

第二，配置文件：是设置，不是软件

可选的客户端配置文件承载管理员单独准备的设置，例如服务器列表或客户端偏好。把它和安装程序混淆很常见，因为两者都是以相似名字出现的文件。如果部署期待一个配置文件，它的缺失改变的是客户端连上之后做什么，而不是它到底能不能连。

把两样东西都盘点清楚，并记录网关实际引用的是哪一个。这一行记录能避免一整类「两个人其实在说不同文件」的支持工单。

第三，监听器与 TLS 身份

网关对象定义外部世界能到达的地址与端口，以及握手中出示的证书。浏览器访问门户页面、客户端完成认证、应用访问内部服务器，这是三种不同的观察，只有第一种是监听器测试。握手失败时，下游的一切都还谈不上，所以在改动任何策略之前，先核对证书链和名称。

把期望的身份写下来，放在某个地方。证书续期或更换，是上个月还能用的部署这个月突然不工作的最常见原因。

第四，上下文与带虚拟模板的策略

上下文和组策略把认证与会话行为绑定在一起：地址池、分离路由、DNS，以及用户可以访问哪些内部网络。文档示例把上下文挂到一个虚拟模板上，由它提供每个会话的接口行为，而这些服务端对象的存在与用户下载任何东西无关。

用户认证通过却什么都访问不到时，问题通常在这里，而不在客户端。对比地址池、下发给客户端的路由以及放行后续流量的 ACL，并且用用户实际反馈去核对，而不是用设计原本的意图。

按顺序验证，并在第一个故障处停下

按连接遇到它们的顺序走完四个部件：监听器、认证、策略，最后是客户端行为。用期望的身份确认 TLS，用一个已知正常的账号认证，从会话里读出分配的地址和路由，只有在这之后才去比对客户端平台与包。 在第一个故障处停下 能让场上只留一个变量，而这正是修复与猜测的区别。

对于手机，或任何不在那个历史桌面示例里的客户端，请去拿到真正受支持的客户端与网关契约，而不是假定 Windows 流程可以照搬。更换请求的协议不会把 IKEv2 配置文件变成这个 SSL VPN 服务，而安装桌面端包对移动端支持什么也证明不了。