iptables下udp穿越结尾篇----iptables与socks5

2024-03-29 20:21:01

从“iptables和natcheck”一文可知，只要在两端都采用了iptables作NAT后，即使两侧都通过了natcheck的兼容性测试，但iptables两侧永远也不能互相穿越。
怎
么办呢，一种办法是在公网上添加中转服务器，两侧内网机器之间的UDP通讯都由中转服务器来中转（其实只要中转一侧足矣）。这种方法的好处是，因为中转服
务器在公网，任何NAT后面的机器都可以和中转服务器建立连接，也就是说，不同内网之间的机器总是可以通过中转服务器实现双向通信的。然而，该办法的缺点
是，对中转服务器的要求比较高，包括CPU处理能力和网络带宽两方面，而且客户机之间的通讯延迟也是不可避免的（目前网上最为盛行的Skype是个例外，
他采用了分布式中转技术，直接挂在互联网上不在防火墙后面的Skype客户端都可以为他人提供中转服务，因此Skype在提供很高呼叫成功率的同时还能确
保超高质量的语音效果）。还有一个更为重要的因素，即中转服务器的标准不统一，导致每种不同类型的P2P程序都需要一个专用的中转服务器。倘若这些中转服
务器之间不能做到资源共享的话，必然存在资源浪费现象（标准的中转协议好像正在推出，名称为Traversal Using Relay NAT
即TURN）。
另一种比较好的办法就是采用Socks5（Rfc1928）代理服务器取代专用的中转服务器，一是因为Socks5能够很好的
支持UDP，二是Socks5代理服务器的品种以及在公网上部署的数量都比较多，而且最重要的是Socks5是一个已经标准化了的协议。客户端采用
Socks5代理后，其UDP通信通过Socks5中转出去，在对方的P2P程序看来，使用Socks5代理后的客户就像直接连在公网上，也就是说，只要
有一方使用Socks5
代理，则另一方不论采用何种NAT，都不会受Stun或natcheck的限制。因此，iptables和Socks5理论上应该合作愉快，但在实现
Socks5代理时，如果对Socks5协议理解不够透彻，在和iptables合作时，还是有一些不愉快的。下文试举两例说明之。
假设一端
采用iptables，另一端采用Socks5，现在Socks5后面的QQ要向iptables后面的在线（不隐身）QQ发送消息。当QQ通过
Socks5代理登陆QQ服务器时，首先要和Socks5服务器建立一个基于TCP连接的Socks5通道，用于控制QQ和Socks5服务器之间的后续
UDP联结。一旦该通道成功建立，Socks5服务器将动态分配一个UDP端口为该QQ担任UDP中转的任务，当QQ给远端iptables后面在线QQ
发送消息时，先将消息（UDP包）发送到Socks5服务器上先前分配的UDP端口，再由服务器将该UDP包转发到远端QQ。当UDP包到达远端QQ时，
由iptables端口受限的属性可知，除非使用Socks5代理的QQ在线且在不久前（三分钟）曾经收到过iptables后面QQ主动发来的UDP
包，否则这个包无法被转发到iptables后面的QQ上。
那么这个UDP包最终又往哪里去了呢？我们来分析一下，该UDP包到达
iptables所在那台Linux主机后的前进流程。当一个UDP包到达Linux时，先交由iptables处理，iptables则先看该UDP包
在/proc/net/ip_conntrack文件里有无匹配项，如有，则进行匹配处理；如无，再看PREROUTING链里有无匹配规则，如有，则继
续进行匹配处理；如无，由于该包目的地址就是Linux本身，所以iptables将其放入INPUT链。由于INPUT链的默认策略为ACCEPT，则
该UDP包将被转交给Linux的本地进程处理，但事实上由于不存在这样的本地进程，结果是Linux向产生该UDP包的机器发回一个icmp-port
-unreachable包（注意，这个包是Linux系统产生的，不是iptables的REJECT目标产生的）。如果INPUT链的策略为
DROP，则该UDP包就被DROP。
由上分析可知，一般情况下，最终iptables所在机器将向发送QQ方返回一个icmp-port-
unreachable包。当Socks5服务器收到这个icmp-port-unreachable包后，不同的Socks5服务器有不同的处理方式。
一些Socks5服务器（如Ccproxy带的Socks5）简单的忽略这个icmp-port-unreachable包，而QQ则由于没有发送成功
（没有收到应答信息），继续重复上述过程若干次，但都无法发送成功，最后只能通过服务器中转，虽然由于中转造成发送速度很慢，但总是能够成功发送。而另外
一些Socks5服务器（如Wingate带的Socks5）收到远端返回的icmp-port-unreachable包后，认为先前QQ发起的UDP
联结无效，通过先前建立的Socks5通道（TCP）给客户端返回一个general SOCKS server failure（Reply
Code‘01’），随后立即关闭该通道，同时还关闭了Socks5服务器上担任中转任务的UDP端口。然而QQ似乎并不知道它和Socks5服务器之间
的联系已被切断，由于没有发送成功（没有收到应答信息），仍然向Socks5服务器上已关闭的UDP端口发送消息。此时由于Socks5服务器已关闭了相
应的UDP端口，所以也向QQ返回一个icmp-port-unreachable包。QQ收到这个包后，继续重复上述过程若干次，最终因超时而失败，并
且因为同样的原因也不能通过服务器中转。更为严重的是，即便到了此时，QQ仍然不知道它和Socks5服务器之间的联系已被切断，因此，即使当QQ向其他
离线或隐身QQ或不在NAT后面的在线QQ发送消息时，也不能成功。
上面这个例子表明，由于某些Socks5服务器和Socks5客户端对Socks5协议理解不够透彻，即使采用了Socks5，在和iptables互通时也会导致通讯不畅。
另一个例子，考虑这样一种情形，Socks5服务器位于公网，内网客户端先通过iptables进行NAT，然后再去连接Socks5服务器。
先引用Socks5协议（Rfc1928）里如下一段文字：
The
UDP ASSOCIATE request is used to establish an association within the
UDP relay process to handle UDP datagrams. The DST.ADDR and DST.PORT
fields contain the address and port that the client expects to use to
send UDP datagrams on for the association. The server MAY use this
information to limit access to the association. If the client is not in
possesion of the information at the time of the UDP ASSOCIATE, the
client MUST use a port number and address of all zeros.
Socks5客户端在进
行UDP
ASSOCIATE时（通过TCP通道），要求用自己将来发送UDP包的地址和端口填充DST.ADDR和DST.PORT字段，以便Socks5服务器
确保其分配的UDP端口仅为对应的Socks5客户端提供中转服务。然而，当Socks5客户端跨越NAT去连接Socks5服务器时，考虑到要经过
NAT地址转换环节，Socks5客户端无法预知将来Socks5服务器看到的自己用来发送UDP包的地址和端口。针对这种情况，Rfc1928建议
Socks5客户端使用0填充DST.ADDR和DST.PORT字段，这样一来，Socks5服务器就不会限制Socks5客户端对中转端口的使用了。
然而，目前好多Socks5客户端似乎没有意识到这一点，像最通用的NEC公司的e-Border
Driver，便使用了客户端的真实IP地址和端口填充DST.ADDR和DST.PORT字段；而其他一些P2P程序自带的Socks5客户端，仅用0
填充DST.ADDR字段。鉴于跨越NAT后，IP地址必然发生变化，导致e-Border
Driver永远不能用于跨越NAT的场合，而像iptables，由于具有Preserves port
number的属性，所以，那些仅用0填充DST.ADDR字段的Socks5客户端，可以用于跨越iptables的场合。此外，跨越NAT还需要
Socks5服务器的配合，遗憾的是，仍然有些Socks5服务器并没有充分理解Rfc1928的这一建议。在这点上，Wingate带的Socks5做
得比较好，支持客户端用0填充DST.ADDR和DST.PORT字段；而Ccproxy带的Socks5，在客户端进行UDP
ASSOCIATE时，虽然也支持客户端用0填充DST.ADDR和DST.PORT字段，并能在服务器上顺利为客户端分配一个UDP端口，但当后来该
UDP端口和客户端通信时，不是发往客户端对应的UDP端口，而是发往客户端前述用0填充的DST.PORT，导致无法实现中转任务。至于NEC公司提供
的广为流传的免费Socks5服务器，则干脆申明“if the destination port is 0, we will assume
the same port as tcp's”，也将导致Socks5客户端无法跨越NAT。
在这个例子里，iptables对
Socks5代理没有任何影响，纯粹是因为Socks5本身的原因导致通讯不畅。相反，利用iptables的保护源端口特性，还能确保部分Socks5
客户端能够顺利跨越用iptables实现的NAT去连接公网上的Socks5服务器。
希望本文两个例子能对即将或已经实现Socks5代理的开发者有所帮助。

iptables下udp穿越结尾篇----iptables与socks5相关推荐

iptables(下)规则
iptables安装停止并禁止开机自启firewalld服务 systemctl stop firewalld && systemctl disable firewalld 检查是否 ...
iptables深入解析：mangle篇
讲了filter.ct.nat 现在剩下最后一个知名模块mangle,但是自身虽然知道内核支持修改数据包的信息,它主要用在策略路由和qos上.我们就具体分析一下. mangle表主要用于修改数据包的T ...
iptables下开放ftp连接端口
iptables下开放ftp连接端口转载 2014年04月19日 10:04:27 2275 iptables 就是linux系统的防火墙,很多人安装iptables之后重启服务器发现网站无法访问, ...
Linux对称NAT的UDP穿越
和同事讨论UDP打洞技术,后做了一个简单的实验,由于Windows上设置NAT以及察看其原理太麻烦或者根本就不可能,于是还是使用Linux做了实验,发现基于Linux ip_conntrack这种对称 ...
iptables nat表含义_十（4）iptables语法、iptables filter表小案例、iptables nat表应用
iptables语法 filter表: INPUT链:作用于进入本机的包 OUTPUT链:作用于送出本机的包 FORWARD链:作用于和本机无关的包 nat表: PREROUTING链:作用是包在刚刚 ...
UDP穿越NAT原理
http://blog.csdn.net/ldd909/article/details/5979967 论坛上经常有对P2P原理的讨论,但是讨论归讨论,很少有实质的东西产生(源代码).在这里我就用自己 ...
Python中的TCP的客户端UDP学习----第一篇博客
Python中的TCP的客户端&UDP学习--第一篇博客 PS: 每日的怼人句子"我真想把我的脑子放到你的身体里,让你感受一下智慧的光芒" 先说UDP流程发送: 创建套接 ...
mysql主从复制中间件_linux下mysql主从复制(第二篇读写分离) mycat 中间件
linux下mysql主从复制(第二篇读写分离) mycat 中间件接着上篇文档补全,mysql 读写分离,在上篇文章案例下准备好Mycat-server-1.4-release-201510192 ...
nat服务器性能,iptables的性能问题：用iptables做了web服务器的NAT，速度很慢是何解？？...
iptables的性能问题:用iptables做了web服务器的NAT,速度很慢是何解?? (2012-06-06 23:44:08) 标签: 的 web服务器杂谈 iptables的性能问题:用i ...

最新文章

热门文章