一套 VPN 服务能覆盖 Windows、Mac 和 Linux 桌面吗?
一套接入方案可以同时服务 Windows、Mac 和 Linux 桌面,但前提是先固定网关身份、凭据、路由与解析器策略。
一个团队三台笔记本,三套不同的 VPN 菜单,还有一张工单说连接在各处都正常,唯独 Mac 不行。这些客户端背后的方案可以完全一致,即使菜单并不相同。真正必须对齐的东西比多数部署设想的要窄:一个网关身份、一种凭据类型、一组路由和一条解析器策略。在任何人导出配置文件之前先把这四项写下来,平台相关工作就会变成一张清单,而不是一场排查。
从接入契约开始,而不是客户端文件
接入契约只有五行,评审者不必打开厂商控制台就能核对。它写明 必须可达的私有网段、必须解析的内部名称、负责应答它们的解析器、允许留在本地路径上的流量,以及客户端应当看到的网关证书。部署中的其他一切都是把这些行翻译成某种文件格式。
一个办公场景的例子能把轮廓具体化:应用服务器位于 10.60.0.0/16,私有名称在 corp.example 之下,内部解析器为 10.61.0.53,而普通浏览仍走设备原本使用的路径。最后一项是策略决定,而不是客户端默认行为;如果没人明确说明,好几个客户端会把所有流量都送进隧道。把契约连同日期和负责人记录在案,因为只有这份记录日后才能告诉你,变的是隧道还是策略。
选定一种协议和一对你能为之辩护的认证方式
当三个平台都必须在没有额外软件的情况下工作时,用 IKEv2 做基于证书的网关认证、用户侧用 EAP 是常见选择,因为 Windows、macOS 和 NetworkManager 各自都自带 IKEv2 客户端。麻烦在于,支持 IKEv2 只描述了一个标签,而不是一组功能。EAP 方法、硬件支持的密钥、证书到账号的映射以及自动重连,都是按平台各自实现的。某种组合在其中两个平台上可用是相当常见的情况,所以在实测之前应当假定它尚未可用。
在写部署指南之前,先在每一个目标平台上测试这对组合,而不是之后。网关同时提供 EAP-MSCHAPv2 和 EAP-TLS,就给了你回退的余地,前提是回退路径被记录为受支持,而不是在事故当中被发现。两条受支持的路径是便宜的保险;一条没有文档的第三条路径则是未来的工单。
当没有任何单一组合能覆盖全部三个客户端时,诚实的选项是增加一个客户端、增加一个网关配置,或者收窄受支持的平台清单。把抱怨最响的那个平台上的证书校验关掉,并不属于这些选项。那一步会把兼容性缺口变成劫持风险,而部署流程里后面的任何一步都修复不了它。
按契约为每个平台构建一份产物
Windows 使用 VPNv2 配置文件,通过 MDM 下发,或在本地用 Add-VpnConnection 加其 XML 载荷创建。容易出问题的是作用域与信任。设备作用域的配置文件和用户作用域的配置文件会安装到不同的存储区,因此客户端需要的证书必须位于与你所选作用域相匹配的存储区。这一步配对弄错,会得到一个能顺利导入、却在首次连接时失败的配置文件。
macOS 使用包含受管 VPN 载荷的配置描述文件,签名后通过 MDM 推送,或在试点时手工安装。身份与 CA 链作为各自独立的载荷传输,这就是为什么一个描述文件可以毫无报错地安装完成,却在连接时失败。要检查载荷清单,而不只是安装结果。
Linux 取决于 NetworkManager 背后的后端,而 strongSwan 与 NetworkManager 插件是两个独立的软件包。连接属性是插件特有的,而不是通用 VPN 键,所以从另一个插件复制来的键常常能无错保存,然后在激活时失败。在一份干净的镜像上建立连接,以确认插件确实存在于它将实际运行的地方。
这三份产物格式不同,但每一份都编码了同样的五行契约。这就是判断一份产物是否完成的标准:每一行都在某处有所体现,并且过程中没有凭空增加任何东西。
| Platform | Artifact | Check before handoff |
|---|---|---|
| Windows | VPNv2 profile or Add-VpnConnection | Scope matches certificate store |
| macOS | Managed VPN payload plus certificate payload | Both payloads present in one profile |
| Linux | NetworkManager connection with strongSwan backend | Plugin package installed on the image |
在干净账户上验证路由、解析器和重连
连上并不是验收测试。在 Windows 上,Get-VpnConnection 显示配置文件,route print 显示私有网段是否落到了隧道接口上。在 macOS 上,scutil --nc list 确认当前活跃的服务,而 scutil --dns 显示系统真正会使用的解析器顺序。
在 Linux 上,nmcli connection show --active 证明连接已建立,resolvectl status 显示每条链路的 DNS。解析器出现在连接文件里、却不在按链路输出中,意味着分离 DNS 没有被应用。这正是「名称能解析」与「名称经隧道解析」之间的区别,它决定了下一步该由哪个支持团队接手。要在连接建立之前和之后都对比按链路输出,而不只是对比之后。
用一个全新账户跑完整套检查,不缓存凭据,也不预装管理员证书。然后在挂起并恢复之后重跑一次,再在强制重新输入凭据之后跑一次。这两个状态转换会暴露首次连接永远不会显示的大部分重连故障。
给软件包打版本号,并保留回滚路径
给每个平台的软件包打上它所实现的契约修订号,并记下你验收它时所用的客户端与网关版本。当客户端更新后行为发生变化时,这个标签指向的是一份需要重测的契约,而不是一个需要猜测的文件。
每个平台都保留上一版软件包可随时取回,并在旁边写下它的卸载命令。卸载 VPN 配置文件并不是安装它的镜像操作,Windows、macOS 和 Linux 上都是如此,而这些差异会在最糟糕的时刻显现。在一台备用设备上演练一次卸载,档案才会成为计划,而不是指望。