iPhone VPN 的 MTU：先确定归属，再改数字

每个关于 iPhone VPN 包大小的帖子，最后都会给出同一条针对名为 ppp0 的接口的 Mac 命令，通常还带一个数字。这条命令搬不过来；即使在那台 Mac 上，除非该接口属于所讨论的连接，它也不是正确的控制点。在手机上，这个数字归实现隧道的一方所有：原生配置归操作系统，应用归数据包隧道提供方，协商文档化属性时归网关。三个问题能分清你面对的是哪一种。

问题一：运行的是哪个客户端

原生 IKEv2 配置、内置 Cisco IPsec 配置和第三方 Cisco 客户端是三种不同实现，支持的属性集合也不同。设置里的配置类型告诉你手机实际启动的是哪一个，应用列表则告诉你路径上到底有没有提供方。先从那里入手，其余判断都由它推出。如果应用列表里没有出现任何提供方，隧道就归操作系统所有。

不要从网关厂商反推实现。Cisco 头端可以终结那些除厂商名之外毫无共同点的客户端连接。旧版本上旧构建的截图说明的是那一组合支持什么，而不是你手里的手机在做什么。

问题二：这个值归谁

Apple 通过网络扩展设置对象，向数据包隧道开发者开放 MTU 属性。这是给自行配置隧道的提供方用的 API，不是用户或管理员能在别人的已安装客户端上拨动的开关。第三方应用可以选择公开它、忽略它，或把某个值写死。

原生配置下，接口大小由操作系统选择，手机上没有任何编辑器可改。Cisco 远程访问网关有文档化属性用于连接配置，而它是否生效取决于客户端、版本和协商出的传输方式。文档写了却不被遵守的那个空档，正是抄来的数字出错的地方。

问题三：症状到底是否与大小有关

大小问题有明显特征：小请求成功，大上传或大响应卡住，而同一服务换一个接入网络就正常。过滤、应用负载上限和服务器卡死也会产生类似投诉，所以把失败的那一次操作和成功的一次并排记录下来。如果应用会报告时间和大小，两者都写上。没有这一对，之后每次改动都是猜。

在 Wi-Fi 和蜂窝网络上做同样的测试。跟着网络走的故障指向路径；跟着设备走的故障指向客户端或配置，两者需要不同的负责人。两次运行要用同一服务和同一账号，否则比较毫无意义。

为什么 Mac 那套做法反复出现

多年基于 PPP 的桌面 VPN 让改接口大小成了合法的本地绕行办法，那些说明又被抄进了手机端的讨论。手机上既没有 shell，也没有这样的接口名，重连之后更不会保留。2011 年解决桌面问题的做法，比让它成立的那些前提走得更远。无论帖子里怎么说，手机客户端都不接受任何 shell 命令来改这个。

把抄来的值当作关于路径的假设，而不是一项设置。如果较小的大小让传输跑通、较大的稳定失败，你就有了关于路径的证据；但你仍要找到有权对它动手的组件。这个查找通常停在网关配置或应用厂商那里，很少停在手机上。

传输方式会改变答案

如果会话跑在 TLS 而不是 IPsec 上，网关上的 TCP 分段调整可能有帮助，因为它会重写 TCP 流对外宣告的分段大小。它对 UDP 流量毫无作用，而现代网页里 UDP 的占比比多数人以为的更高。提出改动之前先确认协商出的传输方式，并在工单里写明你预期影响哪一种。

路径 MTU 发现的存在，是为了让两端学到真实上限而不是靠猜。屏蔽反馈并把大小写死，等于用一次能跑通的大传输，换取每条连接上永久且隐蔽的代价。

该向网关团队问什么

要三样东西：属性的准确名称及其作用范围、已部署客户端是否遵守它、会话协商的是哪种传输方式。只对一条组策略做改动可以验证；全局修改则不行，而且会把风险转给从未报过问题的用户。还要索取文档出处，因为属性名在版本之间会变。

然后只改一处，重新测试原来失败的那次操作，而不是测速下载。把改动前后的记录连同客户端版本和接入网络一起留存，这样下一份报告可以对比，而不必重新争论。

如果原来的大小下操作仍然失败，那么大小并不是原因。把这个结论也记下来，免得下一个人重开同一个假设。