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

核心提示： A机器连接过C机器后，A向C报告了自己的内部地址（192.168.0.4:5000），iptables下udp穿越实用篇－－－－iptables与natcheck(2)，此时C不仅知道了A的外部地址（C通过自己看到的210.21.12.140:8000）、也知道了A的内部地址，同理C也知道

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的包，也能顺利到达。