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

核心提示： 为什么是这样的结果呢？我们知道，iptables是一个有状态的防火墙，iptables下udp穿越实用篇－－－－iptables与natcheck(6)，他通过连接跟踪模块来实现状态检测的功能，该模块检查所有到来的数据包，则永远无法穿越，具体原理，也就是说，该模块不仅对NAT起作用

为什么是这样的结果呢？我们知道，iptables是一个有状态的防火墙，他通过连接跟踪模块来实现状态检测的功能，该模块检查所有到来的数据包，也就是说，该模块不仅对NAT起作用，而且对普通的包过滤也起作用。显然，在上述例子里，A到B的包就是作为普通的包过滤而被记载在B侧iptables的连接跟踪表里，导致后来B到A的包为避免socket重复而不得不改换端口号，从而导致无法实现双向通信。看来，natcheck的结论并没有错，只是由于iptables具有状态检测的新特性导致即使在特殊情况下iptables又从Port restricted Cone变成了Symmetric NAT而已。

那么，有办法解决这一问题吗？根据连接跟踪的特性，在iptables下，只要启用了NAT，就肯定要启用连接跟踪功能，而只要启用了连接跟踪功能，就必然顺带跟踪普通包过滤（启用连接跟踪后，似乎无法控制不让跟踪普通包过滤），也就是说，只要用NAT，就无法避免上述情况，真残酷！然而，这却是事实，即只要两端都采用了iptables作为NAT，则尽管两侧都通过了natcheck的兼容性测试，但iptables两侧永远也不能互相穿越。

在“iptables与stun”一文中曾经附带提到，Win2000下的ics或nat在Stun协议下的表现和iptables是完全一样的。那么，在natcheck下，表现是否还一致呢？答案是否定的，虽然Win2000下的ics或nat也具有状态检测的功能，但该状态检测，仅对NAT起作用，不对普通包过滤起作用。所以在两侧都是Win2000下的ics或nat可以作为Port restricted Cone的特殊情况下，是允许被穿越的。另外，在一侧使用iptables，另一侧使用Win2000下的ics或nat，但两者都表现为Port restricted Cone的特殊情况下，从某个方向发起，最终是允许互相穿越的，但是这种穿越不具有对称性，即从另一个方向发起，则永远无法穿越，具体原理，读者可以参考例2自行分析。