iptables下udp穿越基础篇—-iptables与stun

摘自:http://www.360doc.com/content/070205/13/17255_356485.html

iptables与stun

Stun协议(Rfc3489、详见http://www.ietf.org/rfc/rfc3489.txt)将NAT粗略分为4种类型,即Full Cone、Restricted Cone、Port Restricted Cone和Symmetric。举个实际例子(例1)来说明这四种NAT的区别:
A机器在私网(192.168.0.4)
NAT服务器(210.21.12.140)
B机器在公网(210.15.27.166)
C机器在公网(210.15.27.140)
现在,A机器连接过B机器,假设是 A(192.168.0.4:5000)-> NAT(转换后210.21.12.140:8000)-> B(210.15.27.166:2000)。
同时A从来没有和C通信过。
则对于不同类型的NAT,有下列不同的结果:
Full Cone NAT:C发数据到210.21.12.140:8000,NAT会将数据包送到A(192.168.0.4:5000)。因为NAT上已经有了192.168.0.4:5000到210.21.12.140:8000的映射。
Restricted Cone:C无法和A通信,因为A从来没有和C通信过,NAT将拒绝C试图与A连接的动作。但B可以通过210.21.12.140:8000与A的192.168.0.4:5000通信,且这里B可以使用任何端口与A通信。如:210.15.27.166:2001 -> 210.21.12.140:8000,NAT会送到A的5000端口上。
Port Restricted Cone:C无法与A通信,因为A从来没有和C通信过。而B也只能用它的210.15.27.166:2000与A的192.168.0.4:5000通信,因为A也从来没有和B的其他端口通信过。该类型NAT是端口受限的。
Symmetric NAT:上面3种类型,统称为Cone NAT,有一个共同点:只要是从同一个内部地址和端口出来的包,NAT都将它转换成同一个外部地址和端口。但是Symmetric有点不同,具体表现在:只要是从同一个内部地址和端口出来,且到同一个外部目标地址和端口,则NAT也都将它转换成同一个外部地址和端口。但如果从同一个内部地址和端口出来,是到另一个外部目标地址和端口,则NAT将使用不同的映射,转换成不同的端口(外部地址只有一个,故不变)。而且和Port Restricted Cone一样,只有曾经收到过内部地址发来包的外部地址,才能通过NAT映射后的地址向该内部地址发包。
现针对Symmetric NAT举例说明(例2):
A机器连接过B机器,假使是 A(192.168.0.4:5000)-> NAT(转换后210.21.12.140:8000)-> B(210.15.27.166:2000)
如果此时A机器(192.168.0.4:5000)还想连接C机器(210.15.27.140:2000),则NAT上产生一个新的映射,对应的转换可能为A(192.168.0.4:5000)-> NAT(转换后210.21.12.140:8001)-> C(210.15.27.140:2000)。此时,B只能用它的210.15.27.166:2000通过NAT的210.21.12.140:8000与A的192.168.0.4:5000通信, C也只能用它的210.15.27.140:2000通过NAT的210.21.12.140:8001与A的192.168.0.4:5000通信,而B或者C的其他端口则均不能和A的192.168.0.4:5000通信。
通过上面的例子,我们清楚了Stun协议对NAT进行分类的依据。那么,我们现在根据上述分类标准(或例子),来简要分析一下iptables的工作原理(仅指MASQUERADE、下同),看看他又是属于哪种NAT呢?
首先,我们去网上下载一个使用Stun协议检测NAT的工具,网址在http://sourceforge.net/projects/stun/,使用该工具对iptables的检测结果是Port restricted NAT detected。
我们先不要急着接受这个检测结果,还是先来分析一下iptables的工作原理吧!
iptables在转换地址时,遵循如下两个原则:
1、尽量不去修改源端口,也就是说,ip伪装后的源端口尽可能保持不变。(即所谓的Preserves port number)
2、更为重要的是,ip伪装后只需保证伪装后的源地址/端口与目标地址/端口(即所谓的socket)唯一即可。
仍以前例说明如下(例3):
A机器连接过B机器,假使是 A(192.168.0.4:5000)-> NAT(转换后210.21.12.140:5000)-> B(210.15.27.166:2000)。(注意,此处NAT遵循原则1、故转换后端口没有改变)
如果此时A机器(192.168.0.4:5000)还想连接C机器(210.15.27.140:2000),则NAT上产生一个新的映射,但对应的转换仍然有可能为A(192.168.0.4:5000)-> NAT(转换后210.21.12.140:5000)-> C(210.15.27.140:2000)。这是因为NAT(转换后210.21.12.140:5000)-> B(210.15.27.166:2000)和NAT(转换后210.21.12.140:5000)-> C(210.15.27.140:2000)这两个socket不重复。因此,对于iptables来说,这既是允许的(第2条原则)、也是必然的(第1条原则)。
在该例中,表面上看起来iptables似乎不属于Symmetric NAT,因为它看起来不符合Symmetric NAT的要求:如果从同一个内部地址和端口出来,是到另一个目标地址和端口,则NAT将使用不同的映射,转换成不同的端口(外部地址只有一个,故不变)。相反,倒是符合除Symmetric NAT外的三种Cone NAT的要求:从同一个内部地址和端口出来的包,NAT都将它转换成同一个外部地址和端口。加上iptables具有端口受限的属性(这一点不容置疑,后面举反例证明之),所以好多检测工具就把iptables报告为Port restricted NAT类型了。
下面仍以前例接着分析(例4):
在前例中增加D机器在A同一私网(192.168.0.5)
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转换原则可知,上述两个转换是允许且必然的。
如果此时A机器(192.168.0.4:5000)还想连接C机器(210.15.27.140:2000),则NAT上产生一个新的映射,但对应的转换则变为A(192.168.0.4:5000)-> NAT(转换后210.21.12.140:5001)-> C(210.15.27.140:2000)。这是因为,如果仍然将其转换为210.21.12.140:5000的话,则其所构成的socket(210.21.12.140:5000->210.15.27.140:2000)将和D->C的socket一致,产生冲突,不符合iptables的第2条原则(注意,此处以5001表示转换后不同的端口,但事实上,iptables却并不按照内部端口+1的原则来产生新的端口)。在本例中我们注意到,从同一个内部地址和端口A(192.168.0.4:5000)出来,到不同的目标地址和端口,则NAT使用了不同的映射,转换成不同的端口。
上面这个例子在实际环境中比较少见,我们再以QQ为例举一个真实且常见的例子(例5)。
假设
A(192.168.0.4)和 D(192.168.0.5)是同一NAT服务器(210.21.12.140)保护的两台私网机器,都运行了QQ客户端程序。
B机器在公网(210.15.27.166),运行QQ服务器程序。
C机器在公网(210.15.27.140),运行QQ客户端程序。
A上QQ先登陆到B,按照原则1,使用如下映射:
A(192.168.0.4:4000)-> NAT(转换后210.21.12.140:4000)-> B(210.15.27.166:8000)(原则1,端口不变)
接着D上QQ也登陆到B,按照原则2,使用如下映射:
D(192.168.0.5:4000)-> NAT(转换后210.21.12.140:4001)-> B(210.15.27.166:8000)(原则2,scoket不能有重复,此处4001仅表示转换后不同的端口,实际环境中决不是4001)
然后D欲和公网C(210.15.27.140)上的QQ通信,按照iptables转换原则,使用如下映射:
D(192.168.0.5:4000)-> NAT(转换后210.21.12.140:4000)-> C(210.15.27.140:4000)
到此我们发现,和上例一样,从同一个内部地址和端口D(192.168.0.5:4000)出来,到不同的目标地址和端口,则NAT使用了不同的映射,转换成不同的端口。但和上例不一样的是,本例显然普遍存在于实际环境中。
上面所举两例表明,结论刚好和例3相反,即iptables应该属于Symmetric NAT。
为什么会出现彼此矛盾的情况呢?首先从NAT分类的定义上来看, Stun协议和iptables对映射的理解不同。Stun协议认为,一个映射的要素是:内部地址端口和NAT转换后地址端口的组合。而在iptables看来,一个映射的要素是:NAT转换后地址端口和外部目标地址端口的组合。另一方面则是Stun协议里Discovery Process给出的测试环境不够全面之故,他只考虑了NAT后面仅有一台私网机器的特例(例3),没有考虑NAT后面可以有多台私网机器的普遍例子(例5)。正是由于这两个原因,直接导致了上述矛盾的发生。所以,凡按照Stun协议标准设计的NAT分类检测工具对iptables的检测结果必然是Port restricted NAT。(事实上,在例3那样的特例下,iptables确实是一个标准的Port restricted NAT)
那么,iptables究竟属于哪种NAT呢?我们再来回顾一下Stun协议对Cone NAT的要求:所有(或只要是)从同一个内部地址和端口出来的包,NAT都将它转换成同一个外部地址和端口。虽然iptables在部分情况下满足“从同一个内部地址和端口出来的包,都将把他转换成同一个外部地址和端口”这一要求,但它不能在所有情况下满足这一要求。所以理论上,我们就只能把iptables归为Symmetric NAT了。
下面,我们再来分析一下iptables的端口受限的属性,我们举一个反例证明之(例6),仍以前例说明如下:
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,但实际上,凡按照Stun协议标准设计的NAT分类检测工具对其检测结果也必然是Port restricted NAT。其实,不光是linux下iptables、或者Win2000下的ics或nat、再或者任何其他NAT产品,只要他们遵循和iptables一样的两条转换原则,那么他们在Stun协议下的表现是完全一样的。
3、虽然Win2000下的ics或nat在Stun协议下的表现和iptables完全一样,但其NAT时所遵循的原则1和iptables还是略有差别:iptables对内部私网机器来的所有源端口都将适用Preserves port number,除非确因原则2发生冲突而不得不更换源端口号,但在更换端口号时并不遵循内部端口+1原则(似乎没有规律)。Win2000下的ics或nat则仅对内部私网机器来的部分源端口(1025–3000)适用Preserves port number,对于那些超过3000的源端口号或者因原则2发生冲突的端口号,系统从1025开始重新按序分配端口,在此过程中,仍然遵循如前两个原则,只是原则1不再Preserves port number而已(在不与原则2发生冲突的前提下,尽量重复使用小的端口号,故使用1025的几率远远大于1026、1027…)。

留下评论

邮箱地址不会被公开。 必填项已用*标注

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据