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

核心提示： 假设一端采用iptables，另一端采用Socks5，iptables下udp穿越结尾篇－－－－iptables与socks5(2)，现在Socks5后面的QQ要向iptables后面的在线（不隐身）QQ发送消息，当QQ通过Socks5代理登陆QQ服务器时，因此，即使当QQ向其他离线或隐身

假设一端采用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发送消息时，也不能成功。