iptables与stun

　2007-03-12 12:41:51　来源：WEB开发网　　　

核心提示： 在本例中，从同一个内部地址和端口（192.168.0.4:5000）出来，iptables与stun(4)，到另一个目标地址和端口，则NAT使用了不同的映射，检测结果必然是Port restricted NAT，为什么Win2000下的ics或nat和iptables的分类是如此一致呢？因

在本例中，从同一个内部地址和端口（192.168.0.4:5000）出来，到另一个目标地址和端口，则NAT使用了不同的映射，转换成不同的端口。显然，该现象又满足了Symmetric NAT的要求，同时不能够满足Cone NAT的要求。

我们再来回顾一下Stun协议对Cone NAT的要求：所有（或只要是）从同一个内部地址和端口出来的包，NAT都将它转换成同一个外部地址和端口。虽然iptables在大部分情况下满足“从同一个内部地址和端口出来的包，都将把他转换成同一个外部地址和端口”这一要求，但它不能在所有情况侣阏庖灰蟆Ｋ岳砺凵希颐蔷椭荒馨裪ptables归为Symmetric NAT了。（但在事实上，按照前面例子或者Stun协议里给出的Discovery Process，大部分情况下对iptables的检测结果必然是Port restricted NAT）

为什么会出现上述矛盾的情况呢，关键在于Stun协议和iptables对映射的理解不同。Stun协议认为，一个映射的要素是：内部地址端口和NAT转换后地址端口的组合。而在iptables看来，一个映射的要素是：NAT转换后地址端口和外部目标地址端口的组合。

下面，我们再来分析一下iptables的端口受限的属性，我们举一个反例证明之，仍以前例说明如下：

A机器连接过B机器，假使是 A（192.168.0.4:5000）-> NAT（转换后210.21.12.140:5000）-> B（210.15.27.166:2000）

D机器连接过C机器，假使是 D（192.168.0.5:5000）-> NAT（转换后210.21.12.140:5000）-> C（210.15.27.140:2000）

现假设iptables不具有端口受限的属性，则另一E机器在公网（210.15.27.153:2000）或C（210.15.27.140:2001）向210.21.12.140:5000发包的话，应该能够发到内部机器上。但事实是，当这个包到达NAT（210.21.12.140:5000）时，NAT将不知道把这个包发给A（192.168.0.4:5000）还是D（192.168.0.5:5000）。显然，该包只能丢弃，至此，足以证明iptables具有端口受限的属性。

所以，iptables是货真价实的Symmetric NAT。

附：

1、Stun全称Simple Traversal of UDP Through NATs，所以本文所涉及的包，皆为UDP包。

2、本文虽然是针对linux下iptables的分析，但倘若把本文中关键词“iptables”换成“Win2000下的ics或nat”，则本文的分析过程完全适用于Win2000下的ics或nat。即理论上Win2000下的ics或nat也是货真价实的Symmetric NAT，但实际上，大部分情况下，检测结果必然是Port restricted NAT。为什么Win2000下的ics或nat和iptables的分类是如此一致呢？因为Win2000下的ics或nat在进行NAT转换时，遵循和iptables完全一样的两个原则。

上一页 1 2 3 4