在对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

B侧：cat /proc/net/ip_conntrack | grep 192.168.0.5 | grep udp

udp 17 26 src=192.168.0.5 dst=210.21.12.140 sport=5000 dport=5000 [UNREPLIED] src=210.21.12.140 dst=210.15.27.140 sport=5000 dport=1026 use=1

把两条记录翻译如下：(关于ip_conntrack文件的分析，请见http://www.sns.ias.edu/~jns/security/iptables/iptables_conntrack.html)

A(192.168.0.4:5000)-> A侧NAT(转换后210.21.12.140:5000)-> B(210.15.27.140:5000)

B(192.168.0.5:5000)-> B侧NAT(转换后210.15.27.140:1026)-> A(210.21.12.140:5000)

奇怪，B到A的包在映射后源端口号怎么变了呢，按理不应该呀?因为按照iptables转换原则(详见“iptables与stun”)，要求尽量保持源端口号不变，除非socket有重复。难道B侧NAT上还有重复记录，再cat一下呢?

B侧：cat /proc/net/ip_conntrack | grep 210.21.12.140 | grep udp

udp 17 10 src=210.21.12.140 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

udp 17 16 src=192.168.0.5 dst=210.21.12.140 sport=5000 dport=5000 [UNREPLIED] src=210.21.12.140 dst=210.15.27.140 sport=5000 dport=1026 use=1

操!还果真有两条差不多的记录，第一条与NAT无关，是A到B的包在B侧iptables上留下的记录，产生时间上略早于第二条记录，其构成的socket是(210.21.12.140:5000，210.15.27.140:5000)。第二条即B到A的包产生的记录，其构成的socket是(210.15.27.140:1026，210.21.12.140:5000)，如果其源端口不改动，即是(210.15.27.140:5000，210.21.12.140:5000)，还真和第一条记录重复了呢，怪不得转换后需要修改源端口，也怪不得B发包到不了A。

为什么是这样的结果呢?我们知道，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自行分析。

解决办法

原理：一般的NAT设备，对于接收到的UDP数据包，只有当内部已经有发送到这个数据包的源地址和源端口的数据包时，才会转发给内部主机。否则会丢弃。这个原理只适应UDP协议而不适应TCPIP协议。

步骤：

1)A直接向B的NAT设备地址Bnat发送UDP包，该包一般情况下取决于B的NAT设备类型】会被B的NAT抛弃，但是通过发送该包，A的NAT设备打开了一个可以接收来自B的NAT设备的UDP数据包的"通道";

2)A通过server向B的NAT设备地址Bnat转发UDP包，请求B向A的NAT设备地址Anat发送UDP包。因为B已经向server发送过UDP包，B的NAT设备会将该请求包转发给B。

3)此时，B向A的NAT设备地址Anat发送UDP包，因为在第1)步中，A的NAT设备已经打开了通道，该包会由A的NAT设备正确转发给A。同时，B的NAT设备也打开了一个可以接收来自A的NAT设备的UDP包的"通道"。

4)此后，A可以和B直接通过Anat和Bnat进行UDP通讯，不需要通过server了。

5)还有一点值得提到，以后，A或者B中的任何一个，都可以作为另外一个和第3方如C之间建立UDP连接的中转Server(即上文中的Server)

6)另外，对于多级NAT情况，上面提到的UDP端口反弹技术，都可以自动适应。

通过阅读文章，我们不难发现iptables与natcheck都挺好用的，感兴趣的朋友可以和朋友试试！

  • iptables限制访问某个IP地址
  • 用iptables限制黑客破解密码
  • iptables 菜鸟变大虾
  • iptables 端口转发
  • iptables nat 技术笔记
  • iptables+NAT+端口映射
  • 如何查看iptables关于nat的日志


共2页: 上一页12下一页

相关内容