如何在不丢失第一个 VPN 客户端的情况下测试第二个

你安装第二个客户端以便比较，结果第一个却停止工作。没有任何东西被删除，两个应用都仍然安装着。改变的是它们下面的东西：一个系统扩展、一项 DNS 设置或一条默认路由，而两个客户端现在对归属问题各执一词。安装并不是有风险的部分；有风险的是在没有记录基线可供回退的情况下同时运行两者。

症状：第二次安装后，原本可用的配置停止工作

现代 macOS VPN 客户端往往以网络扩展取代旧式接口。安装其中一个可能会要求批准、添加配置描述文件，或注册一个在任何连接建立之前就影响流量的系统扩展。扩展会在应用窗口出现之前加载，这正是新客户端闲置时原客户端可能失败的原因。

如果此后原客户端无法连接，或者连接了却什么都解析不出来，那么新扩展就是第一个嫌疑对象。这并不构成冲突的证据，但调查正是从这里开始。接下来检查扩展列表和已安装的配置描述文件，而不只是应用程序文件夹。

在安装任何东西之前记录基线

写下当前可用的内容：应用结果、客户端版本、连接的端点，以及任何按应用或分隧道设置的例外。通过客户端支持的受保护流程保存原始描述文件，而不是从应用程序包中复制文件。

scutil --dns | head -40
netstat -rn | head -30
ifconfig | grep -E "^(utun|ipsec)"

在可用的客户端连接时抓取这三项输出。它们给出解析器状态、路由表和可用配置所产生的接口列表，而这正是你稍后比较所需要的东西。如果这台 Mac 由雇主管理，请在开始前确认允许进行比较，因为自动的工作连接可能在测试期间重新激活，届时结果就不代表任何一个客户端单独的表现。把三项输出保存在配置备注旁边，以便后续比较有参照。

一次只改一条活动路径

用常规控制方式停止原连接，然后启动替代方案。两个客户端同时连接所得出的结果描述的是组合，而不是其中任何一个产品。如果服务允许，请保持端点和任务的可比性，因为通过不同服务器的更快下载比较的是两种连接方案，而不是两个应用。

如果新客户端失败，在改动其他任何东西之前先保留它的第一个错误。第一个错误通常会指明阶段，而改动设置后的第二次尝试往往报告的信息没那么有用。

比较 DNS、路由和应用，而不只是速度

在新客户端连接的情况下运行同样的三条命令，并逐行比较。指向别处的解析器，或缺少私有子网的路由表，在你查看吞吐量之前就能解释大部分行为差异。然后用同样的任务测试实际应用，因为一个连接很快却解析不了内部名称的客户端，即使状态窗口看起来更好，也没有赢得这次比较。

注意流量使用了哪个接口。在 macOS 上，隧道接口的名称并不能可靠指示哪个客户端拥有路由，所以要把接口列表和路由表配对来看，而不是只读其中一个。如果存在两个 utun 接口，承载你流量的那个才是有匹配路由和解析器条目的接口。凭名称猜测正是冤枉错误接口的方式，因为存在的接口并不总是承载流量的那个。

请阅读这三项输出，而不是匆匆扫过。在解析器转储中，绑定到 utun 接口的名称服务器表明是哪个客户端安装的；在路由表中，默认路由指明承载流量的接口；在接口列表里，第二个 utun 设备意味着创建了第二条隧道。把这三行与基线相比，就能区分已恢复的配置和两个客户端仍在争夺的配置。

恢复，然后干净地移除

通过原客户端自身的流程回退，并确认基线输出与你记录的一致。如果解析器或路由表没有恢复，请先停下来修好它，再移除其他东西。通过拥有该配置的组件来移除不用的设置：客户端卸载程序、描述文件或系统扩展设置。

最后在笔记中补上你测试的版本、使用的端点以及各自的结果。半年之后，这份记录就是决策与传闻之间的差别。