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

iptables与socks5

从“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合作时，还是有一些不愉快的。下文试举两例说明之。