从 OpenVPN 配置文件中删掉 key-method 什么也不会改变

一份用了多年的配置文件突然拒绝启动，而报错信息点出了一个没人记得加过的指令：key-method。下一条搜索结果建议为兼容性加上 key-method 2，那是另一个年代的建议。拒绝该行的解析器是当前版本，它根本没有这个选项。删掉这一行可以修好启动，而两端保护会话的方式丝毫未变。

配置文件里写着什么、协议实际做什么，二者之间的这道缝隙就是本文的全部主题，它也解释了人们常在同一时间做出的另外几处改动。它还解释了这些改动为什么往往成套出现。

症状是解析错误，而不是握手失败

选项在任何数据包发出之前就被读取。含未知指令的配置会在这一步失败，因此进程根本到不了网络，也永远不会产生握手错误。措辞通常会指出具体的选项和文件，这让它成为最容易归因的故障之一。其中不涉及任何数据包、路由或防火墙。

openvpn --config /etc/openvpn/client/office.ovpn --verb 3 --log /tmp/parse.log
grep -n 'Options error' /tmp/parse.log

如果报错点出了指令，诊断就结束了：文件里有这个版本不接受的东西。如果报错指出的是某个文件路径，那问题出在缺失的 include 或密钥，属于同一启动阶段的另一个环节。

不应得出的结论是客户端或服务器需要更旧的协议模式。解析失败是你的文件与二进制程序之间的词汇问题，而在这个例子里，二进制程序只是从自己的词表里删掉了一个词。

指令与线上格式是两回事

旧的 key-method 选项用来选择 TLS 密钥交换如何分帧，而现代的交换方式正是这个选项当年所要求的、多包完成的那一种。该选项消失，是因为它已无可选择；它所指定的格式成了唯一的格式。因此删掉这一行，会话仍然沿用与之前完全相同的分帧方式。文本改动无法在任何方向上改变这一点。

所以为了让「方式2」「复活」而退回旧版二进制程序，是错误的修法。它除了带回一个默认值更旧的解析器之外什么也没恢复，还让你失去此后积累的修复。同样的道理也适用于指望连接恢复而削弱证书检查或加密套件列表。

有用的核对是版本与解析后的配置，而不是文件里有没有那个词：

openvpn --version | head -n 1
grep -rn 'key-method' /etc/openvpn/ 2>/dev/null

该删什么，以及从哪个文件删

只改运行中的进程真正读取的那个文件。在打包系统上，通常是 unit 所指的客户端或服务器目录下的配置，而不是你放在主目录里备查的那份副本。生成的配置还可能由模板重新构建，所以只改已部署的副本，下次置备运行后它就会回来。

删掉过时的那一行，端点、证书、加密策略与控制通道设置都不要动。这些都是进程需要的受支持选项，与解析错误无关。如果同一份配置里还有你不认识的指令，请逐条对照你实际运行的版本，而不是先删掉一组、直到进程能起来为止。

然后启动目标实例并读取它的启动输出。监听器在位、启动干净，就说明这一阶段完成了；之后的客户端测试回答的是另一个问题。

被拒绝的配置与被拒绝的客户端看起来很像

两种故障会产生相似的求助帖，却需要不同的证据。拒绝自身配置的服务器根本起不来，因此没有任何客户端能连上它。能正常启动却拒绝某个客户端的服务器是在运行的，它的日志里有原因：证书问题、客户端不接受的推送选项、加密套件不匹配。

被删掉的那个选项不是第二种情况的诊断，指望它只会把同一个小时浪费两次。如果客户端日志显示的是服务器的拒绝，就去读那条拒绝；如果显示的是本地错误，要检查的文件就是客户端配置。去抓一个已不存在的指令，会让两项排查同样地慢下来。

这一行从来没有回答过的兼容性问题

带着这条指令流传的配置，通常附带着关于某个平台的说法，而说法往往比技术理由活得更久。移动端或桌面客户端仍然需要 一份完整且受支持的配置：可信的证书链、两端都接受的数据加密、两端都实现的控制通道模式，以及客户端版本不会拒绝的任何指令。这些没有一项是由旧的 key-method 行在不在决定的。

压缩是另一个形状相同、但彼此独立的策略问题。删掉一行 key-method，并不能说明你的部署是否支持或接受某条压缩指令，这两个决定应当分开做。为了连上而一次删掉好几项与安全有关的设置，正是一份能用的配置变成一份说不清的配置的路径。

把删了什么、为什么删简短记下来：那个选项、拒绝它的版本，以及显示错误的命令。下一个接手这份配置的人需要的正是这三条事实，而现在写下来比日后重建要便宜。