为什么按应用配置的 VPN 覆盖不到 Android 应用的工作副本

同一款应用在工作资料手机上会出现两次，而这两个副本并不是同一个主体。在一个上下文内配置的按应用 VPN 只管理该上下文的实例，这就是为什么一条指明包名的规则仍可能让另一个副本保持原样。这不是需要绕开的缺陷，而是资料边界在做它被设计来做的事。值得回答的问题是：VPN 归哪个上下文所有，而你要保护的应用又归哪个上下文所有。

一个图标，两份安装，两个策略归属

Android 给工作资料一个独立受管的上下文，应用、账号和策略都是分开的，所以启动器可能显示两个同名同徽标的条目。在一个上下文内启动的 VPN 服务只为该上下文的用户工作，这正是整个问题背后的机制。图标告诉你点的是哪个应用，而不是产生的流量属于哪个资料。所以归属必须从资料读取，而不是从图标猜测。

组织还可以对受管一侧强制常开或断网即阻断的行为，这会改变隧道断开时的结果。个人一侧没有这样的保证，除非你自己搭一个。

允许列表到底意味着什么

Android 的按应用 VPN 支持建立在列表之上，相关内容写在 VPN 用户与工作资料指南 里；而且 两种列表的默认值正好相反。允许列表意味着只有点名的包走隧道，其余全部排除；拒绝列表则意味着除点名的包之外全部包含。把方向弄反，你就在设置界面看起来仍然合理的情况下做出了与预期相反的策略。列表是在 VPN 运行的上下文内部求值的，因此两个资料里都存在的包名只匹配该上下文中的副本。另一个资料里未列出的包，本来就不归这个 VPN 管。

把真正重要的两三个应用的行为写下来，因为除这些之外和只有这些的差别决定了个人应用是绕过隧道泄漏，还是以关闭方式失败。这里一张小表胜过一段文字：每个资料一行，写明列表类型以及其余项的默认值。

哪一侧运行隧道，又归谁的策略管

消费级 VPN 不会把组织的管控从受管资料上移除，工作资料 VPN 也不是个人应用的通用的隧道。如果组织要求受管应用使用自家客户端，那么个人客户端就是另一套安排，有自己的策略和失败方式。在比较结果之前先确定哪种机制承载哪部分流量，否则你就是在测量两套系统，还把差异叫成缺陷。在各自的上下文里，受管一侧通常获胜，这就是预期行为。

麻烦的情形是受管应用需要一条受管策略不提供的路由。那是向组织提出的例外申请，而不是停用工作资料的理由。

测试你真正指的那个实例

启动你在意的那份副本，并从内部查看请求，因为个人浏览器里查公网地址并不能说明工作应用的情况。分别验证已登录账号和内部域名解析，因为内部名称可能依赖受管路由，而公网浏览仍走别处。测试的当下记下哪份副本给出了哪个结果，并把资料写进标签；两张图标相同的截图不算证据。重连之后以及资料被重建之后都要重复检查，因为策略可能在这中间重新生效。

如果分不清是哪份副本应答的，先修好标注再下任何结论。含糊的结果比没有结果更糟，因为它日后会被当作已经解决问题来引用。

记录覆盖范围，让下一次测试还能用

为每个上下文一起记三件事：应用实例、策略归属和预期覆盖范围。这些足够下一个人复现你的测试，而不用猜他打开的是哪个图标。再加上列表类型和未列出包的默认值，因为人们最常读错的就是这一部分。

然后从每一侧各验证一个内部名称和一个外部地址，并写下受管一侧阻断个人 VPN 时应该发生什么。两侧看起来都连着、却都没有被覆盖的手机，才是值得在设计上防范的失败。当两个资料确实都需要隧道时，规划两套安排，而不是一条聪明的规则。