NGN网络业务NAT穿透技术探讨

一、问题背景

目前，NGN网络正逐步从试验走向商用，在应用过程中出现了很多实际问题，特别是NGN用户的接入问题。NGN是基于分组的网络，能够提供电信业务；利用多种宽带能力和QoS保证的传送技术；其业务相关功能与其传送技术相独立。此外，NGN可以使用户自由接入到不同的业务提供商，并支持通用移动性。因为NGN是基于分组网承载的网络，所以接入用户是通过IP地址来寻址的，由于当前IP地址紧缺以及网络缺乏安全等原因，大量的企业网和驻地网基本都采用私有IP地址通过出口的NAT/FW接入公网。而目前NGN网络中，如H323、SIP、MGCP、H248等在IP上承载语音和视频的协议的控制通道或媒体通道在私网用户接入应用中难以穿越传统的NAT/FW设备与公网进行互通，或者说目前的NAT/FW大多支持HTTP的数据应用协议穿透，而无法支持会话业务的控制与媒体NAT/FW穿透。而NGN网络最大的好处就是能为用户提供丰富的业务，特别是为企业用户提供语音、数据、视频融合的IP Centrex业务，因此上述问题正成为NGN网络业务开展最大的障碍。目前业界的解决方案有：NAT/ALG 方式、MIDCOM 方式、STUN 方式、TURN方式、Full Proxy 方式。

下面针对企业网、驻地网小区用户接入NGN网络的解决方案，对几种方式进行简单介绍与分析。

二、技术方案

1．NAT/ALG方式

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

ALG功能目前主要驻留在一些NAT/Firewall设备中，这些设备具备应用识别的智能。同时，每增加一种新的应用都将需要对NAT/Firewall进行升级。

对NGN业务应用，ALG需要支持IP语音和视频协议（H323、SIP、MGCP/H248）的识别和对NAT/Firewall的控制，以使NGN业务顺利穿越NAT/Firewall。

图1NAT/ALG应用模型

图1为NAT/ALG方式的应用组网模型，企业网或驻地网内部终端设备能穿透NAT/ALG注册到公网SoftX上，通过SoftX进行协议解析和呼叫处理。

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

对于ALG应用来说，在应用业务安全要求上需要作一些折衷，因为ALG不能识别加密后的报文内容，所以必须保证报文采用明文传送，这使得报文在公网中传送时有很大的安全隐患。

NAT/ALG是支持NGN应用一种最简单的方式，但由于网络实际已部署了大量的不支持NGN业务应用的NAT/FW设备，因此我们不推荐使用这种方式，理由如下：

网上大量NAT/FW因不具备ALG能力，需要更换或升级

NGN业务的ALG生产厂家少，也没有一套产品特性需求基线

NAT/FW厂家一般不是IP业务领域的专家，难以支持业务的变化（如SIP的多种扩展）

用户不愿意重新购买NAT/FW设备，更无法判断各种ALG的可行性

用户普遍要求运营商在不改变已有NAT网络设备的情况下就可以提供新的IP业务

2．MIDCOM方式

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

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

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

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

图2MIDCOM应用模型

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

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

3．STUN方式

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

STUN的全称是SimpleTraversalofUDP 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，并且这些NAT/FW并不支持VoIP的应用，如果用MIDCOM或NAT/ALG方式来解决此问题，需要替换现有的NAT/FW，这是不太容易的。而采用STUN方式无需改动NAT/FW，这是其最大优势，同时STUN方式可在多个NAT串联的网络环境中使用，MIDCOM方式无法实现对多级NAT的有效控制。

STUN的局限性在于需要应用程序支持STUNCLIENT的功能，即NGN的网络终端需具备STUNClient功能。同时STUN并不适合支持TCP连接的穿越，因此不支持H323应用协议。另外STUN方式还不支持NGN业务对防火墙的穿越，同时STUN方式不支持对对称NAT（Symmetric NAT）类型的穿越在安全性要求较高的企业网中，出口NAT通常就是这种类型。

STUN的应用模型如下：

图3STUN应用模型

图3为STUN方式的应用组网模型，其关键点为：根据STUN原理，STUNServer必须放在公网中，可以内嵌在公网SoftX中，由于通过STUN协议已在NAT上预先建立媒体流的NAT映射表项，故媒体流可顺利穿越NAT。

4．TURN方式

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

TURN的全称为TraversalUsingRelayNAT，即通过Relay方式穿越NAT，它的应用模型如下图：

图4TURN应用模型

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

TURN的局限性在于需要终端支持TURNClient，这一点同STUN一样对网络终端有要求。此外，所有报文都必须经过TURNServer转发，增大了包的延迟和丢包的可能性。

5．FullProxy方式

FullProxy是另外一种解决NAT问题的思路，通过对私网内用户呼叫的信令和媒体同时做Relay来实现出口NAT/FW的穿越，与TURN方式的Relay相比，区别如下：

TURN方式是在TURNServer与终端通过TURN/STUN协议交互时分配地址和端口，报文内部的地址信息由终端生成，TURNServer对后续的报文根据分配的地址和端口信息做地址变换后Relay转发；

FullProxy方式是通过对报文进行Relay的设备对呼叫协议解析与处理，改写其中携带的RTP/RTCP地址信息后转发信令报文，同时根据改写的RTP/RTCP地址信息对媒体报文做地址变换后Relay转发。

其原理在于当私网终端呼叫信令到达FullProxy时，FullProxy将对呼叫信令协议进行解析，对协议中携带的RTP/RTCP信息进行解析与处理，在记录下用户私网内RTP/RTCP地址和端口号的同时，修改RTP/RTCP私网地址信息为FullProxy本身对外的公网IP地址，同时修改媒体流端口为Full Proxy上分配的外部端口，然后将呼叫信令发送到软交换或对端。这样呼叫信令以及媒体流就可以通过Full Proxy在主被叫之间进行中转。由于Full Proxy可以配置多个IP地址，如一个私网IP地址和一个公网IP地址，因此通过Full Proxy进行Relay，NGN业务可顺利通过NAT/FW.

在FullProxy方式下，无需现有NAT做任何改动即可开展NGN业务，可采用普通的设备，同时私网内的终端无需支持STUN和TURN协议，这是其一个较大的优势。其局限性同TURN一样，增加了包的延时和丢包的可能性。

图5FullProxy应用模型

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

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

在应用领域，由于FullProxy的配置很灵活，组网应用也很灵活，除了实现私网地址向公网地址的转换外，可同时实现公网地址向私网地址的转换，或其它不同地址域之间的变换，满足NGN不同场合下的组网应用。

三、方案比较

ALG MIDCOM STUN TURN Full PROXY

性能NAT设备需要对所有包进行动态监控和解析，将极大增加NAT设备的负担。NAT设备不需要对包进行动态监控，只需要接收从MIDCOMAgent来的指令。基本不会增加NAT设备的负担。 NAT设备不需要解析报文，不会增加NAT设备的负担，性能较好。 NAT设备不需要解析报文，不会增加NAT设备的负担，性能较好。 Full PROXY对所有呼叫报文和媒体流进行定向转发，效率要求较高，但只对会话类报文进行处理，不处理数据类业务。

可扩展性每增加一种协议，需要升级NAT设备，可扩展性差。Agent上进行协议开发。只支持UDP承载的协议，新的基于UDP承载的协议不要求对NAT设备升级。可扩展性最好。 PROXY上进行新协议的扩展。

组网应用小区/企业网，规模不能太大。小区/企业网/互通网关，视NAT设备效率而定。小区/企业网小区/企业网组网最灵活，小区/企业网/互通网关/其它各种NGN组网应用场合。

对现有设备改造需要对NAT设备升级，开发成本高。需要对NAT设备升级支持MIDCOM协议，呼叫代理支持MIDCOM协议。需要提供STUN Server，同时终端需要支持STUN Client功能。需要提供TURN Server，同时终端需要支持TURN Client功能。提供Full Proxy设备即可，其他设备无需修改。

安全性比较高高低低最高

QoS无保证有保证无保证无保证有保证

四、结论

根据上面的方案介绍和对比分析，推荐采用FullProxy和MIDCOM两种解决方案。

FullProxy方式由于不用对运营商和客户端的现有网络设备进行任何改造，具有很强的适应性，组网灵活，可满足NGN网络初期多样化的组网和用户接入。除了解决NAT问题外，功能可以大大扩展，同时可完成在接入层实现对会话业务QoS和安全的处理，可以发展成为NGN网络的用户接入平台。

MIDCOM方式具有很强的扩展性，一旦NAT/FW设备支持MIDCOM协议，MIDCOMAgent可内嵌于软交换中，可一劳永逸的解决NGN业务的NAT/FW穿透问题，同时由于软交换自身对用户呼叫协议的解析与处理，同样能动态下发呼叫的QoS和安全信息，下面的Middlebox（NAT/FW）设备根据这些信息采取必要的保证措施。由于目前网上大量的NAT/FW设备不支持MIDCOM功能，需要对设备进行修改，同时NGN网络应用初期软交换设备布点数量过少，网络层次较高，影响了这种方式在现有网络情况下的应用。