-
Notifications
You must be signed in to change notification settings - Fork 134
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
试验:利用 dummy socket去掉 iptables依赖 #11
Comments
支持大佬,期待好消息(//∇//)\ |
膜拜大佬 |
我在udp2raw中尝试了简单的dummy socket。没有实现你的 我只是开了一个dummy socket,bind,listen,然后放在那里不管了。 添加dummy socket以后:在server端,不添加iptables也不会产生rst,在docker中可以运行;稳定性有待考证。在client端不行,可能得实现你说的
也就是:开一个dummy socket,放在那里不管。 至于为什么只有server端好使,client端不好使,我猜是这个原因:client是主动连接对方的(发送syn 等待syn ack),而bind listen产生的socket是被动的等待连接的(等待syn)。 |
这个是内核实现的,不需要在用户态手动实现,只要在用户态设置好socket就行了, 但既然dummy socket进行握手了,那么你就不能在代码里手动实现握手。 这两个会冲突,导致client端发送RST。 这时 自己的程序 相当于 一个旁路窃听器, 窃听dummy socket和client端的通信。 只是dummy socket除了握手等协商阶段发送数据,其余时间不发送数据,而是由自己的程序 发送(注入)数据。不过不知道对注入的数据(主要是IP头部数据) 有没有要求(如序号的连续性,不然会导致client端发送RST?),还有何时开始注入数据(连接建立后?),何时结束(连接关闭?)。 https://zhangbinalan.gitbooks.io/protocol/content/tcpde_rst.html |
是的。但是问题是怎么和这个dummy socket无缝配合,完全实现你说的功能,貌似还是得额外写很多代码得。
从实测看来,在server端,这个没有产生问题。 在client端不行。
有的环境下对序号的连续性有要求,比如网络穿过了Iptables的SNAT和DNAT,这个会跟踪序号,不连续的序号会导致序号跟踪失效(卡在某个序号),还有如果发送的序号超出了对方的receive windows会被丢掉。 如果做的好的话,应该可以克服这个问题,只是要再写一些代码。。。
|
需要 跟踪(connection tracking) 连接(dummy socket和client建立的)的状态,根据状态,决定何时发送、停止发送数据,IP头部怎么写。 不过有时可能需要 主动用dummy socket对client发起连接(?)
对,因为client是先发送的,而且第一次发送的SYN是正常的数据包,server端内核没有产生RST(自己的代码不会产生RST),然后server进行响应发送的数据包不对,所以应该是client先产生RST,既然client产生RST了,server端就不会产生了。 在client端屏蔽掉输入后,server也不会产生RST,这可能是你client端代码写的比较好。 你client是在输入端屏蔽输入,还是输出端屏蔽RST的? 应该是输入吧 |
如果client和server都用dummy socket的话,两边都会产生RST。貌似应该是client先产生RST,然后server那边也产生了。 如果client用iptables,server用dummy socket的话,目前看来没有问题,可以一直用,两边都不会产生RST。 一般来说,client不用运行在docker上,即使运行在docker上了,用户也对docker的宿主机有控制权,iptables可以在宿主机上添加。 |
嗯,这个可以测试一下 |
屏蔽的是输入,用iptables drop掉接受的包。 就像这样,
==update==
只能抓到一个方向的包的话,抓完之后不知道怎么把两边结果按时间同步起来,有了tcpdump结果,也难以知道哪个是先哪个是后。貌似很麻烦,一想到这个,就不想测了。。。 |
貌似没有想象的那么复杂,tcpdump在2层抓包,双向的都能抓到,只要一边就可以了。现在同时贴上两边的结果,以便互相对照: 可以看到client在收到syn ack之后,马上回复了RST。 server那边,收到RST之后没有回RST。但是收到ack以后,马上回复了个RST(因为之前的RST已经把TCP连接重置了,所以这个ACK是非法的)。 client这边的结果:
server这边的结果:
|
另外再附上client用iptables,server端用dummy socket的: client:
server:
根据我的理解, |
在tcpdump关闭了相对序号的功能,看得更清楚些。 依然是 client:
server:
server这边,产生了2个syn ack回复,但是后来就只有faketcp在发数据了,dummy socket不动了。 dummy socket刚开始打了一下酱油,回了一个包(长度是0的那个),但是因为faketcp发送数据而dummy socket不发数据的原因,后续client 发来的ack_seq在dummy socket看来是非法的,所以它就不回复了。 不过序号回绕以后,dummy socket可能会再次打一下酱油,然后继续不动。 另外我下载了近5个G的数据测试了一下回绕,回绕不会产生RST。 |
去掉iptables依赖,可以在 docker(如樱花)中运行
需要修改LKL, lkl不进行三次握手,本地内核进行三次握手。 但是本地内核不处理数据,由LKL处理数据
出自: https://stackoverflow.com/questions/31762305/prevent-kernel-from-processing-tcp-segments-bound-to-a-raw-socket
TODO:
https://groups.google.com/forum/#!topic/bbr-dev/Nb4a1FPLkJo
The text was updated successfully, but these errors were encountered: