iptables下udp穿越实用篇－－－－iptables与natcheck

核心提示：Stun协议（Rfc3489、详见http://www.ietf.org/rfc/rfc3489.txt） 提出了4种NAT类型的定义及其分类，并给出了如何检测在用的NAT究竟属于哪种分类的标准，iptables下udp穿越实用篇－－－－iptables与natcheck，但是，具体到P2P程序如何应用Stun协议及其

Stun协议（Rfc3489、详见http://www.ietf.org/rfc/rfc3489.txt） 提出了4种NAT类型的定义及其分类，并给出了如何检测在用的NAT究竟属于哪种分类的标准。但是，具体到P2P程序如何应用Stun协议及其分类法穿越NAT，则是仁者见仁、智者见智。（因为Stun协议并没有给出也没有必要给出如何穿越NAT的标准）

在拙作“iptables与stun”一文中，笔者花大幅精力阐述了iptables理论上属于Symmetric NAT而非Port Restricted Cone。对此，很多人（包括笔者最初学习Stun协议时）心中都有一个疑惑，即仅就Stun协议本身来说，Port Restricted Cone和Symmetric NAT的区别似乎不大，虽然两者的映射机制是有点不同，但他们都具有端口受限的属性。初看起来，这两者在穿越NAT方面的特性也差不多，尤其是对于外部地址欲往NAT内部地址发包的情况。既然如此，又为何有必要把iptables分得这么清呢，本文顺带解决了读者在这一方面的疑惑。

网站http://midcom-p2p.sourceforge.net/给出了P2P程序具体如何穿越NAT的一个思路，并提供了一个P2P协议穿越NAT兼容性的测试工具natcheck。让我们仍旧用实例（例1）来说明这一思路吧！

A机器在私网（192.168.0.4）

A侧NAT服务器（210.21.12.140）

B机器在另一个私网（192.168.0.5）

B侧NAT服务器（210.15.27.140）

C机器在公网（210.15.27.166）作为A和B之间的中介

A机器连接过C机器，假使是 A（192.168.0.4:5000）-> A侧NAT（转换后210.21.12.140:8000）-> C（210.15.27.166:2000）

B机器也连接过C机器，假使是 B（192.168.0.5:5000）-> B侧NAT（转换后210.15.27.140:8000）-> C（210.15.27.166:2000）