鸿蒙OS TUN调试：多用户环境下的隔离问题

凌晨三点的崩溃：当我的“数字钱包”撞上鸿蒙的“用户墙”

凌晨两点四十七分，我盯着屏幕上的红色错误码，感觉太阳穴突突直跳。就在十分钟前，我还在为刚部署好的TUN虚拟网卡欢呼——那是我精心搭建的“隐私隧道”，专门用来中转那些见不得光的“链上交易”。可现在，这个本该在鸿蒙OS上畅通无阻的隧道，却像被一堵无形的墙死死堵住。更诡异的是，同一台Mate 60 Pro上，另一个用户空间里的同一套配置，居然跑得风生水起。

这已经不是第一次了。自从我开始在鸿蒙系统上玩转TUN调试，就总感觉有两个“平行世界”在打架：一个是我所在的“主用户”，另一个是那个用来测试的“访客用户”。而这场架，最终让我的虚拟币钱包差点被“冻结”在半路。

一、 那台“分裂”的Mate 60 Pro

事情得从三天前说起。为了避开交易所的风控，我习惯用TUN模式把流量全部加密转发到海外节点。在安卓上，这活儿轻车熟路——root后改个路由表，万事大吉。但鸿蒙不一样，它那个“多用户”机制，简直像给系统装了个“人格分裂器”。

我当时的操作是这样的：在主用户空间里，用adb push了一个编译好的TUN二进制文件，然后通过ip tuntap add创建了虚拟网卡。一切正常，流量哗啦啦地走隧道，延迟低得感人。我甚至得意地跟群友炫耀：“鸿蒙的TUN调试，比安卓还顺滑！”

可当我切换到“访客用户”准备测试另一个钱包App时，噩梦开始了。访客空间里，那个TUN网卡明明还挂在系统里，但ping 8.8.8.8直接超时。我以为是权限问题，赶紧用su切到root——结果系统提示“操作不允许”。更离谱的是，当我尝试在主用户里查看访客用户创建的TUN接口时，居然显示“设备不存在”。

那一刻，我意识到：鸿蒙的多用户隔离，不是简单的“应用沙盒”，而是网络栈级别的物理隔离。每个用户空间，都有自己的路由表、防火墙规则，甚至独立的虚拟网卡命名空间。也就是说，我在主用户里建的TUN隧道，对访客用户来说，就像不存在一样。

二、 虚拟币的“最后一公里”为何总卡在鸿蒙上？

你可能觉得，这不就是个系统特性吗？但对我们这些玩虚拟币的人来说，这简直是致命的。想象一下：你正在用主用户里的冷钱包App签名一笔大额交易，同时需要访客用户里的热钱包App去查询链上状态。两个App之间需要共享同一个TUN隧道来保证IP一致，否则交易所的风控系统会立刻标记为“异常登录”。

我尝试过很多“土办法”。比如，把TUN网卡设置成“全局模式”，但鸿蒙的ip rule策略路由会强制把访客用户的流量扔进独立的fwmark通道。我又试过用iptables做DNAT转发，结果发现鸿蒙的防火墙模块是“每用户独立编译”的——主用户里的规则，在访客用户里根本加载不了。

最崩溃的是那次“跨用户代理”实验。我写了个守护进程，想通过Unix Socket把主用户的TUN流量“桥接”给访客用户。结果进程刚启动，系统就抛了个SELinux权限异常，日志里赫然写着：“avc: denied { read } for pid=1234 scontext=u:r:su:s0 tcontext=u:objectr:systemdata_file:s0 tclass=file”。那一刻，我仿佛听见了鸿蒙安全团队在背后冷笑：“想跨用户？先过我这关。”

三、 鸿蒙的“用户空间”到底隔离了什么？

为了搞明白这个问题，我翻遍了鸿蒙的源码文档（没错，它开源了部分核心）。终于，在base/startup/init目录下，我发现了一个关键文件：user_config.xml。里面定义了一个叫network_zone的属性，每个用户空间可以绑定独立的网络命名空间。

更狠的是，鸿蒙在netd守护进程里加了一个“路由域”概念。每个用户空间有独立的RT_TABLE_ID（路由表ID），默认从100开始递增。当你创建TUN设备时，系统会强制把该设备绑定到当前用户的netns里，并自动生成一条ip rule：“from all lookup 100 pref 1000”。这意味着，即使你手动添加了全局路由，也会被这条高优先级规则截胡。

我试着用ip netns exec进入访客用户的命名空间，结果系统直接报错：“Operation not permitted”。后来才发现，鸿蒙的netns创建权限被SELinux策略锁死了——只有system_app域或shell域（且需allow_netd_domain权限）才能操作。普通App的进程，连unshare(CLONE_NEWNET)都调用不了。

四、 那个“救命的”虚拟币节点，差点被系统杀掉

就在我快要放弃时，灵光一闪：既然不能跨用户共享TUN，那能不能让两个用户共用同一个物理网卡，但通过不同端口走不同的隧道？说干就干，我写了个“端口转发守护进程”，监听在0.0.0.0:1080（主用户），然后把流量通过iptables REDIRECT到访客用户的127.0.0.1:1081。

结果，更诡异的事情发生了。访客用户里的App，居然能正常访问127.0.0.1:1081，但一旦我尝试从主用户向访客用户的127.0.0.1发HTTP请求，就卡死。我抓包一看，发现鸿蒙的loopback接口也是“每用户独立”的！主用户的lo接口，在访客用户里根本不存在。也就是说，鸿蒙把回环地址都隔离了——这简直是“网络级虚拟机”。

最后，我是怎么解决的？答案是“放弃治疗”。我改用了鸿蒙官方的“多设备协同”功能，把访客用户里的钱包App，通过分布式软总线转发到另一台旧手机上。虽然麻烦，但至少数据能通。不过，代价是每次交易都要跨设备确认，延迟从5ms飙升到了200ms——对一个高频交易者来说，这简直是灾难。

五、 虚拟币玩家，请收下这份“鸿蒙避坑指南”

如果你也像我一样，想在鸿蒙上玩TUN调试，我劝你先做好心理准备。以下是我用血泪换来的经验：

第一条：永远别指望跨用户共享TUN。 鸿蒙的netd会强制隔离路由表和防火墙规则，即使你通过adb shell手动改ip rule，重启后也会被恢复。唯一的例外是，如果你有系统签名权限（比如刷了Magisk模块），可以修改/data/system/users/0/package-restrictions.xml，把目标用户标记为“共享网络”。但这样会破坏系统安全模型，不推荐。

第二条：用“虚拟AP”绕过隔离。 我后来发现，如果创建了一个Wi-Fi热点（SoftAP），然后让访客用户连接这个热点，流量就会走主用户的网络栈。原理是鸿蒙的SoftAP默认绑定到主用户空间，访客用户通过wlan0访问时，会经过主用户的NAT转发。但这样做的缺点是，热点加密方式只能是WPA2，且手机发热严重。

第三条：实在不行，就“双开”虚拟机。 鸿蒙的“平行空间”功能（双开应用）其实会创建轻量级虚拟机，每个虚拟机有自己的虚拟网卡。你可以在主用户里跑一个“平行空间”实例，然后在里面安装TUN工具。但注意，平行空间的性能损耗约30%，而且不支持raw socket——所以像tcpdump这种工具基本废了。

第四条（终极方案）：放弃TUN，改用SOCKS5代理。 如果你只是想让虚拟币钱包走代理，别用TUN了。直接在鸿蒙的“设置-网络-代理”里填上SOCKS5地址，系统会全局代理所有流量（除了系统自带应用）。但坑的是，鸿蒙的代理只支持HTTP和SOCKS5明文，不支持HTTPS代理。所以，你得自己搭一个带TLS加密的SOCKS5服务端。

六、 凌晨四点的顿悟：鸿蒙不是安卓，它是“另一个物种”

当我终于搞明白这一切，天已经蒙蒙亮。我坐在电脑前，看着那个失败的TUN配置，突然笑了。鸿蒙的多用户隔离，不是bug，而是它设计哲学的一部分——每个用户都是“一等公民”，拥有独立的网络主权。这种设计，在安全上确实无敌（比如防APT攻击），但对开发者来说，简直是噩梦。

但换个角度想，这也是一种“进化”。在安卓上，我们习惯了“全局root + iptables”的粗暴玩法，而鸿蒙逼迫你重新思考网络架构。或许，这就是华为的野心——它想让你在鸿蒙上，只能通过“合法”的分布式API来通信，而不是像安卓那样随便搞个代理就能翻墙。

至于我那个虚拟币钱包？最后我用了最笨的办法：把访客用户里的App，全部迁移到主用户，然后用frida hook掉它的root检测，让它在主用户里直接跑。虽然风险高，但至少TUN隧道能用了。不过，每次系统更新后，frida脚本就得重写一遍——这大概就是“鸿蒙式修行”吧。

现在，我偶尔还会在凌晨三点醒来，盯着那台Mate 60 Pro的屏幕，仿佛能看到两个“平行世界”在后台默默运行。一个世界里的我，正用TUN隧道流畅地交易；另一个世界里的我，却在对着Permission denied发呆。而那个鸿蒙系统，就像个冷眼旁观的裁判，用netns和SELinux筑起一道道高墙，提醒我：在鸿蒙的世界里，没有“全局”这个概念，只有“用户”和“隔离”。