几种不同的NAT方式

１ 背景

　　目前，ＮＧＮ正逐步从试验走向商用，在此过程中遇到了很多实际问题，特别是ＮＧＮ用户的接入问题。ＮＧＮ是一个基于分组网承载的网络，接入用户都是通过ＩＰ地址来寻址的，但当前网络的实际情况是，由于ＩＰ地址资源紧缺以及安全等原因，网上大量的企业网和驻地网基本都采用私有ＩＰ地址通过出口的ＮＡＴ（ＮｅｔｗｏｒｋＡｄｄｒｅｓｓ Ｔｒａｎｓｌａｔｉｏｎ，网络地址转换）／ＦＷ（Ｆｉｒｅ Ｗａｌｌ，防火墙）接入公网，而目前在ＩＰ上承载语音和视频的协议（如Ｈ.３２３、ＳＩＰ、ＭＧＣＰ、Ｈ２４８等），由于其本身的特点所决定，在私网用户接入应用中，这些协议的控制通道／媒体通道难以穿越传统的ＮＡＴ／ＦＷ 设备与公网进行互通，或者说目前的ＮＡＴ／ＦＷ大多支持ＨＴＴＰ的数据应用协议穿透，而不支持会话业务的控制与媒体ＮＡＴ／ＦＷ穿透。ＮＧＮ最大的好处就是能为用户提供丰富的业务，特别是能为企业用户提供语音、数据、视频融合的ＩＰＣｅｎｔｒｅｘ业务，因此上面所提到的问题就成为目前开展ＮＧＮ业务最大的障碍，迫切需要解决。目前业界的解决方案有如下几种：

　　ＮＡＴ／ＡＬＧ（Ａｐｐｌｉｃａｔｉｏｎ Ｌａｙｅｒ Ｇａｔｅｗａｙ，应用层网关）方式；

　　ＭＩＤＣＯＭ（Ｍｉｄｄｌｅｂｏｘ Ｃｏｍｍｕｎｉｃａｔｉｏｎ）方式；

　　ＳＴＵＮ（Ｓｉｍｐｌｅ Ｔｒａｖｅｒｓａｌ ｏｆ ＵＤＰ Ｔｈｒｏｕｇｈ Ｎｅｔｗｏｒｋ Ａｄｄｒｅｓｓ Ｔｒａｎｓｌａｔｏｒｓ，ＵＤＰ对ＮＡＴ的简单穿越）方式；

　　ＴＵＲＮ（Ｔｒａｖｅｒｓａｌ Ｕｓｉｎｇ Ｒｅｌａｙ ＮＡＴ，通过中继方式穿越ＮＡＴ）方式；

　　Ｆｕｌｌ Ｐｒｏｘｙ（信令代理＋媒体中继）方式。

２ 技术方案

２.１ ＮＡＴ／ＡＬＧ方式

　　普通的ＮＡＴ是通过修改ＵＤＰ或ＴＣＰ报文头部地址信息实现地址转换的，但部分承载于ＴＣＰ／ＵＤＰ的应用，如多媒体会话、文件共享、游戏等“端到端”的应用，在ＴＣＰ／ＵＤＰ负载中也需要携带地址信息。一般的方法是应用程序在负载中填写其自身地址，此地址信息在通过ＮＡＴ时被修改为ＮＡＴ上对外的地址。这就是我们常说的ＡＬＧ方式。

　　对于ＮＧＮ业务应用，ＡＬＧ需要支持对ＩＰ 语音和视频协议（Ｈ.３２３、ＳＩＰ、ＭＧＣＰ／Ｈ.２４８）的识别和对ＮＡＴ／ＦＷ的控制，以便使ＮＧＮ业务顺利穿越ＮＡＴ／ＦＷ。

　　ＮＡＴ／ＡＬＧ方式的应用组网的关键为：企业网／驻地网内部终端设备能穿透ＮＡＴ／ＡＬＧ注册到公网软交换上，通过软交换进行协议解析和呼叫处理。

　　公网软交换和企业网终端通过ＳＩＰ／Ｈ.３２３／ＭＧＣＰ／Ｈ.２４８ 协议互通，ＮＡＴ／ＡＬＧ需要识别ＳＩＰ／ Ｈ.３２３／ＭＧＣＰ／Ｈ.２４８协议信令并建立媒体流通道，以支持媒体流顺利穿越ＮＡＴ／ＦＷ。

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

　　ＮＡＴ／ＡＬＧ是支持ＮＧＮ应用的一种最简单的方式，但由于网络已部署了大量的、不支持ＮＧＮ业务应用的ＮＡＴ／ＦＷ设备，因此我们不推荐采用这种方式，理由如下：

　　网上大量的ＮＡＴ／ＦＷ设备因不具备ＡＬＧ能力，需要更换或升级；

　　ＮＧＮ业务的ＡＬＧ生产厂商少，也没有一套产品特性需求基线；

　　ＮＡＴ／ＦＷ设备厂商一般不是ＩＰ业务领域的专业厂商，难以支持业务的变化（如ＳＩＰ的扩展多种多样）；

　　用户不愿意重新购买ＮＡＴ／ＦＷ设备，更无法判断各种ＡＬＧ的可行性；

　　用户普遍希望运营商在不改变已有网络设备（ＮＡＴ）的情况下就可以提供新的ＩＰ业务。

２.２ ＭＩＤＣＯＭ方式

　　与ＮＡＴ／ＡＬＧ不同的是，ＭＩＤＣＯＭ的框架结构采用可信的第三方（ＭＩＤＣＯＭ Ａｇｅｎｔ）对Ｍｉｄｄｌｅｂｏｘ （ＮＡＴ／ＦＷ ）进行控制的机制，应用业务识别智能也由Ｍｉｄｄｌｅｂｏｘ转移到外部的ＭＩＤＣＯＭＡｇｅｎｔ上，因此应用协议对Ｍｉｄｄｌｅｂｏｘ是透明的。

　　由于应用业务识别的智能从Ｍｉｄｄｌｅｂｏｘ转移到外部的ＭＩＤＣＯＭ Ａｇｅｎｔ上，因此根据ＭＩＤＣＯＭ 的架构，在不需要更改Ｍｉｄｄｌｅｂｏｘ基本特性的基础上，通过对ＭＩＤＣＯＭＡｇｅｎｔ的升级就可以支持更多的新业务，这是ＭＩＤＣＯＭ相对ＮＡＴ／ＡＬＧ方式的一个很大的优势。

　　在ＮＧＮ业务实际应用中，Ｍｉｄｄｌｅｂｏｘ功能可驻留在ＮＡＴ／ＦＷ中，通过软交换设备（即ＭＩＤＣＯＭ Ａｇｅｎｔ）实现对ＩＰ语音和视频协议（Ｈ.３２３、ＳＩＰ、ＭＧＣＰ／Ｈ.２４８）的识别和对ＮＡＴ／ＦＷ的控制，因此它可以作为ＮＧＮ业务穿越ＮＡＴ／ＦＷ的一个解决方案。

　　从安全性方面考虑，ＭＩＤＣＯＭ方式可支持控制报文和媒体流的加密，因此安全性比较高。

　　ＭＩＤＣＯＭ 方式的应用组网的关键为：公网软交换通过ＭＩＤＣＯＭ协议对私网边缘的ＮＡＴ／ＦＷ设备进行控制，软交换识别主、被叫侧的ＳＩＰ／Ｈ.３２３／ＭＧＣＰ／Ｈ.２４８协议，如主、被叫侧均为局内的私网用户，软交换需要通过ＭＩＤＣＯＭ协议控制主、被叫两侧的ＮＡＴ／ＦＷ，在ＮＡＴ／ＦＷ上创建了媒体流通道后，媒体流可顺利穿越ＮＡＴ／ＦＷ。

　　由于软交换设备上已经实现了对ＳＩＰ／Ｈ.３２３／ＭＧＣＰ／Ｈ.２４８协议的识别，因此只需在软交换和ＮＡＴ／ＦＷ设备上增加ＭＩＤＣＯＭ协议即可，而且以后新的应用业务识别将支持软交换所支持的一切功能。因此，这种方案是一种比较有前途的解决方案，但现有的ＮＡＴ／ＦＷ设备需升级以支持ＭＩＤＣＯＭ协议。

２.３ ＳＴＵＮ方式

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

　　ＳＴＵＮ协议最大的优点是无需对现有的ＮＡＴ／ＦＷ设备做任何改动。由于实际的网络环境中已有大量的ＮＡＴ／ＦＷ，并且这些ＮＡＴ／ＦＷ并不支持ＶｏＩＰ的应用，因此若采用ＭＩＤＣＯＭ或ＮＡＴ／ＡＬＧ方式来解决此问题，则需要替换现有的ＮＡＴ／ＦＷ，这是不太容易实现的。除此之外，ＳＴＵＮ方式还可在多个ＮＡＴ串联的网络环境中使用，这也是ＭＩＤＣＯＭ方式无法做到的。

　　ＳＴＵＮ的局限性是：需要应用程序支持ＳＴＵＮ Ｃｌｉｅｎｔ的功能，即ＮＧＮ终端需要具备ＳＴＵＮ Ｃｌｉｅｎｔ的功能；不适合支持ＴＣＰ连接的穿越，因此不支持Ｈ?郾３２３应用协议；不支持ＮＧＮ业务对防火墙的穿越，也不支持对称ＮＡＴ（Ｓｙｍｍｅｔｒｉｃ ＮＡＴ）类型（在安全性要求较高的企业网中，出口ＮＡＴ通常就是这种类型）的穿越。

　　ＳＴＵＮ方式的应用组网的关键是：ＳＴＵＮ Ｓｅｒｖｅｒ必须放在公网中，也可以内嵌在公网软交换中。由于通过ＳＴＵＮ协议已在ＮＡＴ上预先建立媒体流的ＮＡＴ映射表项，因此媒体流可顺利穿越ＮＡＴ。

２.４ ＴＵＲＮ方式

　　ＴＵＲＮ方式解决ＮＡＴ问题的思路与ＳＴＵＮ相似，实际应用原理也基本相同。

　　ＴＵＲＮ应用方式采用ＴＵＲＮ Ｓｅｒｖｅｒ的地址和端口作为客户端对外的接收地址和端口，即私网用户发出的报文都要经过ＴＵＲＮ Ｓｅｒｖｅｒ进行Ｒｅｌａｙ转发。这种应用方式除了具有ＳＴＵＮ方式的优点外，还解决了ＳＴＵＮ应用无法穿透对称ＮＡＴ（ＳｙｍｍｅｔｒｉｃＮＡＴ）以及类似的ＦＷ设备的问题（即无论企业网／驻地网出口为哪种类型的ＮＡＴ／ＦＷ，都可以实现ＮＡＴ的穿透），同时ＴＵＲＮ还支持基于ＴＣＰ的应用，如Ｈ.３２３协议。此外，ＴＵＲＮＳｅｒｖｅｒ控制分配地址和端口，能分配ＲＴＰ／ＲＴＣＰ地址对（ＲＴＣＰ端口号=ＲＴＰ端口号+１）作为本端客户的接收地址，从而避免了ＳＴＵＮ应用方式下出口ＮＡＴ对ＲＴＰ／ＲＴＣＰ地址端口号的任意分配。

　　ＴＵＲＮ的局限性是：需要终端支持ＴＵＲＮ Ｃｌｉｅｎｔ，且所有报文都必须经过ＴＵＲＮ Ｓｅｒｖｅｒ转发，增大了包的延迟和丢包的可能性。

２.５ Ｆｕｌｌ Ｐｒｏｘｙ方式

　　Ｆｕｌｌ Ｐｒｏｘｙ方式通过对私网内用户呼叫的信令和媒体同时做Ｒｅｌａｙ来实现出口ＮＡＴ／ＦＷ的穿越。

　　当私网终端呼叫信令到达Ｆｕｌｌ Ｐｒｏｘｙ时，Ｆｕｌｌ Ｐｒｏｘｙ将对呼叫信令协议中携带的ＲＴＰ／ＲＴＣＰ信息进行解析与处理，在记录用户私网内ＲＴＰ／ＲＴＣＰ地址和端口号的同时，修改ＲＴＰ／ＲＴＣＰ私网地址信息为ＦｕｌｌＰｒｏｘｙ本身对外的公网ＩＰ地址，并修改媒体流端口为Ｆｕｌｌ Ｐｒｏｘｙ上分配的外部端口，然后将呼叫信令发送到软交换或对端。这样呼叫信令以及媒体流就可以通过ＦｕｌｌＰｒｏｘｙ在主被叫之间进行中转了。

　　在Ｆｕｌｌ Ｐｒｏｘｙ 方式下，无需对现有的ＮＡＴ设备做任何改动，采用普通的设备即可，同时私网内的终端也无需支持ＳＴＵＮ和ＴＵＲＮ协议即可开展ＮＧＮ业务，这是其较大的一个优势。它的局限性同ＴＵＲＮ一样，增加了包的延时和丢包的可能性。

　　Ｆｕｌｌ Ｐｒｏｘｙ方式的应用组网的关键是：同时完成对终端呼叫信令的代理转发和媒体Ｒｅｌａｙ。同时，Ｆｕｌｌ Ｐｒｏｘｙ还可借鉴ＴＵＲＮ的应用组网方式，拓展应用范围。

　　由于Ｆｕｌｌ Ｐｒｏｘｙ方式会对呼叫协议进行解析，因此除了可以处理ＮＡＴ问题外，还可完成对每次呼叫带宽等ＱｏＳ信息的解析与处理，从接入层保证ＱｏＳ的安全问题。此外，通过对呼叫状态的把握，还可实现对媒体流的动态防火墙，保证网络安全和防止带宽被盗用等。

　　在应用领域，Ｆｕｌｌ Ｐｒｏｘｙ由于配置灵活，因此组网应用也很灵活，除了可实现私网地址向公网地址的转换外，还可实现公网地址向私网地址的转换，或其它不同地址域之间的变换，以满足ＮＧＮ不同场合下的组网应用。

３ 小结

　　根据上面的方案介绍和方案的对比分析，推荐采用Ｆｕｌｌ Ｐｒｏｘｙ和ＭＩＤＣＯＭ两种解决方案。

　　Ｆｕｌｌ Ｐｒｏｘｙ方式由于不用对运营商和客户端的现有网络设备进行任何改造，因此具有很强的适应性，并且组网灵活，可满足ＮＧＮ初期多样化的组网和用户接入要求。除了解决ＮＡＴ问题外，其功能还可以大大地被扩展，同时在接入层可完成对会话业务ＱｏＳ和安全的处理，从而可发展成为一个ＮＧＮ的用户接入平台。

　　ＭＩＤＣＯＭ方式具有很强的扩展性，一旦ＮＡＴ／ＦＷ设备支持ＭＩＤＣＯＭ协议，ＭＩＤＣＯＭ Ａｇｅｎｔ就可内嵌于软交换中，便可一劳永逸地解决ＮＧＮ业务的ＮＡＴ／ＦＷ的穿透问题；同时，由于软交换自身对用户呼叫协议的解析与处理同样能动态下发呼叫的ＱｏＳ和安全信息，下面的Ｍｉｄｄｌｅｂｏｘ（ＮＡＴ／ＦＷ）设备可根据这些信息采取必要的保证措施。由于目前网上大量的ＮＡＴ／ＦＷ设备不支持ＭＩＤ.ＣＯＭ功能，需要对目前网上ＮＡＴ／ＦＷ设备进行修改，同时ＮＧＮ应用初期软交换设备布点数量过少，网络层次较高，因此在一定程度上影响了这种方式在现有网络情况下的应用。

 

 

 

 

 

 

 

 

 

 

 

 

 

 

                徐文卓
UT斯达康(中国)通讯有限公司 宽带传输交换事业部



　　摘 要：软交换系统中，如何给防火墙/NAT后的用户提供完善的多元化服务是很多运营商和设备制造商困惑已久的问题。现在，有不少标准化组织和设备生产厂家针对这个困难提出了自己的解决方案。UT斯达康凭借丰富的通讯行业经验和深厚的技术研发能力，在软交换系统中实现防火墙/NAT穿越问题上提出了完善的解决方案—使用SBC(边界媒体控制器)控制信令和媒体穿越FW/NAT。该方案不仅很好地解决了防火墙/NAT穿越问题，还基于考虑用户、源自信令和下行网络拓扑结构的策略使用，满足网络所需的独特的QoS和安全要求。

　　关键词：FW、NAT、防火墙、穿越、Softswitch、软交换、VoIP、mSwitch



　　1 FW/NAT问题简介

　　随着近年IP网宽带业务的蓬勃发展，基于分组的多媒体通信系统标准H.323、SIP、MGCP广泛运用于视频会议和IP电话中。VoIP业务的应用也带来一个值得关注的问题：绝大部分企业部门从网络安全考虑配置了专用防火墙，但H.323、SIP、MGCP很难通过传统专用防火墙。原因在于，复杂的H.323、SIP、MGCP协议动态分配端口并产生和维护多个UDP数据流。

　　同时由于Internet快速膨胀，IPV4地址空间处于严重耗尽的境况。为解决这个问题，人们设计出了网址转换器(NAT)。然而NAT后的IP语音和视频设备仅有私有IP地址，这些地址在公众网上是不可路由的。

　　这样一来，多媒体通讯中的防火墙和NAT问题严重地制约了IP电话和视频会议的应用。解决这个问题也就成为多业务宽带IP网络至关重要的事情。

　　在这里，我们先简要回顾一下防火墙和NAT设备是如何保护网络安全的和为什么实时多媒体通讯协议是对安全问题的一个挑战。

1.1 网络防火墙和NAT如何工作

1.1.1 防火墙

　　为了网络的安全性，公司一般都安装防火墙，它是一个放于私有网的设备，用来保护网络资源免受外部的恶意破坏。
　　防火墙检查从外部进来的每个数据包的IP地址和目的端口号，它经常如此设置：如果防火墙内的一台计算机A向防火墙外的一台计算机B主动发出请求要数据，防火墙会让外部计算机B的数据包通过，而且当且仅当数据包的目的地址和端口号与防火墙内发起请求的计算机A的地址和端口号相同；如果计算机B发来的数据包仅仅目的地址是防火墙内发起请求的计算机A的地址，而端口号不是计算机A发出请求的那个端口号，防火墙也将会丢弃那个外来的数据包。
　　防火墙总是被配置过滤掉所有不请自到的网络通信，有一个例外是在防火墙内提供Web Server供外部访问。在这种情况下，公司会配置防火墙允许目的地址是Web Server的IP地址且目的端口号为80的数据包通过，这就使得公司外部可以主动向公司的Web Server发起请求得到一些公司放在Server上的数据。

1.1.2 NAT

　　网络地址转换（NAT）是一个Internet标准，置于两网间的边界，其功能是将外网可见的IP地址与内网所用的地址相映射，这样，每一受保护的内网可重用特定范围的IP地址(例如192.168.x.x)，而这些地址是不用于公网的。从外网来的含公网地址信息的数据包先到达NAT，NAT使用预设好的规则 (其组元包含源地址、源端口、目的地址、目的端口、协议) 来修改数据包，然后再转发给内网接受点。对于流出内网的数据包也须经过这样的转换处理。NAT服务有两个主要目的：

　　1． 许多公司使用NAT用作一个网络安全设备，因为它隐藏了内部IP地址，如果黑客不知道特定计算机的IP地址，想要攻击那台计算机是更困难的。

　　2． NAT让一个公司可以使用更多的内部IP地址，因为这些地址仅仅在内部使用，不可能与被别的公司和组织的IP地址产生冲突。

　　2 防火墙和NAT阻碍IP语音和视频通讯

　　基于IP的语音和视频通讯协议，象H.323，要求终端之间使用IP地址和数据端口来建立数据通信通道。因此存在一个两难境地：为了建立数据连接终端必须随时侦听外来的呼叫，而防火墙却通常被配置来阻止任何不请自到的数据包通过。

　　即使网络管理者打开防火墙上的一个端口来接收呼叫建立数据包，例如1720端口，但IP语音和视频通讯协议还要求打开许多别的端口接收呼叫控制信息来建立语音和视频通道，这些端口号事先并不知道，是动态分配的，这也就是说网络管理者为了允许语音和视频通讯将不得不打开防火墙上所有的端口，防火墙也就失去了存在的意义。由于网络安全的原因，很少企业会让他们的网络防火墙如此开放。

　　在IP语音和视频通讯中NAT问题也是常见的问题。一个NAT设备允许一个公司为局域网上设备分配私有的IP地址。不幸的是控制Internet上信息流向的路由设备仅仅能把数据送到具有可路由IP地址（公众IP地址）的设备。
　　NAT后的终端可以向位于相同局域网上的任何别的终端发起呼叫，因为在局域网内的这些IP地址是可路由的，然而他们的IP地址是私有的，对局域网外来说是不可路由的，因此NAT后的终端不能接收局域网外终端的呼叫。
　　即使NAT内的终端可以向NAT外的终端发起呼叫，这仍然存在问题。当进行呼叫时，发起呼叫的终端A的IP地址会包含在数据包负载中，根据H.323协议被呼叫的终端B收到呼叫建立(call setup)数据包后，会从该数据包负载中获取终端A的IP地址，并开始发送音频和视频数据到这个IP地址的终端A。如果这个IP地址是私有的，Internet路由器将丢弃从外部终端发送往内部终端的音频和视频数据包，因为这些数据包正被送往一个不可路由的IP地址。这个呼叫将显示已经连接上，但NAT后的终端A将永远不会收到外部终端B的音频和视频。

　　3 现有VoIP的FW/NAT穿透技术

　　3.1 不使用防火墙/NAT

　　其实解决防火墙和NAT问题的一个最简单的办法就是避免使用它们，对大多数机构来说，这种方法太冒险，网络安全没有保证，而且要得到足够多的可路由的IP地址或许是困难的，昂贵的。对运营商来说也是这样，若不是用FW/NAT来保护核心设备，使核心交换设备直接跟用户端联接，这样无疑是很冒险的做法。

　　3.2 使用PSTN网关

　　如果不太关心在局域网外是否基于IP通信，那么可以使用网关把局域网上的IP语音和视频转换为公共电路交换网上的PSTN语音和视频。使用这样一个网关就不用关心网络防火墙的穿透问题了，因为没有数据包要通过防火墙。这也解决了NAT问题，所有到局域网内终端的呼叫都是可路由的，因为通过网关进入局域网的呼叫都是可路由的。今天大多数IP电话都是通过一个网关和非IP电话来进行通讯的。网关方法是一个局部解决方案，要求所有参与呼叫者在最后一道NAT和防火墙后要有一个相应的网关。

　　3.3 隧道穿透方案

　　一般企业网都不想升级或者改动他们的防火墙和NAT设备的配置，也不想让内外的交互通讯绕过这些设备，采用允许IP语音和视频穿越防火墙和NAT的隧道穿透方案也许是最合适的，目前提供此类解决方案的有美国的Ridgeway公司。
　　隧道穿透解决方案由两个组件构成，Server软件和Client软件。Client放在防火墙内的私有网，它同时具有网守功能和代理功能，私有网内的终端注册到Client上，它和防火墙外的Server创建一个信令和控制通道，可以把所有的注册和呼叫控制信令转发到Server，也把音视频数据转发到Server，在转发时它把内部终端发送的和外部发往终端的数据包的地址和端口号替换为自己的。Server放在防火墙外的公众空间，可以位于服务提供商网络或者位于企业网的DMZ区域，Server扮演网守代理的角色，从Client收到的所有注册和呼叫信令都被Server转发到中心网守。

3.4 STUN

　　STUN (Simple Traversal of UDP Through NATs)是一种由IETF研制的UDP流协议穿透NAT的协议。STUN可以在不改变NAT的情况下，与任何现有NAT共存。在STUN服务器和客户端之间可以有任意多的NAT设备。STUN技术仅针对NAT穿越有效，对防火墙穿越没有帮助，所以，如果在整个通话话路中没有防火墙仅有NAT，STUN将是一种成本低廉的穿越NAT的选择方案。就STUN协议本身而言，对哪种协议并没有要求，不过目前为止的一些成功案例，都是在基于SIP协议的系统中实现的。

　　UT斯达康自行研制的软电话—iSmart，就是采用了STUN技术的SIP终端。在用户侧和网络侧都没有设置防火墙，而仅有NAT转换问题的时候，借助iSmart上的STUN穿越机制，就可以正常使用其服务，STUN支持NAT的多重穿越。

3.5 MidCom

　　Middlebox Communications (MidCom) 是通过在第三方实体和防火墙/NAT之间建立中间盒通讯，使防火墙/NAT设备变为可控的一种新的概念。这种方法是允许第三方成为受防火墙/NAT信任的实体，然后代表防火墙/NAT做出决定，强迫其开放端口传送媒体流或数据流。这些受信任的实体通过“MidCom”定义的新协议与防火墙/NAT进行通信。受信任的第三方实体帮助防火墙/NAT操作，而不必在其中加入智能程序去判断是否允许媒体流通过。这样，防火墙/NAT可以在对应用层内容未知的情况下继续提供安全服务。

3.6 Full Proxy

　　SIP或H.323 proxy可以用于穿越NAT或者FW/NAT，但穿越防火墙时要考虑防火墙是如何配置的。Proxy有点类似于网关，只是在Proxy的两边都是同样的协议，它起不到协议转换的作用。Proxy可以对内外的IP网络都有所了解，并使基于IP的呼叫看起来像两个完全分离的呼叫：其中一个是从内部网络起呼的终端到Proxy，另一个是从Proxy到外部网络上的终呼终端。而这个Proxy则起到把两个呼叫融合在一起的作用，从而解决了NAT的问题。

3.7 ALG(Application Level Gateway)
　　应用层网关（Application layer gateways）是被设计能识别指定IP协议（象H.323、SIP或MGCP）的设备。它不是简单地察看包头信息来决定数据包是否可以通过，而是更深层的分析数据包负载内的数据，也就是应用层的数据。H.323和SIP协议都在负载中放了重要的控制信息，例如语音和视频终端使用哪一个数据端口来接收别的终端的语音和视频数据。通过分析哪一个端口需要打开，防火墙动态地打开那些被应用的端口，而所有别的端口依然安全地保持关闭状态。如果一个NAT被应用来屏蔽内部IP地址，这时ALG就需要一个代理，一些防火墙生产厂商把代理结合到ALG上越过NAT。
　　应用层网关可以是单独的连接于外网和内网之间的设备，也可以是内置于防火墙内的插件。当防火墙发现外网呼叫信号为H.323、SIP或MGCP呼叫信息时，将其转发到ALG(应用层网关)，通过ALG建立起内网伪地址终端与外网终端的通信连接。它主要完成以下几个功能：H.323、SIP或MGCP协议栈的部分功能、H.323、SIP或MGCP代理服务器、网守、IP地址翻译等。


3.8 SBC(Session Border Controller)
　　SBC方案，是迄今为止，对FW/NAT问题解决最完善的方案，也是UT斯达康公司推荐使用的解决方案之一。实施SBC方案，不仅不用对原有网络中的FW/NAT设备做任何改动，而且对原有网络没有任何特殊要求。
　　SBC本身可以被看作支持VoIP的Proxy，它是一种“可识别应用层”的设备，可以识别第五层和第七层的消息，并且还可以处理第五层的众多会话信令协议，修改数据包头的地址，从而实现SBC内外网地址变换。
　　SBC同时还可以用于协助VoIP穿越远端防火墙/NAT设备。它一般放置在网络核心交换设备侧。所有经过SBC的信令和媒体流经过SBC的协调和修改，可以在系统侧和用户侧正确传输。用户侧的NAT/Firewall可以接受这种修改后的信令和媒体流并把他们传送到用户侧内网。这种利用SBC实现的防火墙穿越技术可以称之为“远端防火墙穿越”。
　　SBC可以帮助SIP/MGCP信令穿越已经存在的FW/NAT，而不需要对现有的FW/NAT设备做任何改变。具体来说，对于SIP终端，SIP终端设备会周期性发注册消息到SBC；对于MGCP终端，当收到MGCP设备的第一个注册消息后,SBC会周期性发AUEP消息到终端，强制其再不停的周期性回复200OK消息。这样，由于不停的有信令消息经过防火墙/NAT设备，可以使防火墙/NAT对通过的消息流始终保持一个确定的端口；同时，当注册信息经过SBC，它将记录在防火墙上的第三层的IP地址和端口等信息，并且将此信息与防火墙后面的终端的用户名或电话号码等第五层信息进行绑定记录。这样，当一个信令到来，SBC将通过防火墙上正确的地址和端口发送给被叫方。
　　当呼叫建立后，双向的媒体流端口都是动态建立的。由于媒体流同样也通过SBC，SBC将通过与该媒体流相关的呼叫（第五层消息中的用户名或电话号码）识别出防火墙上的IP地址和端口。因此，SBC可以把相应的媒体流发送到防火墙上的相关IP地址和端口，然后正确的使媒体流到达防火墙后的用户侧。
　　SBC本身可以被看作支持VoIP的防火墙，不过它们不仅仅有此功能。它们还可以修改IP包的包头，使IP包能够顺利通过网络边缘设备（如：FW或NAT）。SBC是一种“可识别应用层”的设备，可以识别第五层和第七层的消息，并且还可以处理第五层的众多会话信令协议，修改数据包头的地址，从而实现“远端防火墙穿越”。同时，SBC可以通过对会话数目的限制，实现应用层防D.O.S.攻击。
　　4 各种语音穿越防火墙技术的优劣比较




　　5 满足市场需求的解决方案
　　作为下一代电信网的核心技术, 基于VoIP技术的软交换技术在实际应用时, 无疑需要很多的IP地址，在IPv6技术大规模应用前，VoIP软交换网络中利用私有IP地址是一个节省有限共有IP资源的现实选择，所以实际布网时常常会大量使用NAT。
　　防火墙技术是建立在现代通信网络技术和信息安全技术基础上的应用性安全技术，越来越多地应用于专用网络与公用网络的互联环境之中，尤以Internet网络为最甚。
　　而作为电信网，互联互通是软交换所必须的，显而易见，使用NAT和防火墙在节省了公有IP资源和保障安全性的同时，也带来了需要解决一些互联互通的问题。
　　UT斯达康公司的防火墙/NAT穿透技术针对电信运营商的具体网络需求，给出了完整解决方案。其中，SBC方案可以在不改变网络中其他设备的情况下，保障防火墙/NAT后面的终端用户能够使用所有mSwitch系统所提供的语音/视频/数据服务。不仅如此，SBC设备还可以为mSwitch核心网络提供安全防护功能。传统的数据防火墙不能达到运营商网络在传送实时媒体通信所需要的动态特点和规模，大多数的边缘路由器在执行一些安全功能，如许可控制和地址转换时，主要都是用于单向而非实时的通信，却并不是针对处理VoIP信号通信的特别要求而设计。SBC设备正好就可以跟传统数据防火墙和边缘路由器起到互补作用。UT斯达康公司提供的应用于软交换系统中的FW/NAT穿越方案，结合了高性能和可靠性的优越特点，为运营商提供更多能为其带来盈利的服务。
　　6 结语与展望

　　从上述各项FW/NAT穿越技术的研究和分析可看出，UT斯达康的软交换系统采用了先进的STUN、SBC等技术，力求为运营商和终端用户提供更为完善的多元化服务。随着科技的进一步发展，FW/NAT穿越技术也必将走向成熟和完善。

摘要：本文主要参考IETF关于NGN网络中会话业务穿透NAT技术的各种草案，介绍了目前业务开展可以使用的几种NAT穿透技术和方案，并对几种技术方案结合网络的实际情况进行了对比和分析，最后给出了华为公司对NGN业务穿透NAT的解决方案建议。

缩略语：

NAT
 Network Address Translation
 网络地址转换
 
FW
 Fire Wall
 防火墙
 
ALG
 Application Layer Gateway
 应用层网关
 
MIDCOM
 Middlebox Communication
 
 
STUN
 Simple Traversal of UDP Through Network Address Translators
 UDP对NAT的简单穿越
 
TURN
 Traversal Using Relay NAT
 通过中继方式穿越NAT
 
Full Proxy
 
 信令代理+媒体中继
 
SoftX
 
 软交换
 
SIP
 Session Initiationl Protocol
 会话初始协议
 
MGCP
 Media Gateway Control Protocol
 网关控制协议
 
H.248
 
 网关控制协议
 
H.323
 
 IP网络的会话协议
 
RTP
 RealTime Transfer Protocol
 实时传输协议
 
RTCP
 RealTime Transfer Control Protocol
 实时传输控制协议
 

1         问题背景

目前NGN网络逐步从试验走向商用，在应用过程中遇到了很多实际问题，特别是NGN用户的接入问题，由于NGN是一个基于分组网承载的网络，接入用户都是通过IP地址来寻址，当前的网络实际情况是，由于IP地址紧缺以及安全等各种原因，网上大量的企业网和驻地网基本上都采用了私有IP地址通过出口的NAT/FW接入公网，而目前NGN网络中在IP 上承载语音和视频的协议，如H323，SIP，MGCP，H248 等，本身具有的特点，在私网用户接入应用中，这些协议的控制通道/媒体通道难以穿越传统的NAT/FW 设备与公网进行互通，或者说目前的NAT/FW大多支持HTTP的数据应用协议穿透，而无法支持这种会话业务的控制与媒体NAT/FW穿透。而NGN网络最大的好处就是能为用户提供丰富的业务，特别是为企业用户提供语音、数据、视频融合的IP Centrex业务，因此上面所提到问题的解决就更加的迫切，成为目前NGN网络业务开展最大的障碍。目前业界的解决方案有如下几种：

（1）NAT/ALG 方式

（2）MIDCOM 方式

（3）STUN 方式

（4）TURN方式

（5）Full Proxy 方式

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

2         技术方案

2.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。
图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.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语音和视频协议（H323、SIP、MGCP/H248）的识别和对NAT/ Firewall 的控制，可以作为NGN 业务穿越NAT/Firewall 的一个解决方案。

从安全性考虑MIDCOM方式可支持控制报文的加密，可支持媒体流的加密，因此安全性比较高。
图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协议。

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

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

STUN的应用模型如下：

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

2.4  TURN方式

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