你的 VPN 客户端还能获得安全修复吗？

打开一款 VPN 客户端的产品页，你会看到协议、功能表和下载按钮；缺少的是最近几个缺陷究竟如何处理。客户端会安装多年，因此维护记录应当与协议列表并列成为选择依据。单看版本号无法区分高下，因为频繁发布与安静期可能掩盖同样的工作量。下面的说明读的正是这份记录，然后检查你实际持有的构建是否仍能获得修复。

读安全公告，而不是数版本

去你打算安装的产品的公告页，而不是同名的服务器软件包页面。服务器更新并不代表客户端修复，桌面端的修正也说明不了移动应用。公告中有用的部分是受影响的版本范围、已修复的构建，以及厂商要求用户采取的措施。OpenVPN 安全公告列表就是这种形式，因此它可以作为衡量任何厂商的公平基准。

发布频率在两个方向上都是弱信号：频繁的节奏可能只是小维护，而安静期也可能包含重要修复。真正给厂商排序的是被报告的缺陷是否产生了明确声明和已修复的构建。记录含糊本身就是一项发现，因为它暗示下一个缺陷也会以同样方式处理。

追溯你的构建来自哪个渠道

渠道决定修复多快到达你手里，而且各平台并不相同。应用商店、厂商安装器、发行版软件包和组织内部的软件门户，各有自己的时间与审批环节。重新打包的构建可能落后上游数周，第三方捆绑包甚至可能完全不遵循厂商的节奏。

不要相信记忆中的下载页，而要问软件包元数据：二进制文件归哪个渠道所有。下面三条命令可在常见的 Linux 和 Flatpak 配置中查明归属与候选版本：

dpkg -S "$(command -v openvpn)"
apt policy openvpn
flatpak list --columns=application,version

检查实际安装的是什么

公告描述的是项目，不是你的机器；任何半途而废的部署之后，两者就会不一致。在接受某次部署已修复之前，先读出已安装的版本：

openvpn --version | head -3
wg --version
winget list --name OpenVPN

受管机群需要管理员批准部署，所以公告不等于已安装的修复。要问部署工具何时会带上新构建，并把答案记在迁移日期旁边。在日期到来前，机群仍保留旧构建和旧暴露面。

证明更新没有破坏隧道

更新可能改变路由行为、安装器选项或配置文件位置，而这种变化通常以连接问题的形式出现，而不是写在发布说明里。用有记录的程序验证连接、路由和重连，而不要假定旧行为仍然存在。把配置文件要求与兼容性设置记在同一份记录里，这样日后的故障才能归因于构建，而不是网络。

如果新构建失败，请在回滚之前记录版本、日志和确切的失败点。没有证据的回滚，往往以再次尝试同一次更新、得到同样结果收场：

ip route get 203.0.113.10
openvpn --config client.ovpn --verb 4 2>&1 | grep -i -E 'error|fatal'
systemctl status openvpn-client@client --no-pager

先记录，再决定。路由查询能把隧道问题与地址问题分开，详细日志会点出失败的选项，单元状态则显示客户端是否曾经启动。这三行还能构成一份可用的厂商报告，而不是一段没人能复现的症状描述。

当平台已失去支持

当厂商停止支持某个操作系统，诚实的选项是迁移，或者一份有记录的例外。为了回避升级而冻结无人维护的客户端，保住的是一个不再获得修复的构建，而这正是我们读公告记录所要判断的属性。例外只有在附带责任人和结束日期时才站得住脚。

收尾时，把三件事写进选型记录：受支持的版本范围、你能安装的最后一个已修复构建，以及该范围之外一切的迁移日期。三者缺一，就在决定之前而不是之后向厂商索取。厂商的沉默不是维护流程的证据。