Mac VPN 客户端：Network Extension 与 System Extension

Apple 的两个术语常被当成同一回事使用，这种混淆会把人带到错误的设置面板。Network Extension 描述一种能力：实现 VPN 隧道、代理和筛选器的受支持方式。System Extensions 描述用户空间扩展的交付与批准机制。现代 Mac VPN 客户端通常两者都需要，因此任何一个标签都无法单独解释症状。把两者分开，才能确定该检查哪个组件、该期待哪一步批准。

两个问题，不是一个标签

先问组件做什么，再问它如何安装。能力决定存在哪个提供者类，因而决定哪段代码处理你的数据包。交付机制决定二进制文件如何到达、如何获得批准，以及状态记录在哪里。产品可以在旧版本上不交付系统扩展而实现数据包隧道，也可以交付一个实现隧道之外功能的系统扩展。

内核扩展是人们混入的第三个术语。它是运行特权网络代码的旧方式，需要不同的批准，Apple 多年来一直引导开发者远离它。把内核扩展的批准套路套到现代客户端上，只会在一个永远不会出现的对话框上浪费时间。

阅读厂商针对你所运行 macOS 版本的部署说明 而不是早先版本的论坛帖子。架构改过不止一次，说明很快就过时。提到内核扩展批准的说明，描述的是产品的另一个时代。

Network Extension 提供什么

该框架为常见网络工作提供提供者类型：用于 VPN 流量的数据包隧道、用于按应用分流的应用代理、用于检查流量的内容筛选器，以及用于解析器行为的 DNS 代理处理。提供者类型决定扩展能做什么，同时交付两个提供者的客户端可能在执行两项不同的工作。

这在诊断时很重要，因为同一个连接症状可能来自隧道、筛选器或 DNS 代理。屏蔽网站是筛选器的决定，无法访问私有子网通常是隧道的决定，解析到错误地址通常是解析器的决定。说出提供者类型，就能在读取任何日志之前缩小范围。

框架本身不暗示任何隐私立场。用户空间扩展仍然有权限、配置和背后的运营者，因此应把架构当作实现细节，而不是信任信号。要问谁运营该端点，以及它被配置来收集什么。

System Extensions 改变了什么

该机制把特权代码从内核移到用户空间，并改变操作系统请求同意的方式。激活是与安装分开的步骤，需要用户或 MDM 描述文件允许。安装了却从未激活的客户端 看起来存在于 Applications 文件夹，但对连接毫无作用。

状态由系统而非应用记录，这很有用，因为可以查询。下面的命令列出系统已知的扩展及其激活状态。

systemextensionsctl list
scutil --nc list

第一条命令回答组件是否已安装并激活。第二条列出系统持有的 VPN 配置，这是另一个问题，而且往往是连接描述文件缺失而非损坏时真正要紧的那个。

针对某种症状该检查哪一个

在打开设置面板之前，先把症状对应到层次。配置缺失是描述文件问题，已安装但未激活是交付问题，而能激活却传不了流量是能力问题。

最后两行的共同证据是日志流。读取网络扩展子系统能看出哪个提供者处理了该流，而筛选器的决定看起来与隧道故障不同，即使使用者把两者都说成 VPN 坏了。

log show --last 10m --predicate 'process == "nesessionmanager"'

不要因为菜单栏里有图标就断定扩展已激活。图标在激活失败后仍会保留，而过时的图标正是支持电话从错误地方开始的最常见原因之一。应读取激活状态，因为那才是系统记录的内容。

批准、MDM 与内核扩展的迷思

在受管理的 Mac 上，批准步骤属于 MDM 描述文件，而在系统设置里点了允许的使用者仍可能被未更新的策略挡住。在请使用者点击任何东西之前，先问桌面团队这套设备由哪种机制批准扩展。

在未受管理的 Mac 上，批准提示只出现一次，一旦拒绝就可能永久生效，直到重装扩展。这一行为解释了那台在系统升级前还能用、如今却报告连接永远建立不起来的机器。

把所部署客户端的提供者类型、激活状态和批准机制写下来。这三项事实能回答未来大多数关于 Mac VPN 的问题，而不必重新打开能力与交付之争。