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）Proxy 伺服器取代專用的代理服務器，一是因為Socks5能夠很好的支援UDP，二是Socks5Proxy 伺服器的品種以及在公網上部署的數量都比較多，而且最重要的是Socks5是一個已經標準化了的協議。用戶端採用Socks5代理後，其UDP通訊通過Socks5中轉出去，在對方的P2P程式看來，使用Socks5代理後的客戶就像直接連在公網上，也就是說，只要有一方使用Socks5 代理，則另一方不論採用何種NAT，都不會受Stun或natcheck的限制。因此，iptables和Socks5理論上應該合作愉快，但在實現Socks5代理時，如果對Socks5協議理解不夠透徹，在和iptables合作時，還是有一些不愉快的。下文試舉兩例說明之。