旧的 .ovpn 配置文件在 Ubuntu 24.04 上失效：该删掉哪些行

配置文件下载、导入之后，在文件第 12 行停住，报 Unrecognized option 并点出 keysize。账户本身没有任何变化，服务器也仍然接受其他客户端。变的是客户端本身：Ubuntu 24.04 安装的是OpenVPN 2.6，而这份导出是按 2.4 写的。修复就是删掉几行，顺序很重要，因为每一个过时选项都会在下一行被读取之前终止解析。

动文件之前先读报错行

OpenVPN 会指出文件和停止解析的行号，所以一次运行只能修一个问题。从终端而不是桌面小程序启动配置文件，因为小程序通常吞掉 stderr，而行号是你唯一可靠的线索：sudo openvpn --config /etc/openvpn/client/provider.ovpn。改完那一行再跑一次，下一个报错会点出另一个选项。

解析错误总是出现在任何 TLS 握手之前，所以提到证书的报错已经越过了语法阶段。这个区别能避免你去改一个只在认证阶段失败的配置文件。读报错的第一个词，而不是中间部分。

三类故障，三种不同的修法

旧导出会以三种可区分的方式失败，把它们混成一个问题，正是人们重装根本没坏的软件包的原因。报错的措辞会在你打开文件之前告诉你属于哪一类。

• 解析错误会指出文件和行号，并且在任何流量出现之前就停下。
• 协商错误能连上，随后报告两端无法就共享加密套件或可接受的数据通道达成一致。
• 认证错误走得最远，会点出证书、用户或被拒绝的凭据。

改配置文件只能修第一类。协商需要隧道两端共同决定，被拒绝的凭据根本不是语法问题。如果你的报错提到共享加密套件或数据通道，下面的删除不会有任何作用。

按这个顺序删掉 2.6 移除的选项

这些行每一行都会单独终止解析，所以客户端一次只报一个。顺着清单往下做，每删一行就重跑一次。

先删 keysize，因为它没有现代替代品，而且它的存在通常意味着当前客户端本来就会拒绝的加密套件。然后删 ncp-disable，它负责加密套件协商，在 2.5 中弃用、在 2.6 中消失。把 ns-cert-type server 换成 remote-cert-tls server，后者通过受支持的检查表达了同样的意图。2.6 变更历史 会把剩余的移除项与对应替代品列在一起，所以解析器仍然拒绝的任何东西都有据可查。

第一次修改前先留一份原始配置文件。提供商会重新生成导出，与未改动的文件做对比，是把自己的改动和他们的区分开的最快办法。如果删完之后客户端能启动但隧道仍然失败，你就已经进入了协商类，剩下的行不是原因。把客户端版本写进文件名，让下一个人知道这些修改针对哪个发行版。

只把 BF-CBC 保留为受限的兜底

有些提供商仍在用 BF-CBC 收尾，而 OpenVPN 2.6 在没有任何帮助下不会协商它，因为这个加密套件使用 64 位分组。窄口径的修法是兜底列表加上 OpenSSL 的 legacy 提供者，而不是把整个客户端降级。

providers legacy default
data-ciphers AES-256-GCM:AES-128-GCM
data-ciphers-fallback BF-CBC

第一行加载 legacy 提供者，让 OpenSSL 仍能实例化该加密套件；第二行对支持的同类保留现代协商；第三行只在服务器没有更好的选择时生效。这是有意识地削弱隧道，所以在文件旁边记下它为什么存在。同时向提供商索取重新生成的导出，因为兜底是桥而不是终点。

不要把 --compat-mode 当成万能答案。它会一次改变多个行为，包括协商和重新协商的默认值，所以你永远不知道哪个改动起了作用。优先用上面三行显式配置，因为每一行都写明自己的作用。

用客户端实际加载的那份配置来验证

导入的连接经常会被复制到系统目录，所以你改下载文件夹里的文件可能毫无作用。找到真正在跑的那一份：sudo grep -rl "remote " /etc/NetworkManager/system-connections /etc/openvpn。然后启动隧道，读那行报告实际选中数据通道加密套件的日志。靠兜底完成握手的连接说明服务器从未提供过现代选项。

换一个不是提供商预期的网络来测，免得强制门户或被过滤的访客网络被误当成配置故障。提交支持请求时一并写上客户端版本。

隧道起来之后，发一个必须走隧道的请求和一个不该走隧道的请求，然后确认解析器的回答按你的预期变了。如果配置现在能解析但连接仍然失败，你已经离开了语法问题，报错文本会点出新的类别。把改好的文件放进版本控制，并附上一条注明它针对哪个 OpenVPN 版本的说明。