鸿蒙OS VPN路由与USB网络共享：路由配置要点

当矿机在鸿蒙上“流浪”：一场关于VPN路由与USB共享的生死时速

凌晨三点，深圳华强北的某个不起眼的仓库里，老周盯着手机屏幕上跳动的算力曲线，额头上渗出细密的汗珠。他的“矿场”不是传统意义上的机房，而是五台改装过的鸿蒙OS开发板——每块板子都拖着一条USB线，连着一台老旧的安卓手机，而手机又通过Wi-Fi接入了一个虚拟专用网络（VPN）。这套看似荒诞的架构，是他过去两周在“挖矿”圈子里摸索出的“游击战法”：利用鸿蒙OS的分布式能力，把手机当作临时算力节点，再通过VPN穿透运营商封锁，把算力“卖”给海外矿池。

但今晚，系统突然崩溃了。日志显示，VPN隧道在USB网络共享的接口上反复重连，路由表乱成一团，数据包像无头苍蝇一样在鸿蒙的软总线里打转。老周猛灌一口红牛，手指在终端里飞速敲击——他知道，这场与网络栈的搏斗，才刚刚开始。

第一幕：USB网络共享——鸿蒙的“数据脐带”与路由陷阱

老周的第一块开发板，代号“蜂鸟”，是通过USB连接手机上网的。在鸿蒙OS里，USB网络共享（USB Tethering）并不是简单的“插上就通”。它会在系统里创建一个虚拟网卡，通常命名为usb0或rndis0，并分配一个私有IP段，比如192.168.42.x。手机端则作为网关，负责把数据转发到蜂窝网络或Wi-Fi。

问题出在路由表。当老周同时开启VPN时，鸿蒙的netd守护进程会尝试为VPN建立一条默认路由（0.0.0.0/0），指向VPN隧道接口tun0。但USB共享接口usb0也会携带一条默认路由——因为手机在USB共享时，会强制下发“默认网关”给开发板。两条默认路由同时存在，系统只能根据“路由优先级”（metric值）来选路。默认情况下，VPN接口的metric值通常更低（更优先），但鸿蒙的某些版本在USB共享场景下，会错误地把usb0的metric设为0，导致所有流量直接冲向USB口，VPN形同虚设。

老周的解决方案很暴力：手动修改ip route表，删除usb0上的默认路由，只保留一条指向手机网关的静态路由（仅用于DNS和DHCP），然后把所有业务流量强制指向tun0。他在终端里敲下：

ip route del default dev usb0 ip route add default dev tun0 table 100 ip rule add from all lookup 100 pref 1

但鸿蒙的“网络管家”会在几秒后自动重置路由表——这是系统级的安全机制，防止用户误操作导致断网。老周必须用ip rule加一条高优先级的fwmark规则，让VPN隧道的数据包绕过系统检查。他打开鸿蒙的“开发者模式”，在/data/local/tmp下放了一个route_fix.sh脚本，用nohup挂起一个循环，每500毫秒执行一次路由修正。

“这就像在流沙上盖房子，”老周对着屏幕苦笑，“但算力不等人，矿池的奖励每秒钟都在缩水。”

第二幕：VPN路由的“灵魂三问”——DNS泄漏、分流策略与MTU黑洞

VPN隧道建立后，老周发现算力数据虽然能到达矿池，但延迟极高，而且经常出现“掉线重连”。他用tcpdump抓包，发现了三个致命问题：

第一，DNS泄漏。 鸿蒙的DNS解析默认走netd的resolv.conf，但USB共享时，手机下发的DNS服务器地址（比如192.168.42.129）会被写入全局配置。即使VPN隧道已建立，系统仍会优先使用这个本地DNS去解析矿池域名——这意味着DNS查询明文暴露给运营商，VPN形同虚设。老周必须强制让DNS流量也走tun0，他在鸿蒙的/system/etc/下修改resolv.conf，把DNS服务器改为10.111.222.333（VPN内部的DNS），并用iptables加一条规则：

iptables -t nat -A OUTPUT -p udp --dport 53 -j DNAT --to-destination 10.111.222.333:53

第二，分流失效。 老周希望只有挖矿流量走VPN，而系统更新、日志上报等“杂讯”走本地网络。但鸿蒙的VPN接口默认是“全局模式”，所有流量都封装进隧道。他尝试用鸿蒙的“应用VPN”功能（基于VpnService），但USB共享场景下，VpnService只能拦截应用层流量，而内核态的数据包（比如ping、traceroute）仍走原路。最终，他只能写一个ebpf程序，挂载在cgroup上，用cgroupv2的net_cls标记挖矿进程的流量，然后通过ip rule的fwmark引导到独立路由表。

第三，MTU黑洞。 USB共享的默认MTU是1500，但VPN隧道（尤其是WireGuard协议）需要至少1420字节的MTU，否则大包会被分片，导致UDP丢包率飙升。老周在tun0接口上设置了MTU 1400，同时修改usb0的MTU为1400，并关闭了TCP的MSS clamping。他写了个小脚本，每次隧道建立后自动执行：

ifconfig tun0 mtu 1400 ip link set dev usb0 mtu 1400 iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

但鸿蒙的“智能网络切换”功能会定期检测接口状态，一旦发现MTU不匹配，就会自动重置。老周只能禁用鸿蒙的“智能选择”功能，在settings里把“网络切换”改为“手动”。

第三幕：矿池的“幽灵连接”——当鸿蒙软总线遇上VPN多播

就在老周以为一切搞定的时候，矿池突然报告他的算力“忽高忽低”，甚至出现“无效提交”。他检查日志，发现鸿蒙的分布式软总线（SoftBus）在后台不断广播发现报文，这些多播包（目的地址224.0.0.251）被VPN隧道封装后，发到了矿池的服务器——矿池的防火墙以为这是恶意扫描，果断封禁了老周的IP。

老周这才意识到，鸿蒙OS的“分布式能力”是一把双刃剑。软总线默认在usb0和wlan0上发送mDNS和BLE广播，而VPN隧道会将这些广播“泄露”到远端网络。他必须在VPN建立时，关闭软总线的网络发现功能。他在/system/etc/softbus.conf中设置了：

enable_discovery = false enable_net_broadcast = false

同时，他用iptables过滤掉所有目的地址为224.0.0.0/4的组播包，防止它们进入tun0：

iptables -A OUTPUT -d 224.0.0.0/4 -o tun0 -j DROP

但这样又导致鸿蒙的“多设备协同”功能失效——老周原本计划用手机和开发板组成“算力矩阵”，现在只能各自为战。

第四幕：崩溃后的“涅槃”——路由策略的最终形态

经过七十二小时的折腾，老周终于总结出一套可行的配置方案。他在鸿蒙的/data/local/tmp/下写了一个vpn_routing.sh，每次启动时依次执行：

1. 禁用软总线广播（防止VPN泄漏）
2. 删除USB默认路由（防止流量绕行）
3. 建立VPN隧道并设置MTU（确保大包不丢）
4. 添加ip rule高优先级规则（强制业务流量走tun0）
5. 设置DNS重定向（防止DNS泄漏）
6. 用tc（流量控制）给挖矿流量打上高优先级队列（确保延迟稳定）

他还写了一个监控脚本，每10秒检测一次tun0的状态，如果发现VPN断开，立即回滚路由表，并重启挖矿进程。这套脚本让他挺过了矿池的“难度炸弹”——在比特币算力暴跌的那天晚上，他的五块开发板依然稳定运行，算力曲线呈一条直线。

尾声：USB线缆上的“数字游牧”

第二天清晨，老周把仓库的窗户推开一条缝，晨光刺进他布满血丝的眼睛。手机屏幕上，矿池的收益已经到账，折合成USDT，够他付三个月的电费。他低头看着那条USB线——它像一根脐带，连接着鸿蒙开发板和手机，也连接着这个南方小城与全球算力市场。

“鸿蒙的VPN路由，本质上是一场与系统默认行为的博弈。”老周在技术论坛上写下最后的笔记，“USB共享是入口，VPN是通道，路由表是地图。但鸿蒙的软总线总想当‘调度员’，你必须用ip rule和iptables把它按在椅子上。”

他关掉终端，拔掉USB线。开发板上的指示灯熄灭，但那份“路由配置要点”已经刻进他的肌肉记忆。在虚拟货币的世界里，算力就是权力，而权力，永远属于那些能驯服网络栈的人。