Apple Silicon Mac 上的 iPhone 版 VPN 应用：实际跑起来的是什么

有人在一台 M 系列 Mac 上装上 VPN 客户端的 iPhone 版本，它能打开、能连接，团队于是认定平台问题已经解决。并没有。在这里把「已解决」和「只是能跑」区分开的，是用户会话内的应用扩展与带全局上下文的系统扩展之间的差别。Apple 确实在「Mac 上的 iOS 应用」这一模式中支持报文隧道提供程序，并把这种部署单独列在原生 macOS 和 Mac Catalyst 之外。这项支持的含义比听起来要窄。它说明这种部署是被允许的，而不是说某个应用做得很好，也不是说隧道覆盖了你以为的范围。

三种部署，一张表

在 Mac 上有三种部署值得关注，它们不能互换。原生 macOS 客户端提供系统扩展，它在全局上下文中运行，可以在任何人登录之前就存在。Apple Silicon 上的 iPhone 应用提供应用扩展，它在用户会话内运行，并随会话结束。Mac Catalyst 与手机版属于同一个打包家族，但它是另一个目标，有自己的部署行。

下面这张比较是 Apple 部署指引里值得记住的部分，因为它能在给厂商打电话之前回答大部分设计问题。

先读打包那一列再看营销页：它对退出登录时会发生什么的预测，比任何功能清单都可靠得多。

一次成功的请求证明了什么

「Mac 上的 iOS 应用」这一行是真正受支持的部署，而不是模拟器的花招，这也是这个问题反复出现的原因。它同时继承了 Mac App Store 的分发方式，所以发行商从未开启 Mac 可用性的应用不会出现，无论开发者文档多么宽松。

能工作的连接证明：来自一个应用的一个请求到达了目的地。它并不盘点浏览器的解析器、被排除的应用、第二个地址族，也不盘点用户仍期望访问的本地设备。报文隧道只承载其路由和范围所声明的流量，而那个范围来自应用的配置，而不是隧道的存在。

缺口通常出在按应用覆盖

一个把所有流量都路由的客户端，描述起来容易，测试起来也容易。一个包含明确应用列表的客户端，需要这些规则在这次部署中被遵守，而不只在原生 Mac 版本中。对本地设备的访问、分离隧道的例外，以及任何依赖手机版从未有过的菜单栏项的功能，都撞在同一堵墙上。

请以书面形式索取范围，然后去测第二种情况，而不是第一种。谁都能演示浏览器通过隧道访问互联网。

两者在运维上分歧在哪

会话生命周期是最尖锐的差别，也是演示中最不显眼的一点。Apple 的记录是：应用扩展在用户上下文中运行，并在用户注销时结束，所以一台重启到登录窗口的 Mac 在有人登录之前没有隧道。如果需求涵盖一台必须在身份验证之前就受到保护的机器，手机版就无法满足，无论配置文件怎么写。

其余的都相对属于表面：菜单栏是否显示、DNS 如何呈现、隧道保持在线时应用能否退出。这些是真实的使用体验差异，但不是架构决策，所以把它们排在会话问题之后。

按固定顺序决策

有意识地排列问题：无人值守覆盖第一，按应用范围第二，分发第三，界面打磨最后。只有带系统扩展的原生客户端能回答第一个问题，而它通过 MDM 加受管配置文件到达设备。当有人坐在机器前、登录，并希望为那个会话建立隧道时，Apple Silicon 上的 iOS 应用是合理的答案。

在做出承诺之前，问发行商三个具体问题。报文隧道提供程序在「Mac 上的 iOS 应用」部署中是否受支持，按应用的规则在那里是否生效，以及退出登录时会发生什么。能在一封邮件里回答这三个问题的厂商了解自己的部署面；只回答第一个的厂商描述的只是一个能在 Mac 上打开的应用。

然后在你将要支持的那台机器上，用你实际会用的账户和网关去验证。在一台笔记本上连接测试网关的手机版是证据，不是部署。