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

核心提示： 上面这个例子表明，由于某些Socks5服务器和Socks5客户端对Socks5协议理解不够透彻，iptables下udp穿越结尾篇－－－－iptables与socks5(3)，即使采用了Socks5，在和iptables互通时也会导致通讯不畅，利用iptables的保护源端口特性，还能确保

上面这个例子表明，由于某些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代理的开发者有所帮助。