Chinaunix首页 | 论坛 | 博客
  • 博客访问: 417123
  • 博文数量: 38
  • 博客积分: 2513
  • 博客等级: 少校
  • 技术积分: 471
  • 用 户 组: 普通用户
  • 注册时间: 2008-02-22 13:35
文章分类

全部博文(38)

文章存档

2010年(4)

2009年(6)

2008年(28)

我的朋友

分类: LINUX

2008-06-16 15:43:34

第2期

      摘要:本文详细地分析了软交换领域中提出的各种解决企业用户在使用软交换业务时进行NAT穿越的技术的特点,以及它们的优缺点,并提出了选择私网穿越方式应遵循的原则。 

         关键词:私网穿越、NAT/ALG、MIDCOM、STUN、TURN、Full Proxy。
 


          一、概述

         在目前各运营商正在进行的软交换组网的实验过程中,大多都是将软交换网络承载在IP公网之上。对于软交换的核心设备,包括软交换设备、中继媒体网关、信令 网关和接入网关,都使用分配公网IP地址的策略;对于分散的软硬终端,一般采用将终端和ADSL分配的IP地址捆绑的方式,仍然使用公网IP地址。但是, 对于集团用户,为了节省有限的公网IP地址资源,很多企业网络使用的都是内部私有网络,用户访问外部IP网络时通过NAT方式进行地址转换,因此内部软交 换用户对软交换设备和应用服务器的访问也只能采用这种方式,即内部用户设备分配固定的私有IP地址,但实际通信时仍使用合法IP地址,通过NAT进行公私 有地址的转换。目前,NAT地址转换包括静态转换和动态转换两种方式。静态转换是在NAT表中事先为每一个需要转换的私有地址创建固定的映射表,建立私有 地址与公有地址的对应关系,当内部节点与外界通信时,边缘路由器或防火墙可进行相应的变换。动态转换则将可用的公有地址集定义成NAT池,对于要与外界进 行通信的内部节点,如果还没有建立转换映射,则边缘路由器或防火墙会动态地从NAT池中选择一个公有地址替换其私有地址,而在连接终止时再将地址回收。

        采用静态转换方式,在通信忙时仍需占用大量的地址资源,并不能避免地址资源紧张的问题;采用动态转换方式,对于实时业务来说,每个终端“永远在线”,若私 有地址与公有地址选择1:1的对应关系,也不能避免地址资源紧张的问题,唯一的解决方案是采用NAPT动态转换机制,即由多个内部节点共享一个公共IP地 址,用源和目的地址的TCP/UDP端口号来区分NAT表中的转换条目。

        NAPT方案虽然可有效地解决地址短缺的问题,但它对SIP、SDP或H.248/MGCP之类的应用层协议,一方面由于它们含有IP地址或端口等通信地 址信息,许多NAT只是简单地将私有IP包头转换成合法IP包头,但不能分析这些高层应用层协议,使这些协议无法透明穿透NAT,另一方面NAT不一定允 许某些端口的使用,且对实时通信往往需要保留地址映射,以便后续通信可重用此公有地址进行通信,但NAT很有可能会将公有地址回收。为了防止NAT丢弃相 关的信息,需另行制定协议以确保NAT设备保留地址映射关系。

         目前,业界对SIP协议的NAT穿透问题非常关注,也提出了各种解决方案,包括ALG、STUN(Simple Traversal of UDP through NAT)、MIDCOM(Traversal Using Relay NAT)等,这些解决方案各有其应用场合,下面我们分别介绍这些方案的特点。


        二、SIP协议的NAT穿透方案分析 

        1、NAT/ALG方式

        普通NAT是通过修改UDP或TCP报文头部地址信息实现地址转换的,但部分承载于TCP/UDP的应用,如多媒体会话、文件共享、游戏等“端到端”应 用,在TCP/UDP负载中也需要带地址信息。一般采用应用程序在负载中填写其自身地址,此地址信息在通过NAT时被修改为NAT对外的地址,即常说的 ALG方式。

        ALG功能目前主要驻留在一些NAT/Firewall设备中,这些设备具备应用识别的智能,每增加一种新的应用都要对NAT/Firewall进行升级。
对于NGN业务应用,ALG需要支持IP语音和视频协议(H.323、SIP、MGCP/H.248)的识别和对NAT/Firewall的控制,以使NGN业务能够顺利地穿越NAT/Firewall(FW)。

        公网SoftX和企业网终端通过SIP/H.323/MGCP/H.248协议互通,NAT/ALG需要识别SIP/H.323/MGCP/H.248协议信令并建立媒体流通道,以支持媒体流顺利穿越NAT/FW。

        ALG应用对业务安全的要求上需要进行一些折衷。这是因为,ALG不能识别加密后的报文内容,因此必须保证报文采用明文传送,使得报文在公网中的传送存在很大的安全隐患。

        NAT/ALG是支持NGN应用的一种最简单的方式,由于网络实际上已经部署了大量的不支持NGN业务应用的NAT/FW设备,因此不推荐使用这种方式。

        原因如下: 

        1) 网上大量NAT/FW不具备ALG能力,需更换或升级; 
        2) NGN业务的ALG生产厂家少,缺乏一套产品需求基线; 
        3) NAT/FW生产厂家一般不是IP领域专家,难以支持业务变化(如SIP扩展); 
        4) 用户不愿重新购买NAT/FW设备,更无法判断各种ALG的可行性; 
        5) 用户普遍要求运营商在不改变NAT网络设备的情况下即可提供新的IP业务。

        2、MIDCOM方式

        与NAT/ALG不同,MIDCOM的框架结构是采用可信的第三方(MIDCOM Agent)对Middlebox(NAT/FW)进行控制的机制,应用业务识别的智能也由Middlebox转移到外部的MIDCOM Agent上,应用协议对Middlebox透明。

        由于应用业务识别的智能从Middlebox移到外部的MIDCOM Agent上,根据MIDCOM架构,在不需要更改Middlebox基本特性的基础上,通过对MIDCOM Agent的升级即可支持更多的新业务,这是NAT/ALG方式的一个优势。 

        在NGN业务的实际应用中,Middlebox功能可驻留NAT/Firewall,通过软交换设备(即MIDCOM Agent)对IP语音和视频协议(H.323、SIP、MGCP/H.248)的识别和对NAT/Firewall的控制,作为NGN业务穿越 NAT/Firewall的一个解决方案。 

        从安全性考虑,MIDCOM方式支持控制报文的加密,支持媒体流的加密,安全性较高。 

        MIDCOM方式的应用组网模型关键点为:公网SoftX通过MIDCOM协议对私网边缘的NAT/FW设备进行控制,SoftX识别主被叫侧的 SIP/H.323/MGCP/H.248协议,如主被叫侧均为局内的私网用户,SoftX需要通过MIDCOM协议控制主被叫两侧的NAT/FW,在 NAT/FW上创建了媒体流通道后,媒体流可顺利穿越NAT/FW。

        由于软交换设备已经实现了对SIP/H.323/MGCP/H.248协议的识别,只需在软交换和NAT/FW设备上增加MIDCOM协议,而且以后新的 应用业务识别随着软交换的支持而支持,因此这是一种较有前途的方案,但现有的NAT/FW设备需升级支持MIDCOM协议。

         3、STUN方式

        解决NGN NAT问题的另一思路是,私网接入用户通过某种机制预先得到其地址对应在出口NAT上的对外地址,然后在报文负载中所描述的地址信息直接填写出口NAT上 的对外地址,而不是私网内用户的私有IP地址,因此报文负载中的内容在经过NAT时就无需被修改了,只需按普通NAT流程转换报文头的IP地址即可,负载 中的IP地址信息和报文头地址信息一致。STUN协议就是基于这一思路来解决应用层地址的转换问题。

        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。

        STUN协议最大的优点是无需更改现有的NAT/FW设备,网上大量的NAT/FW并不支持VoIP应用,如果用MIDCOM或NAT/ALG方式来解决 该问题,则需替换NAT/FW,这不太容易。但是,采用STUN方式则无需改动NAT/FW,同时STUN方式还可在多个NAT串联的网络环境中应用,而 MIDCOM方式则无法实现对多级NAT的有效控制。

        STUN协议的局限性在于,它需要应用程序支持STUN Client功能,即NGN网络终端需具备STUN Client功能。同时,STUN并不适合支持TCP连接的穿越,不支持H.323应用协议。另外,STUN方式不支持NGN业务对防火墙的穿越,同时也 不支持对称NAT(Symmetric NAT)类型的穿越,在安全性要求较高的企业网中,出口NAT通常采用这种类型。

        STUN应用模型的关键点在于:根据STUN原理,STUN Server必须放在公网,可内嵌在公网SoftX中,由于通过STUN协议已在NAT上预先建立媒体流的NAT映射表项,故媒体流可顺利穿越NAT。

         4、TURN方式

         TURN方式的思路与STUN相似,也是基于私网接入用户通过某种机制预先得到其私有地址对应在公网的地址(STUN得到的地址为出口NAT上的地址, TURN方式得到的地址为TURN Server上的地址),然后在报文负载中所描述的地址信息直接填写该公网地址,实际应用原理也是一样。

         TURN的英文全称为Traversal Using Relay NAT,即通过Relay方式穿越NAT。TURN应用模型通过分配TURN Server的地址和端口作为客户端对外的接收地址和端口,即私网用户发出的报文都要经过TURN Server进行Relay转发,这种方式应用模型除了具有STUN方式的优点外,还解决了STUN应用无法穿透对称NAT(Symmetric NAT)及类似Firewall设备的缺陷,无论企业网/驻地网出口为哪种类型的NAT/FW,都可以实现NAT穿透,同时还支持基于TCP的应用,如 H.323协议。此外,TURN Server控制分配地址和端口,能分配RTP/RTCP地址对(RTCP端口号为RTP端口号加1)作为本端客户的接收地址,避免STUN应用模型下出 口NAT对RTP/RTCP地址端口号的任意分配,使得客户端无法收到对端发过来的RTCP报文(对端发RTCP报文时,目的端口号缺省按RTP端口号加 1发送)。

        TURN的局限性在于它需要终端支持TURN Client,这一点与STUN一样。此外,所有报文都必须经过TURN Server转发,增大了包延迟和丢包的可能性。 

        5、Full Proxy方式

        Full Proxy是另外一种解决NAT问题的思路,它通过对私网内用户呼叫的信令和媒体同时进行Relay来实现出口NAT/FW的穿越。

        Full Proxy与TURN Relay的区别在于:TURN方式是在TURN Server与终端通过TURN/STUN协议交互时分配地址和端口,报文内部的地址信息由终端生成,TURN Server对后续的报文根据分配的地址和端口信息进行地址变换后Relay转发;Full Proxy方式是通过对报文进行Relay的设备对呼叫协议解析和处理,改写携带的RTP/RTCP地址信息后转发信令报文,同时根据改写的 RTP/RTCP地址信息对媒体报文进行地址变换后Relay转发。

        当私网终端呼叫信令到达Full Proxy时,Full Proxy对呼叫信令协议进行解析,对协议中携带的RTP/RTCP信息进行解析和处理,在记录下用户私网内RTP/RTCP地址和端口号的同时,修改 RTP/RTCP私网地址信息为Full Proxy本身对外的公网IP地址,同时修改媒体流端口为Full Proxy上分配的外部端口,然后将呼叫信令发送到软交换或对端。这样呼叫信令和媒体流就可以通过Full Proxy在主被叫之间进行中转。由于Full Proxy可以配置多个IP地址,如一个私网IP地址和一个公网IP地址,因此通过Full Proxy进行Relay,NGN业务可顺利通过NAT/FW。
在Full Proxy方式下,现有NAT无需进行任何改动即可开展NGN业务,它可采用普通设备,同时私网内的终端无需支持STUN、TURN协议,与TURN一样,这种方式也增加了包的延时和丢包的可能性。

        Full Proxy组网模型的关键点是它同时完成对终端呼叫信令的代理转发和媒体Relay。同时,Full Proxy还可借鉴TURN应用模型,拓展应用范围,除了可放在企业网/驻地网出口处外,还可类似TURN Server放在城域网汇聚层接入多个小企业,实现在不改动企业网出口NAT/FW的情况下,实现多个企业出口NAT/FW的穿透。

        由于Full Proxy方式会对呼叫协议进行解析,因此除了可以处理NAT问题之外,还可完成对每次呼叫带宽等QoS信息的解析和处理,从接入层保证QoS的安全问 题。此外,通过对呼叫状态的把握,Full Proxy方式还可实现媒体流的动态防火墙,保证网络安全和防止带宽盗用,可作为NGN终端接入层的NAT、QoS和安全保障的统一处理平台。

        在应用领域,Full Proxy的配置和组网方式非常灵活,除了可实现私网地址向公网地址的转换外,还可同时实现公网地址向私网地址的转换,以及其它不同地址域之间的变换,满足NGN在不同场合下的组网应用。

        6、方案讨论

        表1为上述几种方案在性能、可扩展性、组网应用、安全性和QoS等方面的表现。 

  
表1 


         三、选择方案必须遵循的原则

        在解决SIP协议的NAT穿透问题方案中,具体选择哪种方式需综合考虑下列因素: 

        1) 升级要求:哪些网络元素需要升级? 
        2) 网络业务量:应用方案是否会引入新的网络开销? 
        3) 话音质量:是否会影响到话音质量,增加时延或丢包率? 
        4) 运营商投资:运营商是否需要进行大量的投资? 
        5) 企业投资:是否需要企业客户进行大量的投资? 
        6) 确定性:是否只能应用于特定环境,是否可以穿越各种NAT? 
        7) 应用相关:是否只能针对SIP,是否支持其它应用? 
        8) 扩展性:是否支持大规模应用?

        通过方案对比,结合选择方案必须遵循的原则,显然Full Proxy方案更适合软交换应用。实际上,华为等厂家的软交换解决私网穿越的设备采用的就是Full Proxy技术,图1是华为Full Proxy设备解决私网穿越的组网示意图。



图1 Full Proxy解决私网穿越问题 


        四、结论

        本文详细介绍了五种解决软交换终端接入软交换网络时的私网穿越问题的技术,并在性能、可扩展性、组网应用、安全性和QoS等方面进行了对比。从对比结果来 看,Full Proxy方式不需对运营商和客户端的现有网络设备进行任何改造,并具有很强的适应性,组网方式灵活,可满足NGN网络初期多样化的组网和用户接入,除了 解决NAT问题之外,同时还可完成在接入层实现对会话业务QoS和安全的处理,适合软交换应用,可发展成为软交换网络的用户接入平台。

阅读(2154) | 评论(0) | 转发(0) |
0

上一篇:jrtplib介绍

下一篇:CGI动态页面

给主人留下些什么吧!~~