OpenVPN 引擎还是 Tunnelblick：Mac VPN 会话归谁管？

Homebrew 安装的是 OpenVPN 程序；Tunnelblick 安装的是运行一个或多个引擎的管理器。它们属于不同层次，有用的问题不是你是否喜欢用终端。而是配置、DNS 改动、凭据提示以及会话结束时的清理归谁负责。这些层次只有一个所有者，配置才可预期。

按顺序做下面五项检查。第一个出现两个所有者的检查，正是那些被人归咎于 OpenVPN 本身的奇怪半连接状态的来源。每项检查都给出决定它的证据。

检查一：真正运行的是哪个 OpenVPN 二进制文件

连接时运行 pgrep -fl openvpn，读完整条命令行。第一个路径就是真正在运行的引擎。在 Apple Silicon 上，Homebrew 安装通常位于 /opt/homebrew 下，而 Intel Mac 使用 /usr/local，Tunnelblick 则从自己的应用程序包内部运行引擎。

Tunnelblick 打包了引擎，并允许配置选择其中一个。更新 Homebrew 公式改变的是独立二进制文件，而不是 Tunnelblick 配置文件启动的引擎。如果你通过比较版本来解释行为差异，应比较进程列表中的引擎，而不是包管理器里的那个。只看版本字符串无法告诉你该引擎加载了哪个配置文件。

被复制的配置文件也会让两个引擎看起来一模一样，而它们读取的其实是不同文件。命令行中的配置文件路径告诉你正在运行的进程加载了哪份配置；在编辑器里打开的配置文件并不是证据。比较行为之前先比较这个路径。

检查二：谁在改 DNS 和路由

引擎可以执行 OpenVPN 自己的 up 和 down 指令，但管理器可能掌管同一条生命周期。Tunnelblick 的名称服务器设置控制其标准的连接与断开脚本，启用该集成后，配置文件里互相冲突的指令可能被忽略。

这很重要，因为 DNS 正是看上去正常的隧道最常显得出问题的地方。连接时检查 scutil --dns，记下哪个解析器排在第一位，并确认断开后它恢复原状。如果配置文件想自己设置 DNS，而管理器也在管理它，两者必有一个会失效。

第一次连接前先决定 DNS 归哪一层管，然后删掉落败的指令，而不是两条都留着。路由改动遵循同一规则：只有一个所有者，在配置中可见，并有成文的恢复路径。

检查三：凭据从哪里来

交互式提示和无人值守进程的要求不同。一个应用保存的凭据不会自动对另一个进程可用，而限定给管理器的钥匙串条目，从 shell 启动的独立引擎可能根本看不到。

列出该配置文件的凭据来源：客户端证书和密钥、用户名密码提示，或外部助手提供的令牌。然后确认所选所有者能在无人值守时访问该来源——如果这条连接需要熬过重启的话。

检查四：谁启动、监督并停止进程

独立部署若要保持运行就需要一个监督者。Launchd 可以在登录时或按需启动引擎、崩溃后重启并干净地停止，但必须有人编写并拥有这个任务。在终端里跑命令只适合测试，不适合会关掉窗口的用户。

如果 Tunnelblick 仍是所有者，请使用它支持的控制方式，而不是再启动一个引擎。Homebrew 的二进制文件拿到复制的配置文件后，会以自身的配置和集成上下文打开一条独立连接，而不是去指挥现有的 Tunnelblick 会话。

无论选择哪个所有者，都要定义睡眠、网络切换和注销时会发生什么。管理器通常会处理这些事件；裸进程通常不会，由此产生的过期路由或解析器很容易被误读为服务器故障。

检查五：如何验证交接

先关闭旧所有者测试新所有者，若打算保留旧所有者，再测一次它。同一私有资源在一种工作流下能访问、另一种下不能访问，说明缺的是集成，而不是服务器。

交接给独立引擎时，记录配置文件路径、二进制路径、监督者、DNS 所有者和凭据来源。然后按此顺序验证私有资源、公网路径和干净断开。如果断开后 DNS 或路由仍然残留，说明新所有者还没做完。

交接给 Tunnelblick 时，为该配置选择引擎，启用你想要的 DNS 集成，并删掉与之冲突的配置文件指令。然后重复同样三项检查。连接能用但解析器被改掉，就是失败的交接，即使隧道成功建立。

打包方式并不能决定服务器兼容性。请查看服务本身的客户端要求，只有打算自己提供其管理能力时，才单独选用引擎。