抓包助手到 VPN 隧道的重构

【踩坑实录】抓包助手到 VPN 隧道的重构

▍现象
网络分析工程（抓包巨兽）的移植先决难题：桌面版抓包靠独立抓包进程加系统底层套接字（需要 root 权限），鸿蒙应用没有 root、也没有那个套接字通道——上游的抓包模型整体失效。GUI 再好，抓不到包就是空壳。

▍定位过程
需求的本质拆解：要的不是 root，是全设备网络包的可见性。鸿蒙上有一个合法通道恰好提供这个：VPN 扩展能力——建 TUN 隧道后，设备的 IP 包流经应用可读写的虚拟网卡。工程架构就此定型（记录登记）：GUI 侧整体保留上游界面（十五万行 Qt 界面重写不现实）；抓包侧用 VPN 扩展建 TUN 隧道截获全设备 IP 包，在扩展进程内写成标准抓包文件交给界面解析。

▍实现的关键件
权限挂载位置：网络与后台权限挂在 VPN 扩展而不是主应用——权限跟着能力走，形态即架构。数据通道：扩展进程写抓包文件，GUI 侧轮询增量读取（约一秒级的刷新节奏配界面重载接口——实时性的工程折中）。用户交互：VPN 的系统授权弹窗是用户感知的入口（启动抓包即建立隧道，系统弹窗说明用途——合规且透明）。

▍根因抽象
无 root 不是绝路，是换路：抓包类需求在移动系统的正解是 VPN 隧道（设备级包可见的合法通道）。同类需求（广告过滤、流量监控、网络调试）都走这条路——通道是同一门技术，用法各自工程化。

▍方法论沉淀
能力失效时的提问顺序：这个能力的本质是什么（包可见性）、系统有没有合法通道（VPN）、通道的成本与限制（授权弹窗、扩展进程模型、性能）。三问答完，架构就出来了。

TUN 隧道抓包的完整架构记录在网络分析工程实录，apps 板块 56 篇欢迎对照。