那个 OpenVPN 安全修复到底和你的安装有关吗？

建议给客户端打补丁让它校验证书，这句话太空泛，没法照做。它可能指一个已修复的软件缺陷、某个提供商的旧构建，或者一份从未要求这项检查的配置。这是三种不同的改动，分属三个不同的负责人。不清楚自己面对哪一种就照这句话动手，正是把原本正常的客户端无故改坏的常见路径。

把三种说法分开

软件缺陷有安全公告、受影响版本和已修复的发布。提供商的构建有自己的分发渠道和更新节奏。配置遗漏则两者都没有，因为可执行文件本身没问题，只是配置要求的检查比你以为的少。在这句话点明三者中的哪一种之前，没有可测试的东西。

先去搜索之前，把这句话写成一句。如果这句话说不出哪里坏了，搜索就没有目标，每个结果看起来都相关。

找到真正在运行的可执行文件

在看任何版本之前，先确定是什么启动了连接。发行版服务、桌面插件和厂商应用可能各自使用不同的可执行文件或引擎。shell 搜索路径里随便一个二进制打印出的版本，并不是这台机器的清单。要读的是真正完成连接的那个 unit 或进程。

systemctl cat openvpn-client@*.service
ps -o pid,cmd -C openvpn
apt-cache policy openvpn network-manager-openvpn

包查询报告的是本地元数据认为已安装且可用的内容，而这份缓存可能过期，所以要先刷新。它也完全没说正在运行的服务是否加载了五分钟前刚安装的二进制。把包记录和真正处于连接状态的进程对照起来看。

用软件包的证据代替版本印象

发行版的安全维护经常回移修复，所以看起来更旧的上游版本仍可能包含补丁。反过来也成立：来自陌生仓库的软件包并不自动代表当前维护。要看发布的支持状态，而不是版本号。

这个区别就是真实缺口与只是看起来旧的数字之间的区别。记录软件包来自哪个仓库，因为同一个版本字符串可能通过差别极大的渠道、带着差别极大的支持到达。

配置是另一半

受维护的可执行文件仍然需要一份配置去要求你以为已经生效的检查。信任锚点、对端的预期角色和预期服务器名称是相关但彼此独立的决定。角色检查不是名称检查，两者也不能互相替代。如果告警说的是配置，修复就属于配置的所有者。

不要为了弥补未经核实的配置而随意安装补丁，也不要为修复真正的实现缺陷而添加指令。这两种错误都像在推进，所以都会反复出现。

依据记录中的证据来决定

决定取决于你确认了什么。有文档的受影响软件包要求使用受支持的更新，不受支持的平台需要迁移路径，提供商的客户端需要该提供商的指引。含糊的指示在以上任何一条适用之前，需要一份公告和一个受影响的组件。

把正在使用的客户端、完整版本、公告和配置所有者一起写进变更记录。这比引用一篇教程更有力，也正是下一个人真正需要的东西。