安卓（Android）网络栈中最近发现一个新的漏洞，任何应用都能借此把流量发到 VPN 隧道之外，即便已开启「无 VPN 时阻止所有连接」。流量泄漏意味着真实 IP 地址会在互联网上暴露，可能被用于追踪或监控。攻击不需要特殊权限。修复需要改动安卓系统本身。发现者已向安卓漏洞奖励计划（Android Vulnerability Reward Program）报告，但据其说法，问题被关闭且未采取行动。GrapheneOS 已知悉并正在修复。
正文
Android 网络栈中又发现了一个漏洞，恶意应用可以把流量发送到 VPN 隧道之外，即使开启了「无 VPN 时阻止所有连接」也一样。
流量泄漏到隧道外，意味着你的真实 IP 地址会在互联网上暴露，可能被用于追踪或监视。
这个恶意应用不需要任何特殊权限就能实施攻击。
要彻底修复需要在 Android 系统层面做改动。发现该漏洞的研究者已将其上报给 Android 漏洞奖励计划，但据研究者称，该问题被关闭且未采取行动。这一漏洞并未公开，但基于这些信息，我们认为 Google 不太可能有所动作。GrapheneOS 已获悉该问题，正在着手修复。
技术细节
该漏洞的手法，是让 Android 建立一条保活 UDP 连接，并将其卸载到硬件 Wi-Fi 或蜂窝芯片上。这条连接的本意是帮助完成网络地址转换（NAT）穿透，但恶意应用可以滥用它，向互联网上任意服务器发送 4500 端口的 UDP 包。由于这些保活 UDP 包直接从网络硬件发出，它们绕过了「无 VPN 时阻止所有连接」所要求的、所有流量必须经过 VPN 连接的检查，从而暴露设备的真实 IP 地址。
缓解措施
网络硬件同时只支持有限数量的保活连接，因此理论上的一种解决办法，是用某个应用自行创建保活连接直到占满容量为止。此后恶意应用就无法再创建自己的连接了。
Mullvad 目前没有计划自行提供这种理论上的缓解措施，因为它仍然意味着要把数据包发到隧道之外，哪怕目标是 Mullvad 自己的服务器。而且这种缓解并不保证有效，因为恶意应用可能在 Mullvad 应用启动之前就已经发起了泄漏。
结论
一如既往，最重要的是只在设备上安装可信应用，并且尽可能使用像 GrapheneOS 这样专注于安全和隐私的 Android 分支。
评论
讨论的基调相当一致地指向对 Google 的不信任：多数人从「无行动关闭」这个处理方式反推其动机，少数人则把注意力放在 VPN 流量本身的特征以及可行的规避手段上，对 iOS 是否存在同类泄漏则尚无定论。
认为 Google 最可能是故意保留或至少默许了这个泄漏
- 研究者的说法若属实，就不能排除 Google 有意引入或有意保留这条泄漏通道；「无行动关闭」本身就被当成证据，而不是疏忽（较多人） > 一个 Google 知道却放任不管的泄漏，已经不算 bug，而是他们觉得可以接受的特性。（@brinepot）
讽刺 Google 一贯如此
- 一句「好人 Google，一如既往」把整件事概括成可预期的行为模式，代表了不少人的情绪底色（较多人）
认为问题根源是 VPN 流量特征太明显
- 如果全部流量都去往同一个 IP、同一对源/目的端口，用户本来就没有隐藏任何东西，泄漏与否并不是唯一破绽（少数人）
建议用 WiFi 加路由级 VPN 并彻底避开蜂窝数据
- 让路由器强制所有流量走 VPN，配合只走 WiFi，是目前最稳妥的用法；蜂窝数据路径上无法保证（少数人）
- 有人提出用不具备蜂窝连接功能的 USB-C 无线网卡作权宜之计，但承认对蜂窝连接无济于事（少数人）
认为此事被严重低估
- 有人惊讶这么严重的问题居然没有引发更大范围的讨论（少数人）
肯定 Mullvad 的披露与 GrapheneOS 的响应
- Mullvad 的博文写得清楚，GrapheneOS 再次承担了善后修复的角色（较多人）
有价值的补充
- 更详细的技术分析见 supuk.ch 上关于 Android NAT-T keepalive 绕过 VPN 的论文，值得直接查阅。
- 该问题并非公开披露，Google 未采取行动，GrapheneOS 已知情并正在修复。
- 有人追问 iOS 目前是否存在同类泄漏，讨论中并未给出答案，这仍是一个悬而未决的问题。