STUN(Simple Traversal of User Datagram Protocol through Network Address Translators (NATs),NAT的UDP简单穿越)是一种网络协议,它允许位于NAT(或多重NAT)后的客户端找出自己的公网地址,查出自己位于哪种类型的NAT之后以及NAT为某一个本地端口所绑定的Internet端端口。这些信息被用来在两个同时处于NAT 路由器之后的主机之间建立UDP通信。该协议由RFC 3489定义。
方案:
一旦客户端得知了Internet端的UDP端口,通信就可以开始了。如果NAT是完全圆锥型的,那么双方中的任何一方都可以发起通信。如果NAT是受限圆锥型或端口受限圆锥型,双方必须一起开始传输。
需要注意的是,要使用STUN RFC中描述的技术并不一定需要使用STUN协议——还可以另外设计一个协议并把相同的功能集成到运行该协议的服务器上。
SIP之类的协议是使用UDP分组在Internet上传输音频和/或视频数据的。不幸的是,由于通信的两个末端往往位于NAT之后,因此用传统的方法是无法建立连接的。这也就是STUN发挥作用的地方。
STUN是一个客户机-服务器协议。一个VoIP电话或软件包可能会包括一个STUN客户端。这个客户端会向STUN服务器发送请求,之后,服务器就会向STUN客户端报告NAT路由器的公网IP地址以及NAT为允许传入流量传回内网而开通的端口。
以上的响应同时还使得STUN客户端能够确定正在使用的NAT类型——因为不同的NAT类型处理传入的UDP分组的方式是不同的。四种主要类型中有三种是可以使用的:完全圆锥型NAT、受限圆锥型NAT和端口受限圆锥型NAT——但大型公司网络中经常采用的对称型NAT(又称为双向NAT)则不能使用。
算法:
STUN 使用下列的算法(取自 RFC 3489)来发现 NAT gateways 以及防火墙(firewalls):
的识别和对NAT/Firewall的控制,同时每增加一种新的应用都将需要对 NAT/Firewall进行升级。<br />
在安全要求上还需要作一些折衷,因为ALG 不能识别加密后的报文内容,所以必须保证报文采用明文传送,这使得报文在公网中传送时有很大的安全隐患。<br />
NAT/ALG是支持VOIP NAT穿透的一种最简单的方式,但由于网络实际情况是已部署了大量的不支持此种特性的NAT/FW设备,因此,实际应用中,很难采用这种方式。<br />
二、MIDCOM 方式<br />
与NAT/ALG不同的是,MIDCOM的基本框架是采用可信的第三方(MIDCOM Agent)对Middlebox (NAT/FW)进行控制,VOIP协议的识别不由Middlebox完成,而是由外部的MIDCOM Agent完成,因此VOIP使用的协议对Middlebox是透明的 .<br />
由于识别应用协议的功能从Middlebox移到外部的MIDCOM Agent上,根据MIDCOM 的构,在不需要更改Middlebox基本特性的基础上,通过对MIDCOM Agent的升级就可以支持更多的新业务,这是相对NAT/ALG方式的一个很大的优势。<br />
在VOIP实际应用中,Middlebox功能可驻留在NAT/Firewall,通过软交换设备(即MIDCOM Agent)对IP语音和视频协议(H323、SIP、MGCP/H248)的识别和对NAT/Firewall的控制,来完成VOIP应用穿越 NAT/Firewall .在安全性上,MIDCOM方式可支持控制报文的加密,可支持媒体流的加密,因此安全性比较高。<br />
如果在软交换设备上实现对SIP/H323/MGCP/H248协议的识别,就只需在软交换和NAT/FW设备上增加MIDCOM协议即可,而且以后新的应用业务识别随着软交换的支持而支持,此方案是一种比较有前途的解决方案,但要求现有的NAT/FW设备需升级支持MIDCOM协议,从这一点上来说,对已大量布署的NAT/FW设备来说,也是很困难的,同NAT/ALG方式有相同的问题。<br />
三、STUN 方式<br />
解决穿透NAT问题的另一思路是,私网中的VOIP终端通过某种机制预先得到出口NAT上的对外地址,然后在净载中所填写的地址信息直接填写出口 NAT上的对外地址,而不是私网内终端的私有IP地址,这样净载中的内容在经过NAT时就无需被修改了,只需按普通NAT流程转换报文头的IP地址即可,净载中的 IP地址信息和报文头地址信息是一致的。STUN协议就是基于此思路来解决应用层地址的转换问题。<br />
STUN的全称是Simple Traversal of 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负载中,告知对端,本端的RTP接收地址和端口号为NAT 外部的地址和端口号。由于通过STUN协议已在NAT上预先建立媒体流的NAT映射表项,故媒体流可顺利穿越NAT.<br />
STUN协议最大的优点是无需现有NAT/FW设备做任何改动。由于实际应用中,已有大量的NAT/FW,并且这些NAT/FW并不支持VoIP的应用,如果用MIDCOM或NAT/ALG方式来解决此问题,需要替换现有的NAT/FW,这是不太容易的。而采用STUN方式无需改动NAT/FW,这是其最大优势,同时STUN方式可在多个NAT串联的网络环境中使用,但MIDCOM方式则无法实现对多级NAT的有效控制。<br />
STUN的局限性在于需要VOIP终端支持STUN CLIENT的功能,同时STUN并不适合支持TCP连接的穿越,因此不支持H323.另外 STUN方式不支持对防火墙的穿越,不支持对称NAT (Symmetric NAT)类型(在安全性要求较高的企业网中,出口NAT通常是这种类型)穿越。<br />
四、TURN方式<br />
TURN方式解决NAT问题的思路与STUN相似,也是私网中的VOIP终端通过某种机制预先得公网上的服务地址(STUN方式得到的地址为出口 NAT上外部地址,TURN方式得到地址为TURN Server上的公网地址),然后在报文净载中所要求的地址信息就直接填写该公网地址。<br />
TURN的全称为Traversal Using Relay NAT,即通过Relay方式穿越NAT.TURN应用模型通过分配 TURN Server的地址和端口作为私网中VOIP终端对外的接受地址和端口,即私网终端发出的报文都要经过TURN Server进行Relay转发,这种方式除了具有STUN方式的优点外,还解决了STUN应用无法穿透对称NAT(Symmetric NAT)以及类似的Firewall设备的缺陷,同时TURN支持基于TCP的应用,如H323协议。此外TURN Server控制分配地址和端口,能分配RTP/RTCP地址对(RTCP端口号为RTP端口号加1)作为私网终端用户的接受地址,避免了STUN方式中出口NAT对RTP/RTCP地址端口号的任意分配,使得客户端无法收到对端发来的RTCP报文(对端发RTCP报文时,目的端口号缺省按RTP端口号加 1发送)。<br />
TURN的局限性在于需要VOIP终端支持TURN Client,这一点同STUN一样对网络终端有要求。此外,所有报文都必须经过TURN Server转发,增大了包的延迟和丢包的可能性。<br />
<br /> </div>
<!-- <div class=)
管理员在2009年8月13日编辑了该文章文章。
阅读(1414) | 评论(0) | 转发(0) |