用scapy构建假的TCP隧道提高传输性能

TCP一定要是TCP吗&＃xff1f; 它可能是个trick&＃xff01;

豪雨滂沱&＃xff0c;作文一篇&＃xff0c;当笑话看看就好。

前几天写了两篇与本文相关的随笔&＃xff1a;
https://blog.csdn.net/dog250/article/details/106881244
https://blog.csdn.net/dog250/article/details/106955747

想让数据包按照TCP的样子被传输和被处理&＃xff0c;非常复杂。

然而&＃xff0c;TCP是一个端到端有状态协议&＃xff0c;这意味着中间转发设备没有能力处理TCP的细节&＃xff0c;如果在端系统也不需要处理TCP细节的时候&＃xff0c; 一个流只需要让中间转发设备看起来像TCP就行了&＃xff01;

什么时候端系统不需要处理TCP细节&＃xff0c;以及为什么要让一个本不是TCP的流看起来像TCP呢&＃xff1f;

我们要明白中间转发设备的一些行为。中间转发设备会针对TCP做出一些动作&＃xff0c;比如&＃xff1a;

• 流量高峰期对除TCP之外的其它协议进行丢包限速(过度对TCP丢包会引发端系统盲CC算法的过激反应&＃xff0c;加剧网络拥塞)。
• 按照TCP四元组对单流进行限速。
• 按照TCP四元组对单流进行整形。
• …

这些动作基于以下的事实&＃xff1a;

• 行为最终会作用于端到端系统&＃xff0c;端到端系统会正确处理TCP细节&＃xff0c;使网络收敛。

而我们可以通过忽略端到端处理&＃xff0c;从这些动作中得到收益&＃xff0c;而不是限制&＃xff1a;

• 给UDP封装一个TCP头使其在高峰期免于被限速。
• 为同一个流封装不同四元组的TCP头而免于被限速。
• 为同一个流封装不同四元组的TCP头而免于被整形。

本文给出一个 将任意流量伪装成TCP流量 的POC。我称为 dummy TCP隧道。

本来我是想用Netfilter做的&＃xff0c;但是我厌倦了写内核模块&＃xff0c;本来我是想用eBPF做的&＃xff0c;但是我觉得有点哗众取宠&＃xff0c;于是&＃xff0c;我用scapy&＃43;tun来做&＃xff0c;因为简单&＃xff01;

下面是dummy TCP隧道python代码(仅侧重于数据面)&＃xff1a;

#!/usr/bin/python
# dtun.py
from scapy.all import *
import socket
import fcntlIFF_TUN &＃61; 0x0001
IFF_NO_PI &＃61; 0x1000
TUNSETIFF &＃61; 0x400454casrc &＃61; &＃39;0.0.0.0&＃39;
peer &＃61; &＃39;0.0.0.0&＃39;
sport &＃61; 0
dport &＃61; 0
seq &＃61; 12345 # 本应random&＃xff0c;但为了简单&＃xff0c;算了
ack_seq &＃61; 12345 # 本应random&＃xff0c;但为了简单&＃xff0c;算了# 从网络接收dummy TCP隧道封装好的报文&＃xff0c;直接解除TCP头&＃xff0c;送到tun网卡
def net2tun(packet):global ack_seq, src, peer, sport, dportflags &＃61; packet[TCP].flags# 处理模拟SYNACK的if分支if flags & 0x02 !&＃61; 0 and flags & 0x10 &＃61;&＃61; 0:ip &＃61; IP(src &＃61; src, dst &＃61; peer)# 收到SYN包&＃xff0c;获取ack&＃xff0c;直接回复SYNACKtcp &＃61; ip/TCP(sport &＃61; sport, dport &＃61; dport, flags &＃61; "SA", seq &＃61; seq, ack &＃61; ack_seq)ack_seq &＃61; packet[TCP].seqsend(tcp)# 处理正常通信的if分支elif flags & 0x02 &＃61;&＃61; 0:os.write(tun.fileno(), str(packet[TCP].payload))ack_seq &＃61; packet[TCP].seq &＃43; len(packet[TCP].payload)def recv():filter &＃61; "src " &＃43; peer &＃43; " and tcp and tcp port 12345"sniff(filter &＃61; filter,iface&＃61;"enp0s8", prn &＃61; net2tun)# 模拟TCP握手&＃xff0c;其作用主要是协商序列号以及让中间状态设备初始化流表。
def handshake(src, dst):global seq, ack_seq, sport, dportip &＃61; IP(src &＃61; src, dst &＃61; dst)tcp &＃61; ip/TCP(sport &＃61; sport, dport &＃61; dport, flags &＃61; "S", seq &＃61; seq)pkt &＃61; sr1(tcp, iface &＃61; "enp0s8")ack_seq &＃61; pkt[TCP].ackprint pkt[TCP].seqprint pkt[TCP].ack# 直接封装TCP头后&＃xff0c;发到网络
def tun2net(src, dst, payload):global seq, ack_seqip &＃61; IP(src &＃61; src, dst &＃61; dst)tcp &＃61; ip/TCP(sport &＃61; sport, dport &＃61; dport, flags &＃61; "A", seq &＃61; seq, ack &＃61; ack_seq)/payloadseq &＃43;&＃61; len(payload)send(tcp)if __name__ &＃61;&＃61; "__main__":global peertunip &＃61; sys.argv[1]peer &＃61; sys.argv[2]src &＃61; sys.argv[3]syn &＃61; sys.argv[4]dport &＃61; int("12345")sport &＃61; int("12345")tun &＃61; open(&＃39;/dev/net/tun&＃39;, &＃39;r&＃43;w&＃39;)iface &＃61; "tun0"# 打开并设置tun设备ifr &＃61; struct.pack(&＃39;16sH&＃39;, iface, IFF_TUN|IFF_NO_PI)fcntl.ioctl(tun, TUNSETIFF, ifr)ip &＃61; socket.inet_aton(tunip)sockfd &＃61; socket.socket(socket.AF_INET, socket.SOCK_STREAM, 0);ifr &＃61; struct.pack(&＃39;16sH2s4s8s&＃39;, iface, socket.AF_INET, &＃39;\x00&＃39;*2, ip, &＃39;\x00&＃39;*8)fcntl.ioctl(sockfd, 0x8916, ifr)ifr &＃61; struct.pack(&＃39;16sH2s4s8s&＃39;, iface, socket.AF_INET, &＃39;\x00&＃39;*2, socket.inet_aton("255.255.255.0"), &＃39;\x00&＃39; * 8)fcntl.ioctl(sockfd, 0x891C, ifr)ifr &＃61; struct.pack(&＃39;16sH&＃39;, iface, IFF_UP)fcntl.ioctl(sockfd, SIOCSIFFLAGS, ifr)try:threading.Thread(target &＃61; recv).start()if syn &＃61;&＃61; "1":handshake(src, peer)# 从tun设备接收裸数据包&＃xff0c;封装TCP头&＃xff0c;直接发到dummy TCP隧道while True:packet &＃61; os.read(tun.fileno(), 2048)tun2net(src, peer, packet)except KeyboardInterrupt:os._exit(0)


来看下效果。

准备两台虚拟机hostA和hostB&＃xff0c;直连&＃xff0c;配置如下&＃xff1a;

# hostA
enp0s8:192.168.56.110/24
# hostB
enp0s8:192.168.56.101/24


下面在hostA和hostB上分别启动上述脚本&＃xff1a;

# hostB (先启动B&＃xff0c;因为它等待接收SYN)
root&＃64;zhaoya-VirtualBox:/home/zhaoya/tun# ./dtun.py 1.1.1.2 192.168.56.110 192.168.56.101 0
# hostA
[root&＃64;localhost tun]# ./dtun.py 1.1.1.1 192.168.56.101 192.168.56.110 1


此时两台机器的隧道就已经建立好了&＃xff0c;由于并没有真正的TCP连接&＃xff0c;为了避免端到端的RST&＃xff0c;需要在hostA和hostB上额外添加两条过滤规则&＃xff1a;

iptables -t mangle -A POSTROUTING -p tcp -m tcp --tcp-flags RST RST -j DROP


OK&＃xff0c;现在可以实验了。

在hostA上ping hostB的tun网卡的地址&＃xff1a;

[root&＃64;localhost ~]# ping 1.1.1.2 -c 2
PING 1.1.1.2 (1.1.1.2) 56(84) bytes of data.
64 bytes from 1.1.1.2: icmp_seq&＃61;1 ttl&＃61;64 time&＃61;42.1 ms
64 bytes from 1.1.1.2: icmp_seq&＃61;2 ttl&＃61;64 time&＃61;50.2 ms--- 1.1.1.2 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 999ms
rtt min/avg/max/mdev &＃61; 42.196/46.243/50.290/4.047 ms


tcpdump抓包如下&＃xff1a;

[root&＃64;localhost tun]# tcpdump -i enp0s8 tcp port 12345 -n
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on enp0s8, link-type EN10MB (Ethernet), capture size 262144 bytes
# 看起来像是TCP的握手包
06:24:40.483759 IP 192.168.56.110.12345 > 192.168.56.101.12345: Flags [S], seq 12345, win 8192, length 0
06:24:40.522107 IP 192.168.56.101.12345 > 192.168.56.110.12345: Flags [S.], seq 12889, ack 12345, win 8192, length 0
# 哦&＃xff0c;缺失了3rd ACK&＃xff0c;嗯&＃xff0c;有待改进...
06:24:46.525279 IP 192.168.56.101.12345 > 192.168.56.110.12345: Flags [.], seq 0:48, ack 1, win 8192, length 48
06:24:46.989491 IP 192.168.56.110.12345 > 192.168.56.101.12345: Flags [.], seq 1:85, ack 48, win 8192, length 84
06:24:47.027375 IP 192.168.56.101.12345 > 192.168.56.110.12345: Flags [.], seq 48:132, ack 85, win 8192, length 84
06:24:47.989780 IP 192.168.56.110.12345 > 192.168.56.101.12345: Flags [.], seq 85:169, ack 132, win 8192, length 84
06:24:48.034897 IP 192.168.56.101.12345 > 192.168.56.110.12345: Flags [.], seq 132:216, ack 169, win 8192, length 84


TCP流&＃xff0c;搞得跟真事儿一样…

其实我们没有建立任何TCP连接&＃xff0c;都是假的。

中间设备看到这种包之后&＃xff0c;会认为这来自于一个真实的TCP连接&＃xff0c;当它想对这个流进行限制的时候&＃xff0c;它会实施排队&＃xff0c;丢包等动作&＃xff0c; 以期待端到端的TCP cc算法可以通过测量RTT&＃xff0c;探测丢包等感知到这种抑制动作&＃xff0c;从而作出绅士般的避让行为。 然而&＃xff0c;根本就没有端到端的TCP处理&＃xff0c;都是装出来的。

现在看看可以进一步做点什么。

如果我用10个不同的源地址建立10条这样的dummy TCP隧道&＃xff0c;那么隧道的过境包每次只需要从这10条隧道里随便挑选一条就可以了。理论上&＃xff0c;如果中间设备对TCP单流进行限速的话&＃xff0c;这种方案可以将吞吐提高10倍&＃xff01;

好吧&＃xff0c;你可能会说中间设备可以对一个IP段进行限速&＃xff0c;那也不是没办法&＃xff0c;只要隧道两端有一端是喇叭大张口&＃xff0c;就可以用那一端来模拟SYN来构建多条隧道&＃xff1a;

多年以前&＃xff0c;我那个时候玩OpenU&＃43;&＃43;Q–N&＃xff0c;我一直嚷嚷着TCP隧道会造成连接崩溃&＃xff0c;我一直嚷嚷着一定要用UDP隧道&＃xff0c;嗯&＃xff0c;那时其实就应该像本文这么玩&＃xff0c;之所以没有想到这等技巧&＃xff0c;或许是因为金融网是一个准内网&＃xff0c;QoS各方面都有所保证&＃xff0c;而且又不会过多对UDP有所限制&＃xff0c;如果当时的生产环境换到公共Internet上&＃xff0c;此等trick估计早就被我偷偷摸摸上线了。

左右手互搏&＃xff0c;道高一尺&＃xff0c;魔高一丈&＃xff0c;自己打脸&＃xff0c;然后抓着经理的领带把经理推进沟渠。

浙江温州皮鞋湿&＃xff0c;下雨进水不会胖。