关于 TPROXY 透明代理使 V2Ray 占满 CPU 问题的研究

[ToutyRater]

自从白话文推出 TPROXY 模式的透明代理之后，曾看到多位网友反映 V2Ray 占用了大量 CPU，另有人指出这是 iptables 的 PREROUTING 链缺失 iptables -t mangle -A V2RAY -j RETURN -m mark --mark 0xff 规则。我对此感到很奇怪，因为我使用了一年多的 TPROXY 透明代理，始终没有遇到这个问题，甚至有时在怀疑是不是网友配置跟教程有差异导致出问题。
后来看到有好多人出现几乎一样的问题，越发觉得这不是偶然，应该有特定的因素导致，但是我一直无法复现，也搞不出个结果。然后仔细研究，终于从 v2ray/v2ray-core#2621 , v2ray/v2ray-core#2549 , v2ray/v2ray-core#2461 发现了关键，占用大量 CPU 的问题是由于 DNS 的 PRT 查询导致的。

由于 V2Ray 的 DNS 可以使用 dlc 进行分流，几乎跟 routing 规则进行复用，使用 V2Ray DNS 相比使用第三方 DNS 减少对域名列表的维护。因此教程中直接使用了 V2Ray 作为 DNS 服务器。但是：

1. V2Ray 只能处理 A 和 AAAA 查询，对于其他类型将会转发至 dokodemo 指定的地址进行查询；
2. 由于早期 BUG(见 在透明代理环境中开放 UDP 53 端口作为 DNS 服务器出现问题 v2ray/v2ray-core#1971 ，现已修复)，V2Ray 的 DNS 服务无法监听独立的端口，为了绕过这个问题教程的方案是通过 iptables 劫持目标地址为非私有 IP 的 53 端口的 UDP 包发给 V2Ray；
3. 过了一段时间，为了强化效果，教程加大力度改了 iptables 规则，连私有 IP 的包也给劫持了；
4. 我以为 V2Ray 发出的包都进入 OUTPUT 链，就没想过还会有从 PREROUTING 接收来自于自己的包的情况，所以没有在 PREROUTING 链上对有标记的包做处理；
5. 没有任何设备查询 A 和 AAAA 之外的类型。

以上几点任何一点不满足都不会出现 V2Ray 占用大量 CPU 的问题。

先贴一下当时有问题的 iptables 规则。

iptables -t mangle -N V2RAY
iptables -t mangle -A V2RAY -d 127.0.0.1/32 -j RETURN
iptables -t mangle -A V2RAY -d 224.0.0.0/4 -j RETURN 
iptables -t mangle -A V2RAY -d 255.255.255.255/32 -j RETURN 
iptables -t mangle -A V2RAY -d 192.168.0.0/16 -p tcp -j RETURN
iptables -t mangle -A V2RAY -d 192.168.0.0/16 -p udp ! --dport 53 -j RETURN 
iptables -t mangle -A V2RAY -p udp -j TPROXY --on-ip 127.0.0.1 --on-port 12345 --tproxy-mark 1
iptables -t mangle -A V2RAY -p tcp -j TPROXY --on-ip 127.0.0.1 --on-port 12345 --tproxy-mark 1
iptables -t mangle -A PREROUTING -j V2RAY

iptables -t mangle -N V2RAY_MASK 
iptables -t mangle -A V2RAY_MASK -d 224.0.0.0/4 -j RETURN 
iptables -t mangle -A V2RAY_MASK -d 255.255.255.255/32 -j RETURN 
iptables -t mangle -A V2RAY_MASK -d 192.168.0.0/16 -p tcp -j RETURN 
iptables -t mangle -A V2RAY_MASK -d 192.168.0.0/16 -p udp ! --dport 53 -j RETURN 
iptables -t mangle -A V2RAY_MASK -j RETURN -m mark --mark 0xff 
iptables -t mangle -A V2RAY_MASK -p udp -j MARK --set-mark 1
iptables -t mangle -A V2RAY_MASK -p tcp -j MARK --set-mark 1
iptables -t mangle -A OUTPUT -j V2RAY_MASK

因此，当有设备查询非 A 和 AAAA DNS 时，iptables 劫持发给 V2Ray，V2Ray 无法处理只能转发至 dokodemo 指定的服务器，但是这个 dokodemo 是透明代理用的，没有指定转发的地址，然后 V2Ray 只能识别到是透明网关本机的地址(假设是192.168.1.5)，然后 V2Ray 就把 DNS 查询的包发往 192.168.1.5:53，虽然在 OUTPUT 根据 iptables -t mangle -A V2RAY_MASK -j RETURN -m mark --mark 0xff 直接发出去了，但由于是发给自己，下一时刻就进入到了 自己的 PREROUTING 链，由于 PREROUTING 链没有处理有标记的包，还把 53 端口的 UDP 包劫持给了 V2Ray。就这样进入了死循环，占用了大量 CPU。

虽然说现在教程已加上了 iptables -t mangle -A V2RAY -j RETURN -m mark --mark 0xff，不会有此类问题，后续我还是打算修改教程，把 2、3 点也给规避掉。

[yatsuki]

我也发现了这个问题的一个别的原因，那就是对广播地址没有有效处理，导致CPU、内存、带宽三爆炸。
如下图所示：

一晚上就给我跑了8T上传。
日志中会有一些下面类似的地址出现

2021/01/05 00:49:36 172.17.0.1:43884 accepted udp:172.17.255.255:138 [direct]
2021/01/05 00:49:36 172.17.0.1:55325 accepted udp:172.17.255.255:138 [direct]

之前部署的想法就是内网地址在直接转发中打上mask从V2Ray中过一遍也没关系

{"tag": "direct","protocol": "freedom","settings":{"domainStrategy":"UseIPv4"}, "streamSettings": {"sockopt": {"mark": 255}}}

不过想法很好，现实啪啪打脸。
进程打开文件句柄数在短时间膨胀到一个难以相信的数量这大概是启动程序3min过后的文件句柄数：

root@ubuntu:~# lsof -p 582693 | wc -l
1052

马上继续按Enter文件句柄数量继续爆炸

root@ubuntu:~# lsof -p 582693 | wc -l
1064
root@ubuntu:~# lsof -p 582693 | wc -l
1076

对于广播地址发出的程序，自己通过 lsof定位到了 smbd 和 nmbd。
这是自己开的局域网文件共享。马上停止这两货之后打开句柄爆炸还是不会停。

root@ubuntu:~# lsof -p 582693 | wc -l
1088
root@ubuntu:~# lsof -p 582693 | wc -l
1100
root@ubuntu:~# lsof -p 582693 | wc -l
1136

看来只要广播地址进了V2Ray就会停不下来。

最后在iptables加入这个广播地址172.17.255.255的拦截才算解决

iptables -t mangle -I V2RAY 4 -d 172.17.255.255/32 -j RETURN
iptables -t mangle -I V2RAY_MASK 3 -d 172.17.255.255/32 -j RETURN

对于这个地址自己开始也根本没注意，发起的请求也只有两三个。

2021/01/05 00:49:36 172.17.0.1:43884 accepted udp:172.17.255.255:138 [direct]
2021/01/05 00:49:36 172.17.0.1:55325 accepted udp:172.17.255.255:138 [direct]
2021/01/05 00:51:01 192.168.1.6:59334 accepted udp:61.139.2.69:53 [dns-out]
2021/01/05 00:51:01 192.168.1.6:57958 accepted tcp:192.30.255.117:443 [tokyo-2]
2021/01/05 00:51:21 192.168.1.6:46274 accepted udp:61.139.2.69:53 [dns-out]
2021/01/05 00:51:21 192.168.1.6:58476 accepted udp:61.139.2.69:53 [dns-out]
2021/01/05 00:51:21 192.168.1.6:48839 accepted udp:61.139.2.69:53 [dns-out]
2021/01/05 00:51:21 192.168.1.6:36138 accepted udp:61.139.2.69:53 [dns-out]
2021/01/05 00:51:21 192.168.1.6:39396 accepted udp:61.139.2.69:53 [dns-out]
2021/01/05 00:51:21 192.168.1.6:45633 accepted udp:61.139.2.69:53 [dns-out]
2021/01/05 00:51:23 192.168.1.6:42537 accepted udp:61.139.2.69:53 [dns-out]
2021/01/05 00:56:26 192.168.1.6:51128 accepted udp:61.139.2.69:53 [dns-out]
2021/01/05 00:56:26 192.168.1.6:39482 accepted tcp:157.240.1.33:443 [tokyo-2]

自己一开始也是往DNS解析的方向去找，排除了好久才把目光转向了它。
不知道这算是配置问题还是V2Ray的BUG。不过还是希望加入对广播地址的处理吧，iptables也可以不用配置那么多了。

[linzhanyu]

太帅了!

[1265578519]

emmmm，早年sstap也有这个问题，猜测是你用了路由表的缘故？