禁用 Android 上的 VPN 配置：上线检查清单
先定政策、确认你真正拥有的权限、核对各版本行为，并在强制执行前保住已批准的常连通道。
有人要求你阻止人们在受管的 Android 设备上自行配置 VPN。诱人的答案是一条防火墙规则，封掉几个熟悉的端口。这个答案忽略了平台如何运作，也忽略了应用实际如何建立连接。
受支持的控制手段是所拥有设备或配置档上的一项管理限制，它有明确的适用范围、随版本变化的行为，以及一个必须刻意配置的例外。
按顺序走完下面五项检查。任何一项都可能让计划作废，所以只要有一项站不住就停下。
检查 1：先确定“没有 VPN”到底指什么
同一句话背后藏着两种需求。一种是任何用户都不得自建 VPN；另一种是只允许组织批准的 VPN 运行。两者都合理，但它们带来不同的配置、不同的支持说辞和不同的故障模式。
在动任何管理控制台之前，先写下你买的是哪一种。如果意图是给所有人一条获批隧道，那你是在实现一条带禁区的获批通道；如果意图是完全不要隧道，你也必须接受远程访问和排障路径会随之改变。
这一步弄错，上线看起来照常运行，却在悄悄掐断运维所依赖的 VPN，通常由值班的人在不太合适的时间发现。
检查 2：确认你实际拥有的权限
Android 通过 UserManager.DISALLOW_CONFIG_VPN 暴露这项限制，文档见 UserManager 参考。它阻止 VPN 的配置与启动，而且不是普通应用能对自身或其他应用施加的设置。
它由获授权的管理员施加：整个设备上由设备所有者执行，受管配置档上由配置档所有者执行，受管配置档内部也向配置档所有者提供同样的权限。如果你的 EMM 无法充当其中任一角色，你就不具备这项控制，控制台里再怎么配策略也变不出来。
适用范围与权限同等重要。施加在工作资料上的限制只管那个资料，管不到同一部手机的个人一侧。把这说成“对用户一切行为的掌控”并不准确，第一个在个人资料里装 VPN 并发现它能用的人就会来验证这一点。
检查 3：弄清各版本的行为
这项限制在不同版本间有过变化，差异决定了你的上线在现场设备上到底会做什么。
| 平台边界 | 文档记载的行为 |
|---|---|
| 设备所有者或配置档所有者 | 可在该所有者的权限下施加这项限制 |
| API 24 及更高版本 | 由设备或配置档所有者配置的常连 VPN 仍会由系统启动 |
| API 31 及更高版本 | 开启限制会断开用户已在运行的 VPN |
API 31 那一行才是上线中途让人意外的：在这些设备上，执行不是做样子，它会直接断开一条已在运行的隧道。要把它当作可见事件来规划，而不是一次无声的设置变更。
API 24 那一行是救你的：所有者配置的常连 VPN 能在限制下存活，获批通道靠这条才不至于彻底不可用。
检查 4：保住获批通道
要在执行限制之前配置并测试组织的常连 VPN，而不是之后。若先执行，设备会同时失去隧道和用来诊断它们的工具。
明确核对三件事：常连 VPN 是由所有者而非用户创建；执行后它确实在这些设备上启动；它能在重启后存活。只能手动起来的隧道不算获批通道，那是支持工单队列。
保留一条不依赖隧道可用的恢复路径。管理控制台、本地管理员路径或带外通道都行。行不通的是：指望通过策略刚刚断掉的那条连接去修复坏掉的策略。
检查 5：先验证，再如实说明边界
用真实设备和真实账号测试。确认用户无法添加或启动 VPN，确认获批隧道能连上并承载流量，确认个人资料仍按文档所述行事。这三项结果就是验收标准。
然后注意你的说法。这项限制管的是 Android 的 VPN 能力，它不会把每条被允许的连接变成被检视的协议，也挡不住应用通过显式代理转发自己的请求。封掉 UDP 500、UDP 4500 和一个 OpenVPN 端口并不是同一种控制，因为流量可以走多种承载方式，包括看起来普通的 HTTPS。
如果需求比 VPN 能力更宽，就把这项控制与应用分发策略、账号管控和适合环境的网络限制结合起来。并把留在范围之外的部分记录下来，免得下次审计时有人把部分限制当成完整方案复述。