多媒体通信中多种NAT/Firewall穿越技术分析和相关国际标准动态的探讨

多媒体通信中多种NAT/Firewall穿越技术分析和相关国际标准动态的探讨

来源：cmvc                  浏览：1451 次

NAT/Firewall穿越是多媒体通信中普遍存在的一个问题，对于通信有很大的影响。该问题是为了保证正常通信进行所必须解决的问题。本文对于目前存在的多种NAT/Firewall穿越技术进行了论述和分析，重点介绍基于穿越代理的穿越解决方案，和其中的一些典型技术。同时，因为NAT/Firewall穿越问题涉及多种技术方案，因此国际标准领域目前也在加速进行相关的标准化工作，期望能够形成少数几种被业界共同遵循的标准。本文对于相关的国际标准动态也进行了描述和探讨。 一、多媒体通信中的NAT/Firewall穿越问题的普遍性 众所周知，因为IPv4的地址不足，私有地址的采用是必然的，因此就引入了NAT，从安全角度，也有对于Firewall的需要。在实际中两者紧密结合，往往实现在一个物理设备上，因此在提到穿越的时候，都是两者并称的。当然，NAT/Firewall的存在，还有其他原因，比如实现企业网内部拓扑和地址隐藏（Address and topology hidding）。目前的视频、VoIP在很大程度上是为企业网用户服务的，这些业务的用户也主要集中在企业网中。视讯目前作为一种高端业务，其资费还是较高的，通常提供给企业；VoIP可以为企业节省大量通信费用。在发达国家，IPv4地址资源相对丰富，但是企业网内部还是采用私有地址的。因此可以说在多媒体通信中NAT/Firewall穿越问题是普遍存在的，并且这个问题并不会因为采用IPv6就自动消除。 人们非常关注多媒体通信的NAT/Firewall穿越问题，除了该问题普遍存在，还因为有如下原因。 （1） 多媒体通信涉及的协议相当多样和复杂，H.323，SIP，H.248，T.120和其他关于数据应用的事实标准（如Webex、Data Connection等）。对于每种具体协议，可能都需要不同的穿越机制来支持。 （2） 多媒体通信协议，如H.323和SIP等都是应用层协议，普通的NAT如果只能做IP层的地址翻译，无法对IP payload中涉及到的IP地址和端口进行相应的翻译，因此会造成通信失败。 （3） Firewall有多种类型，为了保证安全，对于来自公网和私网的进出信令流和媒体流都有很多约束和限制。如果不能正确规避这些约束条件，则可能无法进行正常的通信。最典型的情况是通信涉及位于多个私网上的终端，而这些私网通过公网相互连接。 二、多媒体通信中的NAT/Firewall穿越相关的一些概念介绍 1．NAT和NAPT NAT（Network Address Translation），网络地址翻译。就是这样一个过程，通过网络地址翻译设备（Network Address Translator）在两个地址域（Realm如公网和私网）之间进行地址的翻译和映射。NAPT（Network Address/Port Translation），在地址翻译的基础上，还需要进行端口的映射。不同的应用协议（如HTTP、RTP等），采用不同的TCP或者UDP端口。在很多情况下，映射不但是地址映射也是端口的映射。 2．NAT的种类 （1）静态NAT 采用静态的地址/端口映射，即公网地址和私网地址之间存在一对一的映射关系。 （2）动态NAT 采用动态的地址/端口映射，这种情况下NAT是可以配置的，根据使用需求和会话流来启发式地决定这种动态映射关系。一个动态映射关系将随着最后一个使用该绑定关系的会话结束而被释放，从而使得全局公网地址能够循环使用，提高资源的利用率。 （3）完全锥形NAT 这是一种形象的说法，来自IETF的定义。完全锥形NAT把所有来自同一个内部私网地址/端口的请求，都映射到同一个外部公网地址/端口。并且，任何外部主机可以通过向映射得到的该外部地址发送数据包，从而发送数据包到该内部主机。 （4）受限锥形NAT 受限锥形NAT把所有来自同一个内部私网地址/端口的请求，都映射到同一个外部公网地址/端口。并且，只有当该内部主机曾经向某个外部主机发送过数据包时，这个外部主机才能向该内部主机发送数据包，即通信只能首先由私网上的终端发起。 （5）端口受限锥形NAT 类似于受限锥形NAT，但是限制更加严格。只有当内部主机曾经向某个外部主机地址上的某个特定端口发送过数据包，这个外部主机地址上的特定端口才能向该内部主机发送数据包，即通信只能首先由私网上的终端发起。 （6）对称NAT 这种NAT的限制是最严格的。所有来自于同一个内部地址/端口并且要发送到某个特定目的地址/端口的请求将被映射到同一个外部地址/端口。如果同一个内部主机从同一端口上发送了一个数据包，只是目的地址/端口不同，那么映射关系也将是不同的。并且，只有曾经收到过来自内部主机数据包的外部主机才能向该内部主机发送数据包。 （7）双向和单向NAT 地址绑定请求可以从公网上发起也可以从私网上发起的NAT叫做双向NAT。地址绑定请求只能从私网上发起，不能从公网上发起的NAT叫做单向NAT。 在实际的多媒体通信中，很多NAT都是单向的。单向NAT造成的问题是，在没有穿越机制帮助情况下，公网上（或者另外一个私网上）的终端无法首先对于私网上的终端发起呼叫，只能由私网上的终端首先向公网上的终端发起呼叫。 三、NAT/Firewall穿越的几种主流技术 1. ALG（Application Level Gateway） 在NAT/Firewall上加入能够对于具体应用协议（如H.323）感知的模块，通过对于具体应用协议的感知，进行针对不同协议的具体NAT/Firewall穿越处理。对于每一种应用协议都需要一个ALG实例（Instance）来支持。H.323需要一个，SIP需要一个，H.248需要一个，如此等等。因此每增加一种新的协议，或者现有协议修改了，都需要一个新的ALG来支持。因此这种机制在实际应用中复杂度高，可扩展性差，受到很大限制。 2. MIDCOM类机制 这是一大类方法，因其中非常典型的一种采用了IETF的MIDCOM（MIDdlebox COMmunication）协议而得名。该类方法的共同特点是需要一个辅助设备（当然可以做在NAT/Firewall上）来支持。该设备对于具体的应用协议是感知的，了解其具体的穿越需求。该设备通过一种通信协议来请求/控制NAT/Firewall，创建特定的地址/端口绑定关系或者打开特定端口允许该应用协议的数据流通过。但是并非所有的NAT/Firewall都能够支持某种类似MIDCOM的请求/控制协议，因此这类技术在实际中的应用也受到一定的局限。 3． 基于隧道的穿越 通过把需要穿越的数据流封装在某种隧道中，从而绕过NAT/Firewall，这是基于隧道穿越的基本思想。可以考虑的隧道协议有L2TP、IPSEC、HTTP、UDP和TCP等。因为经过隧道封装的数据流在通过NAT/Firewall的时候，在通信双方之间，都通过特定的隧道协议的端口，而不是原来数据流协议的端口。那么不论原来的应用协议是什么，只要隧道协议能够正常穿越过NAT/Firewall，就能完成任何应用协议的穿越。这样在很大程度上解决了对于不同应用协议需要开发不同穿越策略的办法。但是隧道机制需要多媒体终端和服务器能够支持隧道，这是一个比较大的限制条件。目前，通过提供集中式的功能实体在私网和公网侧分别提供隧道功能，是可以解决这个问题的。隧道机制也会导致潜在的安全问题，因为被封装的数据是安全检查机制所不可见的，因此会引发一定的安全风险。需要某种机制保证通信终端和服务器的可信性。 4． 基于终端的穿越 这是一个不太合适的名称（借用自ETSI/TISPAN标准组织的文稿），但是对于这类技术目前并没有更好的名称。这类方法利用STUN和TURN或者类似的私有协议，由私网上的终端来获得关于穿越需要的信息并且实现某种协议的穿越：终端可以通过STUN协议发现自己是否位于NAT/Firewall后面，并且发现NAT为它绑定的公网地址/端口。同时通过使用TURN协议来接收来自公网的TCP和UDP数据。对于接收终端位于对称NAT/Firewall后的情况，TURN也能正确穿越。通过“反转”机制，可以把发送终端转变成接收终端，从而使发送终端即便位于对称NAT/Firewall后的情况也能够实现穿越。并且可以不降低对称NAT/Firewall所提供的强安全性。 在实际中，STUN和TURN可以和很多类型的NAT/Firewall配合实现穿越。因此得到了比较广泛的使用。类似的机制经过进一步发展和提高，穿越能力和适用广泛性会更好。目前非常流行的VoIP软件Skype很可能就使用了类似的机制。 需要说明的事，对于STUN和TURN都需要有对应服务器的支持，即分别需要STUN和TURN服务器。 5． 基于穿越代理的穿越 代理本质上是一种“反射”（Reflector）机制。对于数据流的发送端，代理就是接收端；对于数据流的接收端，代理就是发送端。采用代理，就可以把来自多个终端，本来需要发送到另外多个终端/服务器的数据流发送到某个给定的IP地址和相应的知名端口，便于NAT/Firewall进行地址/端口绑定，同时也为NAT/Firewall对于地址/端口的管理提供了很大的方便。代理的使用将穿越问题大大简化。比较适合大规模的公众视讯/VoIP业务。运营商可以在公网上部署一个功能强大的穿越代理，从而为很多私网中的终端/服务器提供穿越的支持。 需要说明的是，以上介绍的多种技术可以结合起来使用，达到更好的穿越效果。比如代理可以和隧道机制结合，也可以和修改协议的方法结合。 6． 基于修改协议的穿越 在终端和服务器上的协议栈进行必要的协议修改，比如H.323协议的修改，也可以支持穿越。修改协议的主要问题是需要现有终端和网络设备比如Gatekeeper等进行改动和升级。 四、理想的穿越方案需要满足的条件 为了选择一种好的多媒体NAT/Firewall穿越方案，首先必须分析需求，明了一种理想的穿越方案应该满足的条件。 （1）能够支持多种不同的网络情况。包括服务器（Gatekeeper，SIP服务器等）和终端都位于私网的情况，都位于公网的情况，终端位于公网、服务器位于私网的情况，以及服务器位于公网、终端位于私网的情况。 （2）能够支持多层地址域之间的信令流和媒体流穿越。 （3）对于现有网络上的设备和组件没有任何为了支持穿越而进行升级改造的要求。 （4）穿越是透明的，即穿越辅助设备的存在对于NAT/Firewall、服务器和终端都是无法感知的。 （5）能够很好地解决和其他穿越机制融合共存的问题。 （6）能够支持多种类的NAT/Firewall的信令穿越和媒体穿越。比如对于完全锥形、受限锥形、端口受限锥形、对称NAT、单向NAT等类型都能够支持。 其中支持对称NAT的要求最高。 （7）不改变呼叫信令流处理过程中的状态机状态。 五、基于穿越代理的NAT/Firewall穿越方案 1.穿越代理类型 穿越代理负责信令流和媒体流的代理。从功能划分角度看，穿越代理可以划分为：信令代理（SPF）和媒体代理（MPF）。 具体来说，信令代理功能如下：终端将通信（注册、呼叫）请求消息发送到信令代理，信令代理首先对于IP包头和消息净荷进行一定的分析和处理，然后转而将消息发给真正的目的服务器或者目的终端。同时，信令代理可以把来自服务器或者其它终端的相应消息转发给该终端。信令代理必须能够感知具体的通信协议，通过信令的分析提取必要的信息来支持穿越。 媒体代理具体功能是在呼叫成功建立之后在终端之间转发媒体流。它能够把目的终端的媒体流接收地址/端口替换成自己的媒体流接收地址/端口，从而能够接收来自发送终端的媒体流。同时媒体代理需要对于媒体流的数据报文进行合法性检查，以决定是否转发以及如何转发媒体流。如果通信中涉及的终端位于不同的地址域，那么其间的媒体流必定要通过媒体代理转发；如果终端位于同一个地址域，但是使用不同的代理，那么其间的媒体流也一定需要要经过媒体代理转发。只有终端位于同一个地址域，并且使用同一个穿越代理的情况下，媒体流才可能不需要经过媒体代理转发。 另外使用媒体代理可以解决所谓“单向通”的问题。因为对于RTP，并不要求媒体发送和接收端口相同，虽然一般情况下可以相同。如果不同，那么终端A首先向终端B发送媒体流（B位于公网或者另外一个私网），B发送的媒体流无法正确到达A的媒体接收端口，而是到达了A的媒体发送端口。因为NAT/Firewall通过学习建立的地址/端口映射是针对A的媒体发送端口的，NAT/Firewall根本不知道A的媒体接收端口。 信令代理和媒体代理可以在一个物理设备上实现，也可以在不同物理设备上实现。在ITU-T目前关于NGN架构研究中，信令代理功能可能放在业务层的会话控制功能实体中，而媒体代理功能可能放在边界网关功能实体中实现。另外，现在的一种趋势是把穿越代理和所谓的会话边界控制设备（SBC）结合成一体。 2. 穿越代理的三种不同网络位置 根据具体的应用场景，穿越代理可以灵活部署在多种网络位置上，包括：穿越代理位于私网、私网和公网边缘、公网的情况。穿越代理位于公网的情况针对的应用场景主要是运营商提供公众视讯/VoIP运营的情况。 3. 穿越服务器和穿越客户端 在很多情况下，仅仅有穿越代理还是不能解决所用的多媒体通信涉及到的复杂问题，比如前面提到的媒体流“单向通”问题，以及单向NAT/Firewall的穿越问题。都需要另外的辅助功能实体的协助。还有，当使用隧道机制或者基于扩展协议来实现穿越的时候，也需要一些辅助的功能实体来支持。一般来说，在公网上，和穿越代理部署在一起的有一个穿越服务器（Traversal Server，xTS）；在私网上，和终端部署在一起的有一个或者多个穿越客户端（Traversal Client，xTC）。穿越服务器和穿越客户端配合起来通过会话创建技术或者类似MIDCOM的技术来协助穿越代理完成穿越。穿越服务器可以和穿越代理结合在同一个物理设备上来实现；穿越客户端也可以直接实现在终端上，但是对于公众运营来说，终端要尽可能便宜和简单，因此可以在私网上部署集中式的穿越客户端。 六、NAT/Firewall穿越问题相关的国际标准领域动态和趋势 1．ITU-T SG 16 因为SG16是ITU-T在多媒体通信方面的主导研究组（Lead Study Group），目前也是多媒体通信中NAT/Firewall穿越问题的主要研究部门。其主要关注的是H.323协议的穿越，H.248，T.120等其他协议的穿越将可能在未来进行研究。在H.323穿越方面，主要有两种方案在竞争成为国际标准。一种方案是中国（多个研究单位和设备厂家合作）提出的H.Proxy，采用基于穿越代理的穿越机制，配合以穿越服务器和穿越客户端等辅助功能实体，穿越代理可以位于私网内、公网内、和私网与公网之间的边缘。具体技术采用隧道、会话创建等。另外一种方案是PolyCom、Tandberg、Radvision等公司联合提出的H.Fantas，该方案主要采用H.323协议扩展的方法支持穿越。目前ITU-T SG16在后期的研究和会议中将决定两种方案的命运。很可能的结果是H.Proxy和H.Fantas同时被接受成为ITU-T标准，因为两者有各自的优点。如果最终两种方案同时成为标准，那么还存在一个在实际应用中竞争的问题。运营商和设备厂商可以自由选择使用其中一种，通过市场竞争来确立真正的主导标准。我们相信，H.Proxy更加适合运营商提供大规模公众视讯/VoIP业务的需要，更加适合复杂多样的网络情况，对于构建可管理、可运营的多媒体业务网络更有帮助。 2．ITU-T Focus Group NGN（FG NGN）和SG 13 ITU-T FG NGN和SG13主要研究NGN环境下的NAT/Firewall穿越问题。穿越问题目前属于“资源和准入控制功能”RACF（Resource and Admission Control Functions）中。其穿越策略控制由RACF（PDF）来实施，RACF控制Transport Stratum中的网关功能实体A-BGF和I-BGF/PGCF来实施具体的NAPT和Firewall穿越。对于这个问题，运营商和设备厂商都比较关注。因为目前仅仅是在制定NGN的架构阶段，对于采取何种穿越机制，FG NGN/SG13的研究还没有深入展开，只是基本确定了应该把穿越这部分功能放在哪个子系统中，仅仅是Lucent在2005年6月份的FG NGN第七次会议上提交的文稿“Clarification and Recommendation of Network Address Hiding and NAT Traversal Mechanisms in FGNGN FRA”中比较全面分析了目前的穿越机制，最后的结论是倾向于基于代理的穿越和基于隧道的穿越。在基于代理的穿越机制中，在NGN架构下，信令代理位于Service Stratum的会话控制功能实体（SCPF）中，穿越代理转而通过RACF（PDF）来控制A-BGF和I-BGF/PGCF上的NAPT和Firewall穿越。媒体代理（这里叫做媒体中继）在A-BGF和I-BGF/PGCF上实现。 3． ETSI/TISPAN和3GPP ETSI/TISPAN是欧洲地区性的标准组织，在NGN标准研究方面具有了越来越大的影响力，几乎和ITU-T并驾齐驱，甚至在某些方面已经超过了ITU-T。从目前的情况看，ETSI/TISPAN内部基本达成一致，很倾向于基于穿越代理的穿越方案。这种思想，以Nokia公司在2005年5月份ETSI/TISPAN第６次全会上的一篇文稿“NAT Traversal for IMS”为代表。该文稿讨论了多种穿越方案，如ALG、基于UE的机制（终端利用STUN和TURN等技术能够自己向外发布经过NAT后的外部地址）、基于代理的机制（信令代理和P-CSCF合一，媒体代理和媒体网关合一）以及基于隧道的机制。会议对于该文稿进行了热烈讨论，最终的结论是倾向于基于代理的穿越机制。 在3GPP中，对于NAT/Firewall穿越的研究目前还基本处于等待起步的状态，但是人们认识到了非GPRS接入网的大量使用将使得穿越问题成为一个很普遍的问题。因此在Nokia等厂家的推动下，3GPP SA2可能即将在其下属的FBI（System Enhancements for Fixed Broadband Access to IMS）项目中开展类似的研究。如果ETSI/TISPAN倾向于使用基于代理的方案，那么3GPP将在很大程度上受到影响，因为这两个组织存在密切的合作关系。 当然，还有其他一些国际或者地区性的标准组织，比如IETF，对于穿越问题也有相当深入的研究，但是限于篇幅，就不在这里介绍了。 七、需要进一步研究的问题 1. 安全问题 对于基于穿越代理的穿越机制，会涉及到一些安全问题（当然别的机制也有各自的安全问题）。在安全方面，需要研究的问题有两大类：（1）因为使用了某些特定的穿越技术（如会话创建），从而进行了报文仿冒，可能会造成一些安全风险，给黑客攻击造成机会，这些安全“漏洞”必须杜绝。可以采用认证鉴权等方式，保证穿越服务器和穿越客户端之间的通信是安全的，不会被黑客仿冒。 （2）因为穿越代理的网络位置比较优越，并且很多情况下可能和SBC（Session Border Controller）结合在一个物理实体上，因此能够了解到会话的状态信息，便于实施某些安全策略，比如通过合法用户名单和基于优先等级的控制，来有效防范DOS（Denial of Service） 攻击，尤其是洪水式分布DOS攻击。 2. QoS问题 因为穿越代理的网络位置比较优越，并且很多情况下可能和SBC（Session Border Controller）结合在一个物理实体上，因此比较适合部署一些QoS策略，特别是针对会话的QoS控制，或者实施某种QoS检测机制。 3. 多种穿越机制融合共存的问题 即使通过标准活动，目前众多的穿越机制统一成了少数几种机制（完全统一到一种是非常困难的），这些机制之间的融合和共存还将会是一个很大的问题。比如目前在ITU-T SG16中，H.Proxy和H.Fantas代表着两种方案，都有可能成为国际标准。因此目前SG16已经在考虑如何使得这两种机制能够融合共存。当然，这个问题的研究范围可能还要大得多，要考虑国际标准和业界事实标准（De Facto Standard）之间的融合共存。 4．Peer-to-peer（P2P）通信机制的穿越问题和穿越管制问题 P2P通信现在非常流行，从早期的文件共享（如BT、eDonkey,eMule等）到VoIP（如目前非常流行的Skype），P2P已经进入了多媒体通信的范畴。目前有很多基于P2P机制的网络流媒体软件，能够比基于传统Client-Server架构的解决方案提供更好的媒体质量和用户体验。因此Skype等软件拥有了巨大的用户群。对于运营商而言，既希望能够利用其机制来给用户提供更好的VoIP、IPTV业务；同时又希望能够对于P2P通信进行必要的管制。P2P的一个突出特点是几乎能够在任何网络条件下成功实现NAT/Firewall的穿越，比如Skype，据分析可能就是采用了一种类似STUN和TURN的私有协议。对于P2P的有效管制，应该包含对于这种几乎无所不能穿越能力的限制。这个领域有很多需要深入研究的问题。这个问题可以说是经典穿越问题的对偶问题（Dual problem），“道高一尺，魔高一丈”，限制和反限制的需要，将不断推动我们去研究相关的问题。 八、结束语 综上所述，多媒体通信中的NAT/Firewall穿越是一个非常普遍的问题，因为涉及的网络情况复杂多样，现有的解决方案和技术众多，因此提出一种通用性好的方案，并且研究相关的技术，同时通过国际国内标准活动，在运营商、设备厂商之间就采用一种或者几种能够被广泛接受的穿越机制达成共识，将是非常必要的。如果成功，将能够在很大程度上解决这个复杂的问题，大大推进多媒体通信的发展，为运营商建设下一代网络并普及多媒体增值业务，创造好的条件。