NAT 穿透

winston

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）     
  A机器连接过C机器后，A向C报告了自己的内部地址（192.168.0.4:5000），此时C不仅知道了A的外部地址   
  （C通过自己看到的210.21.12.140:8000）、也知道了A的内部地址。同理C也知道了B的外部地址（210.15.27.140:8000）和   
  内部地址（192.168.0.5:5000）。之后，C作为中介，把A的两个地址告诉了B，同时也把B的两个地址告诉了A。     
  假设A先知道了B的两个地址，则A从192.168.0.4:5000处同时向B的两个地址192.168.0.5:5000和210.15.27.140:8000发包   
  ，由于A和B在两个不同的NAT后面，故从A（192.168.0.4:5000）到B（192.168.0.5:5000）的包肯定不通，现在看   
  A（192.168.0.4:5000）到B（210.15.27.140:8000）的包，分如下两种情况：     
  1、B侧NAT属于Full   Cone   NAT     
  则无论A侧NAT属于Cone   NAT还是Symmetric   NAT，包都能顺利到达B。如果P2P程序设计得好，使得B主动到A的包也能借用   
  A主动发起建立的通道的话，则即使A侧NAT属于Symmetric   NAT，B发出的包也能顺利到达A。     
  结论1：只要单侧NAT属于Full   Cone   NAT，即可实现双向通信。     
   
  2、B侧NAT属于Restricted   Cone或Port   Restricted   Cone     
  则包不能到达B。再细分两种情况     
  （1）、A侧NAT属于Restricted   Cone或Port   Restricted   Cone     
  虽然先前那个初始包不曾到达B，但该发包过程已经在A侧NAT上留下了足够的记录：   
  A（192.168.0.4:5000）->（210.21.12.140:8000）->B（210.15.27.140:8000）。如果在这个记录没有超时之前，   
  B也重复和A一样的动作，即向A（210.21.12.140:8000）发包，虽然A侧NAT属于Restricted   Cone或Port   Restricted   Cone，   
  但先前A侧NAT已经认为A已经向B（210.15.27.140:8000）发过包，故B向A（210.21.12.140:8000）发包能够顺利到达A。   
  同理，此后A到B的包，也能顺利到达。     
  结论2：只要两侧NAT都不属于Symmetric   NAT，也可双向通信。换种说法，只要两侧NAT都属于Cone   NAT，即可双向通信。     
   
  （2）、A侧NAT属于Symmetric   NAT     
  因为A侧NAT属于Symmetric   NAT，且最初A到C发包的过程在A侧NAT留下了如下记录：   
  A（192.168.0.4:5000）->（210.21.12.140:8000）->   C（210.15.27.166:2000），故A到B发包过程在A侧NAT上留下的记录为：   
  A（192.168.0.4:5000）->（210.21.12.140:8001）->B（210.15.27.140:8000）（注意，转换后端口产生了变化）。   
  而B向A的发包，只能根据C给他的关于A的信息，发往A（210.21.12.140:8000），因为A端口受限，故此路不通。   
  再来看B侧NAT，由于B也向A发过了包，且B侧NAT属于Restricted   Cone或Port   Restricted   Cone，故在B侧NAT上留下的记录为：   
  B（192.168.0.5:5000）->（210.15.27.140:8000）->A（210.21.12.140:8000），此后，如果A还继续向B发包的话   
  （因为同一目标，故仍然使用前面的映射），如果B侧NAT属于Restricted   Cone，则从A（210.21.12.140:8001）来的包能够顺利到达B；   
  如果B侧NAT属于Port   Restricted   Cone，则包永远无法到达B。     
  结论3：一侧NAT属于Symmetric   NAT，另一侧NAT属于Restricted   Cone，也可双向通信。     
   
  显然，还可得出另一个不幸的结论4，两个都是Symmetric   NAT或者一个是Symmetric   NAT、另一个是Port   Restricted   Cone，   
  则不能双向通信。     
  上面的例子虽然只是分析了最初发包是从A到B的情况，但是，鉴于两者的对称性，并且如果P2P程序设计得足够科学，   
  则前面得出的几条结论都是没有方向性，双向都适用的。     
  通过上述分析，我们得知，在穿越NAT方面，Symmetric   NAT和Port   Restricted   Cone是有本质区别的，尽管他们表面上看起来相似。   
  我们上面得出了四条结论，而natcheck网站则把他归结为一条：只要两侧NAT都属于Cone   NAT   
  （含Full   Cone、Restricted   Cone和Port   Restricted   Cone三者），即可双向通信。   
  而且natcheck网站还建议尽量使用Port   Restricted   Cone，以充分利用其端口受限的属性确保安全性。

jinghao666

一直想写个P2P的东西，哪怕是最简单的。网上下过一个，不过看的有点晕。好像代码里没发现打洞的痕迹。版主有这方面的没有？能体现原理的就行。