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

在对natcheck提供的思路进行详细分析后，开始探讨本文主题：iptables与natcheck。

Natcheck脱胎于Stun协议，由拙作“iptables与stun”一文可知，其对iptables进行的穿越NAT兼容性测试结果必然是GOOD。此外，我在该文中还提到一句，如果在每个NAT后面仅有一个客户端这种特殊情况下，iptables就是一个标准的Port restricted Cone。根据前面natcheck的结论，这样两个iptables后面的客户端应该可以互相穿越对方的NAT。让我们来看一下实际情况（例2）呢？

仍然参考前例，只是两侧都使用iptables来进行地址转换。（因为采用了iptables，故此处和前例稍有点区别，即转换后源端口不变）

A与B通过C交换对方地址的初始化环节此处略去，我们从A（192.168.0.4:5000）向B（210.15.27.140:5000）（注意因使用iptables而导致端口和前例不一样）发包开始分析，因为在本例中，两侧均只有一个客户端，我们姑且把iptables简化成Port restricted Cone看待。

如前例一样，从A（192.168.0.4:5000）到B（210.15.27.140: 5000）的第一个包必不能到达B，但其会在A侧iptables上留下记录，在这条记录没有超时之前（iptables下默认30秒），如果B也向A（210.21.12.140:5000）发包，如前所述，按理该包应该能够到达A，但事实上却是永远到不了。

难道是natcheck的结论错了，或者是特殊情况下iptables并不是Port restricted Cone（即仍然是Symmetric NAT），我们还是别忙着再下结论，先来看看来两侧iptables上留下的记录吧：

A侧：cat /proc/net/ip_conntrack | grep 192.168.0.4 | grep udp

udp 17 18 src=192.168.0.4 dst=210.15.27.140 sport=5000 dport=5000 [UNREPLIED] src=210.15.27.140 dst=210.21.12.140 sport=5000 dport=5000 use=1