iPhone 上的 IKEv2 流量范围：覆盖范围由谁决定

你在 iPhone 上找一个「发送全部流量」开关，但它并不存在。在原生 IKEv2 配置文件中，路由范围由所下发的配置文件决定，而不是用户可以拨动的控件，因此在「设置」里翻找那个不存在的开关只会浪费一下午。正确的做法是向配置文件所有者索取书面的流量约定，然后用真实请求去验证。本手册用五步完成这件事。

在看手机之前先拿到书面约定

四个结果需要分别回答：上网是否应该走网关，是否只有私有资源才走，哪些本地网络和系统服务留在隧道之外，以及隧道不可用期间会发生什么。这些是不同的需求，由不同的键来满足。一个覆盖全部流量的配置文件和一个只覆盖单个子网的配置文件，在设备摘要页面上可能看起来一模一样。

还要确定配置文件归谁所有。如果它由管理服务下发，那么取值就存在那个控制台里，在手机上手工修改充其量只是一次临时的本地改动。如果没有人能说出所有者是谁，就把这当作发现并停下来；从手机上去猜测覆盖范围不会得到站得住脚的答案。

索取决定范围的四个值

覆盖键是 IncludeAllNetworks，Apple 文档称其在 iOS 14 中引入，正是它让连接广泛承载流量，而不只是发往网关推送的那些地址。本地例外是 ExcludeLocalNetworks，从 iOS 14.2 起可用，其文档记载的 iOS 默认值为 1，与 macOS 的默认值 0 不同。要问实际载荷里每个键取什么值，而不是从一份面向 Mac 的指南里假设平台默认值。

接着问 DNS，因为私有名称和公共名称分别由哪个解析器接收，属于同一份约定的一部分，并且有它自己的可达性要求。一条承载全部流量、却把私有名称留给公共解析器的隧道，会让每个只输入短主机名的用户觉得隧道坏了。先测这个场景，因为它最容易复现，也正是用户报「VPN 坏了」的那种情况。

签字之前先检查版本下限

这些键各有最低版本，而带有已装 iOS 不认识的键的配置文件不算是部分成功。覆盖推送通知和蜂窝服务的附加排除键也各有下限，因此为某个机群组装的载荷，在更旧的机群上可能只生效一半。在部署记录里把已装 iOS 版本写在载荷版本旁边。只生效一半的载荷比拒绝安装的载荷更糟，因为设备会报告一条你无法推断的隧道。

不要仅仅为了露出旧版本截图所承诺的控件，就安装一个来源不明的配置文件。如果提供的配置里没有某个键，那么这个键就没有生效，无论摘要页面暗示什么。

用流量验证，而不是看开关位置

配置完成后，打开目标私有资源和一页普通公网页面，确认两者都走约定所描述的路径。然后把手机切到蜂窝网络，重复这两项，并检查你为不可用情形记录的预期行为，而不是在测试时临时编造。要包含一次允许的 Wi-Fi 到蜂窝切换，因为范围偏窄的配置文件通常就在那里露出真相。

把受监管的托管 Always On 部署排除在这套比较之外。个人配置文件上的自动激活和广泛路由并不能证明那份托管策略，反之亦然。一次只在一台设备上测一种配置，因为同时装有两个 VPN 配置文件的手机会把你收集到的每个结果都搅乱。

回滚到已知的配置文件

当行为不对时，删除配置文件并重装最后一份已知良好的载荷，而不是在设备上改键值。然后重复同样的两个请求，确认此前的覆盖范围真的回来了。只恢复配置文件却不恢复路由的回滚不算回滚，而且发现它的会是用户，不是测试。

把载荷版本、那四个值和验证结果归档在一起，让下一次变更从有文档的基线开始，而不是从一张截图开始。