Apple IncludeAllNetworks：仍在绕过 VPN 的是什么

你在 MDM 控制台打开配置文件，看到 IncludeAllNetworks 已被勾选，便以为这台设备的每个数据包现在都会进入隧道。Apple 自己的 schema 并没有这样承诺。这个设置是带着例外把流量送进 VPN 的：有些例外是可选开关，有些则是系统能继续运行所必需的。下面的梳理沿着这份文档从配置文件向外展开，所以你最先读到的是设置本身，而不是一台谁都还没确认过身份的设备的抓包记录。隧道外的行为并不自动等于故障，但也不自动等于没有例外。

这些例外中有两个能解释大部分混乱，而且都与蜂窝服务有关。

从受管理的配置文件开始，而不是从抓包开始

在读任何数据包日志之前，先打开受管理 VPN 配置文件的 schema，读一读属性说明。注意这段说明讲的是带例外的路由，而不是完整隧道的保证。就是这一句话，决定你如何理解之后看到的一切。

在控制台里顺手记下三件事：承载该设置的 payload 标识符、设备上受管理的操作系统版本，以及实际安装的是哪个 VPN 实现。这三项会决定后面每一次判断的边界。文档里描述了某个键，并不代表第三方客户端会在自己的配置界面里把它暴露出来。

把蜂窝例外读成两种不同的情况

在受支持的配置中，ExcludeCellularServices 会排除可经互联网路由的蜂窝服务流量，但前提是它与 IncludeAllNetworks 同时启用。schema 举的例子包括 Wi-Fi Calling、IMS 以及与消息相关的服务。这些流按设计就可以离开隧道，只要例外开着，再怎么检查配置文件也不会让它们走隧道。换句话说，这个开关决定的是这类流量是否可能走隧道，而不是它此刻有没有走隧道。

第二种情况是独立的，不依赖任何开关。有些运营商直接通过自己的网络、而不是互联网提供蜂窝服务，Apple 把这一类记录为始终排除在隧道之外。它不是上面那种有条件的、可经互联网路由的情况，所以即便把每个例外勾选框都清空，配置文件仍然抓不到它。这也解释了为什么逐项清空配置仍然可能看到同样的行为。把两者当成同一个特性，正是大多数关于泄漏的争论的起点。

如果你的要求字面上就是任何数据包都不得离开隧道，那么在蜂窝设备上，第二种情况已经让这个要求不可能成立。这一点必须在设计评审之前知道，而不是之后。

检查你的平台实际暴露了哪些键

schema 还描述了必需的网络连接流量和 captive 网络流量，以及针对本地网络、设备间通信等其他类别的独立控制项。这些是有文档记录的配置关系，不是对你设备的观测。要针对你所管理的操作系统版本逐项确认，因为不同版本之间可用性会变，而一个被静默忽略的配置键，看起来和一个正常工作的键完全一样。逐项确认不是形式，它能排除掉一半看起来像泄漏的案例。

这类决定所需的最小 payload 通常如下，蜂窝标志要显式写出，而不是从模板继承：

<key>IncludeAllNetworks</key><true/>
<key>ExcludeCellularServices</key><true/>
<key>ExcludeLocalNetworks</key><true/>

如果交付的配置文件缺少某个键，设备会回落到该键的默认值，而这个默认值未必是模板作者设想的那个值。要把交付的 payload 与模板做差异比较，而不是只读模板。

弄清一个陌生主机名到底是什么

出现可疑名字时，先确定这条观测到底代表什么：是系统请求的名字、做出应答的解析器、连接的目的地，还是某个工具打印出来的标签。单凭一个与运营商相关的名字，既不能确定发起进程，也不能确定实际生效的例外。把它当作绕过的证据去追，正是支持帖子把一周时间花在错误层面上的原因。先把观测归类，再谈它是否异常。

使用受支持的诊断手段，与拥有该配置文件的管理员沟通，然后把实际流量与预期策略作比较。能告诉你流量是否在预期之内的，是这个比较，而不是主机名。把比较结果写下来，比在聊天里争论有用得多。

解决需求，而不是削弱系统

不要仅仅为了让抓包安静一点，就安装来路不明的根证书或关闭系统服务。让抓包安静下来，等于抹掉证据、把例外留在原处，这比原来那个问题更糟。如果某条合规规则禁止了平台有意排除的类别，请带着 schema 的相应章节，把这个冲突交给设备与网络的所有者。

收尾时记录：是哪个例外解释了这段流量、它适用于哪个操作系统版本、是哪个配置值造成的。一个连接图标无法调和两种互不相容的假设，即操作系统到底把流量范围划到多远。