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

叁歲伎倆 2023-02-21 06:57 130阅读 0赞

TCP一定要是TCP吗？ ***它可能是个trick！***

豪雨滂沱，作文一篇，当笑话看看就好。

前几天写了两篇与本文相关的随笔：  
[https://blog.csdn.net/dog250/article/details/106881244][https_blog.csdn.net_dog250_article_details_106881244]  
[https://blog.csdn.net/dog250/article/details/106955747][https_blog.csdn.net_dog250_article_details_106955747]

--------------------

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

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

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

我们要明白中间转发设备的一些行为。中间转发设备会针对TCP做出一些动作，比如：

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

这些动作基于以下的事实：

*  ***行为最终会作用于端到端系统，端到端系统会正确处理TCP细节，使网络收敛。***

而我们可以通过忽略端到端处理，从这些动作中得到收益，而不是限制：

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

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

本来我是想用Netfilter做的，但是我厌倦了写内核模块，本来我是想用eBPF做的，但是我觉得有点哗众取宠，于是，我用scapy+tun来做，因为简单！

下面是dummy TCP隧道python代码(仅侧重于数据面)：

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

来看下效果。

准备两台虚拟机hostA和hostB，直连，配置如下：

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

下面在hostA和hostB上分别启动上述脚本：

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

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

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

OK，现在可以实验了。

在hostA上ping hostB的tun网卡的地址：

[root@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=1 ttl=64 time=42.1 ms
    64 bytes from 1.1.1.2: icmp_seq=2 ttl=64 time=50.2 ms
    
    --- 1.1.1.2 ping statistics ---
    2 packets transmitted, 2 received, 0% packet loss, time 999ms
    rtt min/avg/max/mdev = 42.196/46.243/50.290/4.047 ms

tcpdump抓包如下：

[root@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
    # 哦，缺失了3rd ACK，嗯，有待改进...
    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流，搞得跟真事儿一样…

其实我们没有建立任何TCP连接，都是假的。

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

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

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

好吧，你可能会说中间设备可以对一个IP段进行限速，那也不是没办法，只要隧道两端有一端是喇叭大张口，就可以用那一端来模拟SYN来构建多条隧道：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2RvZzI1MA_size_16_color_FFFFFF_t_70]  
多年以前，我那个时候玩OpenU++Q–N，我一直嚷嚷着TCP隧道会造成连接崩溃，我一直嚷嚷着一定要用UDP隧道，嗯，那时其实就应该像本文这么玩，之所以没有想到这等技巧，或许是因为金融网是一个准内网，QoS各方面都有所保证，而且又不会过多对UDP有所限制，如果当时的生产环境换到公共Internet上，此等trick估计早就被我偷偷摸摸上线了。

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

--------------------

浙江温州皮鞋湿，下雨进水不会胖。

[https_blog.csdn.net_dog250_article_details_106881244]: https://blog.csdn.net/dog250/article/details/106881244
[https_blog.csdn.net_dog250_article_details_106955747]: https://blog.csdn.net/dog250/article/details/106955747
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2RvZzI1MA_size_16_color_FFFFFF_t_70]: https://img-blog.csdnimg.cn/20200629202845417.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2RvZzI1MA==,size_16,color_FFFFFF,t_70