Chinaunix

标题: [转贴]iptables下udp穿越基础篇----iptables与stun [打印本页]

作者: xiaoyi1982 时间: 2005-12-31 01:04
标题: [转贴]iptables下udp穿越基础篇----iptables与stun
[转贴]

文章标题 iptables下udp穿越基础篇----iptables与stun
张贴者： shixudong (member)
张贴日期 09/24/04 11:12 PM

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…）。

即将推出其姊妹篇----iptables下udp穿越实用篇----“iptables与natcheck”

shixudong@163.com

作者: xiaoyi1982 时间: 2005-12-31 16:18
这些讲的是udp的,不知道tcp的原理是否也是一样?

那位能讲解一下呢?

作者: platinum 时间: 2005-12-31 16:44
tcp 的机制和 udp 完全不同，udp 之所以能完成穿越，是因为 udp 是无连接协议
我知道的 nat 有两种，一种是“圆锥 nat”，一种是“对称 nat”
iptables 的 nat 是不能完成 udp 透传的
也就是说，如果网络两边都是 iptables 做的 nat，那么两边的 client 无法实现 udp 透传功能

作者: xiaoyi1982 时间: 2006-01-02 00:04

原帖由 platinum 于 2005-12-31 16:44 发表
tcp 的机制和 udp 完全不同，udp 之所以能完成穿越，是因为 udp 是无连接协议
我知道的 nat 有两种，一种是“圆锥 nat”，一种是“对称 nat”
iptables 的 nat 是不能完成 udp 透传的
也就是说，如果网络两边都 ...

tcp和udp的机制虽然不同，但是iptables的转发是基于状态的吧？
tcp也有状态，所以，
在这篇文章没有错误观点的前提下，
我这样理解对吗：
如果网络两端都是iptables做的NAT，并且没有做端口映射，
那么多数情况下，tcp和udp都不能透传。

作者: platinum 时间: 2006-01-02 00:55
你把 state 和 TCP 的 SYN、SYN/ACK、ACK 搞混了
TCP 之所以不能穿透，是因为用 UDP 的方法无法完成 TCP 的三次握手
而 UDP 根本不需要三次握手，只要同时双方对着发一次包就行了，NAT 会自动为对方打开一个临时通道

作者: xiaoyi1982 时间: 2006-01-02 11:09
我的确是还没弄明白

不过UDP的包大多数情况下,也不能穿透吧?

作者: ycfei 时间: 2006-01-02 12:22
长见识了.

作者: xiaoyi1982 时间: 2006-01-02 13:07

原帖由 platinum 于 2006-1-2 00:55 发表
你把 state 和 TCP 的 SYN、SYN/ACK、ACK 搞混了
TCP 之所以不能穿透，是因为用 UDP 的方法无法完成 TCP 的三次握手
而 UDP 根本不需要三次握手，只要同时双方对着发一次包就行了，NAT 会自动为对方打开一个临时 ...

我现在稍微想清楚些了,
能把TCP的三次握手看成是3个独立的包吗?
拿QQ来说,
假设客户端的4000和nat服务器的4000端口都没被占用,
客服端通过4000端口发送tcp的一个SYN包,被nat成服务器的ip和4000端口,连接远程的8000端口,
远程服务器回复一个SYN/ACK包到nat的4000端口,因为此时nat服务器的4000端口只有一个映射,就是到内网客服端4000的,所以客服端能收到这个包,
客服端再回一个ACK包,照SYN包的方式发送,此时连接建立.
所以说,
tcp在只有单条映射的特定条件下,也是可以透传的.

不知道这样说对不对?

作者: 網中人 时间: 2006-01-03 00:42
TCP 的 stateful , 可以搞懂 seq number 跟 ack number 的演算規則, 就有概念了.

作者: jsean 时间: 2006-01-04 14:18
我觉得能否穿越，只要能实现唯一性的影射就OK了

作者: paub 时间: 2006-01-05 11:34
标题: 回复 1楼 xiaoyi1982 的帖子
胜读十年书

作者: creat7151 时间: 2006-01-10 11:26
希望各位大虾多给菜鸟发这样的贴子，

作者: happy2005huan 时间: 2006-01-12 09:11
高手。。小生好像看都没有看懂！

欢迎光临 Chinaunix (http://bbs.chinaunix.net/)