Tunnelblick data-ciphers 无法识别：究竟是哪个引擎在运行？

Tunnelblick 报告 data-ciphers 选项无法识别，同一句话里又提到 OpenVPN 2.4，而连接始终无法启动。这是本地解析失败，而不是密码套件分歧，因为引擎在与网关进行任何协商之前就拒绝了配置文件。关于服务器密码策略的常规建议在这里帮不上忙；解析器必须先读懂文件。找出这个配置实际启动的引擎，其余问题自然迎刃而解。

先读日志行，再动配置文件

在 Tunnelblick 的详细信息窗口中打开失败的连接，从顶部开始读日志。最前面的几行会写明引擎版本和交给它的配置文件，接着是让解析停止的那个选项。之后的内容都是噪声，因为进程已经退出。

从日志中记下三件事：引擎版本、配置名称和确切的消息。这三项就是完整的诊断。如果修复最终需要改动已安装的应用程序，它们也正是你需要的。请截图保存这些行，而不是凭记忆复述，因为选项名很容易抄错。

确认该配置运行的是哪个引擎

Tunnelblick 是一个包裹在 OpenVPN 引擎外面的应用程序，不同配置可以运行不同的引擎。请在详细信息窗口中查看为这个配置选定的版本，而不是去读应用程序版本，也不要用该配置从不使用的终端 openvpn 二进制文件的输出代替它。Tunnelblick 的 OpenVPN 版本指南 说明了这种选择如何生效、选择保存在哪里。

这个区别很重要，因为一台机器可能在 PATH 上装有新版二进制文件，而失败连接背后用的是随附的 2.4 引擎。评估配置文件的是后者。

openvpn --version
ls /Applications/Tunnelblick.app/Contents/Resources/openvpn/

这两条命令显示了终端会运行什么，以及已安装的应用程序带有哪几个引擎目录。两者都不能证明失败的配置用了哪一个，因为日志已经告诉了你，而且不同 Tunnelblick 版本的路径并不相同。

为什么指令名变了

OpenVPN 在 2.5 中引入 data-ciphers 作为协商列表，取代了在该版本中已弃用的旧写法 ncp-ciphers。2.4 引擎没有这个选项，所以它会停在第一个不认识的标记上。单独的 cipher 选项也不是列表的旧别名；它指定的是单个密码套件，而不是一组协商选项。

正因如此，跨版本替换文本会生成能够解析、随后行为却出人意料的配置文件；也正因如此，从论坛帖子里复制片段并不等于版本核对。选项名连同回退处理和默认值一起变了，把一条指令改个名字拼出来的文件，并不等同于为那个引擎编写的文件。

要修引擎或配置文件，而不是症状

对于受支持的部署，持久的修复方案是受支持的 Tunnelblick 与引擎组合，并且接受运维者的配置文件，这需要通过负责应用程序安装的人来安排。如果旧安装还必须保留一段时间，就请对方提供为该引擎编写、并使用网关真正接受的密码套件的配置文件。

删除 data-ciphers 和 data-ciphers-fallback 确实能消除这个特定的解析错误，这正是它诱人的原因。但它也会在你并不打算改动的安全配置中，悄悄改变协商哪些密码套件。请保留原始配置文件，转而有意地比较受支持的设置。

重试并阅读下一阶段

修正之后，请重试连接，并从开头阅读新的日志，而不是想当然地认为成功。现在能够解析的配置文件仍可能停在密码协商、证书验证、身份验证或路由上，而每一种失败都有自己的证据。

如果协商失败，就比较双方各自支持的密码套件与各自允许使用的密码套件。如果身份验证失败，说明配置文件和引擎已经足够正常，至少到达了网关，这是值得记录的进展。在第一条安静的日志处就停下这条链，正是安全设置在错误理由下被删除的方式。