为什么添加 opt-verify 并不能修复 OpenVPN 的加密错误

你找到一条建议，加上 opt-verify，添加了那一行，加密错误却仍然停在原处。这个结果是可预见的，因为该选项从来不会协商加密算法。它只是一项选项一致性检查，在 2.6 中弃用、在 2.7 中移除；一个带着它仍能解析的配置文件，并没有因此强制执行任何东西。

在断定它就是缺失的那一环之前，先了解这行以前做什么会有帮助。这段历史也解释了它现在为什么帮不上忙。

该选项以前强制什么

2.6 的手册把 opt-verify 标为已弃用，并描述了更早的行为：服务器会断开那些声明的选项与自身不匹配的客户端，比较的包括设备类型和 MTU。这项检查还依赖于选项一致性检查保持启用，因此使用 disable-occ 运行的服务器从来就没有它。注意比较是由什么构成的：描述对端配置的文本。它对数据通道将使用哪种加密只字未提。

这就是该标志无法修复加密错误的第一个原因。加密算法的选择由 data-ciphers 策略以及双方的支持范围决定，而文本一致性检查既不会扩展那份列表，也不会执行协商。第二个原因是范围：这项检查针对的是声明的选项看起来是否兼容，而不是由此得到的路径质量。

2.7 看到这行时会怎样

在 2.7 中该选项已不存在。解析器仍能识别这个名字，所以旧配置文件可以加载而不报语法错误，并且它会报告该选项已被移除，而不是默默略过。识别一个名字和执行一种行为是两回事，现在仍然发生的只有前者。移除说明给出了原因：一旦参数可以协商，双方就可能在就连接达成一致的同时合法地持有不同的选项字符串。

因此，一个能被解析的配置文件并不能证明执行过任何准入检查。如果你唯一的信号是客户端连上了，那你只知道了语法被接受。

故障究竟在哪里

在改动任何东西之前，先保留第一个具体错误，因为后续消息通常是它的后果。数据通道协商失败属于已批准的加密策略以及双方实际宣告的能力。TLS 版本或套件失败属于控制通道。证书被拒绝需要的是身份和信任链，而不是兼容性标志。

还要确认两端所用的引擎。桌面应用可能打包了与你测试时所用命令行二进制不同的构建，两者的选项支持也不同。去查那个引擎的文档，而不是假定每个导入配置文件的程序都表现一致。

替换意图，而不只是那一行

如果较旧的自管服务器确实依赖这项一致性检查，请在升级前记录它当时强制的是什么约束。在较新的配置文件里保留一个被忽略的选项无法保住那项策略，随意删行同样不行。

不要用启用所有历史算法来回应“所有加密都被禁用”这类旧建议。

在批准的修正之后，用一条新连接检查协商结果，并测试用户真正需要的应用。把服务器版本和生效策略留在该结果旁边，好让下一个人看到商定的是什么，而不只是被接受的是什么。

目标是受支持的约束和可用的已认证路径，而不是一个仍能被解析的遗留标志。