关于stun学习笔记1

STUN的全称是Simple Traversalof UDP Through Network Address translators，即UDP对NAT的简单穿越方式。应用程序（即STUN CLIENT）向NAT外的STUN SERVER通过UDP发送请求STUN 消息询问自身的转换后地址，STUN SERVER收到请求消息，产生响应消息，响应消息中携带请求消息的源端口，即STUN CLIENT在NAT上对应的外部端口。然后响应消息通过NAT发送给STUN CLIENT，STUN CLIENT通过响应消息体中的内容得知其在NAT上对应的外部地址，并且将其填入以后呼叫协议的UDP负载中，告知对端，同时还可以在终端注册时直接注册这个转换后的公有IP地址，这样就解决了H.323/MGCP/SIP穿越NAT的通信建立问题以及作为被叫时的问题。本端的接收地址和端口号为NAT外的地址和端口号。由于通过STUN协议已在NAT上预先建立媒体流的NAT映射表项，故媒体流可顺利穿越NAT。
需要注意的是，NAT/PAT对于地址转换关系是有一定生命期的，某个地址转换后在一段时间内没有被使用将会被清除，当这个业务流再次出现时，将会建立一个新的地址转换关系，这就意味着STUN的询问过程以及终端的注册过程都需要再执行一遍才能保证通信的正确。解决这个问题一个比较通行的方案是采用某种方式保持NAT/PAT的转换关系，例如在NAT/PAT生命期内重复注册一次，比如NAT/PAT的生命期是3分钟，那么就将注册重复周期设置为2分钟。
另外STUN server并非指一个专用的服务器，而是指一种功能、一个协议，我们可以在softswitch或者任何一个需要此功能的服务器上内置此协议。
NAT可以细分为几种操作模式，其中有一种称为symmetric NAT(对称NAT)。所谓对称NAT是指当私网内的用户A访问公网用户B时，NAT为A到B的访问
所形成的地址对应关系只能服务于A与B之间的通信。虽然A已经拥有了公有地址A'，但A'并不能为其它用户使用以达到与A通信的目的。这是出于安全性考虑的一种设计。一些功能较强的NAT提供这种可选工作模式。
当NAT采用这种对称模式工作时，STUN的方案就会出现问题。
假如我们在softswitch上提供STUN server功能，终端A通过STUN可以获得NAT为终端A与softswitch之间通信分配的地址A'，并将这个地址注册在softswitch上，当一个公网上的终端B呼叫终端A时，A'和B通过softswitch完成呼叫建立过程。当B试图向A'发送媒体流时，问题就出现了。因为对称NAT只允许从softswitch发送数据给地址A'，从B发送的媒体流将被丢弃。所以STUN无法应用于工作在对称模式的NAT
STUN协议最大的优点是无需现有NAT/FW设备做任何改动,同时STUN方式可在多个NAT串联的网络环境中使用
STUN的局限性在于STUN并不适合支持TCP连接的穿越,同时STUN方式不支持对对称NAT（Symmetric NAT）

TURN

TURN又称SPAN(Simple Protocol for Augmenting NATs)方式

TURN方式解决NAT问题的思路与STUN相似，也是基于私网接入用户通过某种机制预先得到其私有地址对应在公网的地址（STUN方式得到的地址为出口NAT上的地址，TURN方式得到地址为TURNServer上的地址），然后在报文负载中所描述的地址信息直接填写该公网地址的方式，实际应用原理也是一样的。
TURN的全称为Traversal Using RelayNAT，即通过Relay方式穿越NAT，TURN应用模型通过分配TURNServer的地址和端口作为客户端对外的接受地址和端口，即私网用户发出的报文都要经过TURNServer进行Relay转发，这种方式应用模型除了具有STUN方式的优点外，还解决了STUN应用无法穿透对称NAT（Symmetric NAT）以及类似的Firewall设备的缺陷，即无论企业网/驻地网出口为哪种类型的NAT/FW，都可以实现NAT的穿透，同时TURN支持基于TCP的应用，如H323协议。此外TURN Server控制分配地址和端口，能分配RTP/RTCP地址对（RTCP端口号为RTP端口号加1）作为本端客户的接受地址,避免了STUN应用模型下出口NAT对RTP/RTCP地址端口号的任意分配，使得客户端无法收到对端发过来的RTCP报文（对端发RTCP报文时,目的端口号缺省按RTP端口号加1发送)
TURN的局限性在于所有报文都必须经过TURNServer转发，增大了包的延迟和丢包的可能性。


Accessasp.netC#CSSdelphiFoxProhtml注册表JavaJsjspMsSQLMySQLOraclephpvc++网页firefox添加到收藏夹 返回目录页 上一篇：GNOMEnclature：为G...

LINUX软件学习技巧：iptables下udp穿越基础篇

　　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的工作原理，看看他又是属于哪种NAT呢？
　　首先，我们去网上下载一个使用Stun协议检测NAT的工具，网址在http://sourceforge.net/projects/stun/，使用该工具对iptables的检测结果是Port restricted NAT detected。
　　我们先不要急着接受这个检测结果，还是先来分析一下iptables的工作原理吧！
　　iptables在转换地址时，遵循如下两个原则：
　　1、尽量不去修改源端口，也就是说，ip伪装后的源端口尽可能保持不变。
　　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）-> C（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协议下的表现是完全一样的