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

程序员文章站 2022-05-26 16:33:50

...

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

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

前几天写了两篇与本文相关的随笔：
https://blog.csdn.net/dog250/article/details/106881244
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)
aaa@qq.com:/home/zhaoya/tun# ./dtun.py 1.1.1.2 192.168.56.110 192.168.56.101 0
# hostA
[aaa@qq.com 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网卡的地址：

[aaa@qq.com ~]# 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抓包如下：

[aaa@qq.com 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来构建多条隧道：
用scapy构建假的TCP隧道提高传输性能
多年以前，我那个时候玩OpenU++Q–N，我一直嚷嚷着TCP隧道会造成连接崩溃，我一直嚷嚷着一定要用UDP隧道，嗯，那时其实就应该像本文这么玩，之所以没有想到这等技巧，或许是因为金融网是一个准内网，QoS各方面都有所保证，而且又不会过多对UDP有所限制，如果当时的生产环境换到公共Internet上，此等trick估计早就被我偷偷摸摸上线了。

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

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