多媒体通讯中防火墙和NAT问题的解决

多媒体通讯中防火墙和NAT问题的解决随着近年IP网宽带业务的蓬勃发展，基于分组的多媒体通信系统标准H.323广泛运用于视频会议和IP电话中。VoIP业务的应用也带来一个值得关注的问题：绝大部分企业部门从网络安全考虑配置了专用防火墙，但H.323很难通过传统专用防火墙。原因在于，复杂的H.323协议动态分配端口并产生和维护多个UDP数据流。同时由于Internet快速膨胀，IPv4地址空间处于严重耗尽的境况。为解决这个问题，人们设计出了网址转换器(NAT)。然而NAT后的IP语音和视频设备仅有私有IP地址，这些地址在公众网上是不可路由的。这样一来，多媒体通讯中的防火墙和NAT问题严重地制约了IP电话和视频会议的应用。解决这个问题也就成为多业务宽带IP网络至关重要的事情。在这里，我们先简要回顾一下防火墙和NAT设备是如何保护网络安全的和为什么实时多媒体通讯协议是对安全问题的一个挑战。一．网络防火墙和ＮＡＴ如何工作防火墙为了网络的安全性，公司一般都安装防火墙，它是一个放于私有网的设备，用来保护网络资源免受外部的恶意破坏。防火墙检查从外部进来的每个数据包的IP地址和目的端口号，它经常如此设置：假如防火墙内的一台计算机A向防火墙外的一台计算机B主动发出请求要数据，防火墙会让外部计算机B的数据包通过，而且当且仅当数据包的目的地址和端口号与防火墙内发起请求的计算机A的地址和端口号相同；假如计算机B发来的数据包仅仅目的地址是防火墙内发起请求的计算机A的地址，而端口号不是计算机A发出请求的那个端口号，防火墙也将会丢弃那个外来的数据包。防火墙总是被配置过滤掉所有不请自到的网络通信，有一个例外是在防火墙内提供WebServer供外部访问。在这种情况下，公司会配置防火墙答应目的地址是WebServer的IP地址且目的端口号为80的数据包通过，这就使得公司外部可以主动向公司的WebServer发起请求得到一些公司放在Server上的数据。NAT网络地址转换（NAT）是一个Internet标准，置于两网间的边界，其功能是将外网可见的IP地址与内网所用的地址相映射，这样，每一受保护的内网可重用特定范围的IP地址(例如192.168.x.x)，而这些地址是不用于公网的。从外网来的含公网地址信息的数据包先到达NAT，NAT使用预设好的规则(其组元包含源地址、源端口、目的地址、目的端口、协议)来修改数据包，然后再转发给内网接受点。对于流出内网的数据包也须经过这样的转换处理。NAT服务有两个主要目的：1．许多公司使用NAT用作一个网络安全设备，因为它隐藏了内部IP地址，假如黑客不知道特定计算机的IP地址，想要攻击那台计算机是更困难的。2．NAT让一个公司可以使用更多的内部IP地址，因为这些地址仅仅在内部使用，不可能与被别的公司和组织的IP地址产生冲突。二．防火墙和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收到呼叫建立(callsetup)数据包后，会从该数据包负载中获取终端A的IP地址，并开始发送音频和视频数据到这个IP地址的终端A。假如这个IP地址是私有的，Internet路由器将丢弃从外部终端发送往内部终端的音频和视频数据包，因为这些数据包正被送往一个不可路由的IP地址。这个呼叫将显示已经连接上，但NAT后的终端A将永远不会收到外部终端B的音频和视频。三．穿越防火墙和NAT的方法其实解决防火墙和NAT问题的一个最简单的办法就是避免使用它们，对大多数机构来说，这种方法太冒险，网络安全没有保证，而且要得到足够多的可路由的IP地址或许是困难的，昂贵的。因此大多数希望利用IP进行多媒体通讯的机构将不可避免的面对防火墙或NAT的挑战。事实上，大多数机构都同时使用了防火墙和NAT，因此单单解决其中一个问题还不够。现有的一些解决办法如下：1．使用PSTN网关假如不太关心在局域网外是否基于IP通信，那么可以使用网关把局域网上的IP语音和视频转换为公共电路交换网上的PSTN语音和视频。使用这样一个网关就不用关心网络防火墙的穿透问题了，因为没有数据包要通过防火墙。这也解决了NAT问题，所有到局域网内终端的呼叫都是可路由的，因为通过网关进入局域网的呼叫都是可路由的。今天大多数IP电话都是通过一个网关和非IP电话来进行通讯的。网关方法是一个局部解决方案，要求所有参与呼叫者在最后一道NAT和防火墙后要有一个相应的网关。2．DMZMCU一些机构通过把MCU放在所谓的DMZ区域来解决防火墙和NAT穿越问题。DMZ区域通常位于外部Internet和内部网络防火墙之间，想要对外提供他们自己的Internet服务（例如web服务，ftp服务，email服务和域名服务）的机构一般把这些服务放在DMZ区域，这样可以很好地保护他们的私有网络。放在DMZ区域的MCU被装上两块网卡，这样一块网卡提供访问私有网络的入口，另一块网卡提供访问公网Internet的入口。这个解决方案的一个最大缺点是即使是进行点对点的呼叫也得需要使用MCU，另外假如在呼叫路径上有多个NAT设备，那么在每个NAT设备的位置都需要放置一个MCU。3．H.323代理H.323代理能被用来解决NAT问题或者同时解决NAT和防火墙问题，这取决于代理如何被配置。代理其实是一种非凡类型的网关，但并不是把IP协议转换为别的，在代理两边使用的是相同的协议。代理使终端到终端的呼叫过程看起来像两个分离的呼叫：一个是从私有网上的终端到代理，另一个是从代理到公众网上的终端，代理通过对这个呼叫进行中转解决了NAT问题。H.323代理一般结合标准的网守的功能和RTP/RTCP多媒体流的代理功能。这种解决方案典型应用是在防火墙后放一个H.323代理，代理需要被分配公有IP地址。防火墙被配置答应代理和外部进行多媒体通讯。有时候沿着网络路径在许多位置都应用了NAT设备，这时就需要在每一个使用NAT的地方放置代理。4．应用层网关应用层网关（Applicationlayergateways）是被设计能识别指定IP协议（象H.323和SIP协议）的防火墙，也被叫做ALGFirewall。它不是简单地察看包头信息来决定数据包是否可以通过，而是更深层的分析数据包负载内的数据，也就是应用层的数据。H.323和SIP协议都在负载中放了重要的控制信息，例如语音和视频终端使用哪一个数据端口来接收别的终端的语音和视频数据。通过分析哪一个端口需要打开，防火墙动态地打开那些被应用的端口，而所有别的端口依然安全地保持关闭状态。假如一个NAT被应用来屏蔽内部IP地址，这时ALG就需要一个代理，一些防火墙生产厂商把代理结合到ALG上越过NAT。主要的防火墙厂商象Cisco,Checkpoint,Gauntlet都对他们的防火墙产品提供H.323ALG升级功能，但市场上大多数防火墙还不支持ALG。这种解决方案还有一些缺点：由于要分析数据包负载，这样就加重了防火墙的处理任务，影响网络的运行，成为潜在的网络瓶颈；并且假如这儿有多层防火墙和NAT，则在呼叫路径上的每个防火墙都必须被升级来支持ALG功能；对大多数公司的网络来说防火墙是要害部件，在一些公司增加一个ALG或许是困难的。5．虚拟专用网(VPN)VPN技术是当前在IP网络上提供安全通讯的的方法之一，在同一个VPN网内可以解决防火墙穿越问题；不久的未来，确保网络安全和QoS的VPRN技术将是IP网上进行多媒体通讯的最有潜力的解决方案。在VPN技术中，在UDP和TCP层下的IPSec层被用来提供安全的IP通讯，但由于基于VPN技术的IPSec层使用它自己的连接标识符而不是UDP或TCP端口，而且IPSec上面的层要被加密，这套自己的机制对NAT尤其是NAPT是不可通过的。为了解决NAT穿越问题，最好选择由一个生产商提供的整合防火墙，NAPT和VPN功能的解决方案。另外，虽然VPN方案是很安全的，但它仅仅答应位于同一个VPN内的设备进行通讯，而无法与位于公众网的终端用户进行通讯。6．隧道穿透方案一般企业网都不想升级或者改动他们的防火墙和NAT设备的配置，也不想让内外的交互通讯绕过这些设备，采用答应IP语音和视频穿越防火墙和NAT的隧道穿透方案也许是最合适的，目前提供此类解决方案的有美国的Ridgeway公司。隧道穿透解决方案由两个组件构成，Server软件和Client软件。Client放在防火墙内的私有网，它同时具有网守功能和代理功能，私有网内的终端注册到Client上，它和防火墙外的Server创建一个信令和控制通道，可以把所有的注册和呼叫控制信令转发到Server，也把音视频数据转发到Server，在转发时它把内部终端发送的和外部发往终端的数据包的地址和端口号替换为自己的。Server放在防火墙外的公众空间，可以位于服务提供商网络或者位于企业网的DMZ区域，Server扮演网守代理的角色，从Client收到的所有注册和呼叫信令都被Server转发到中心网守。Server和Client之间的通讯主要通过两个固定的端口来传输数据，这两个端口是2776和2777端口，被IANA机构分配给Ridgeway的系统。当私网内Client启动时：1．它与Server上的2776端口建立一个固定连接用来传送控制和状态信息；2．它监听私网内H.323网守注册和请求信息；当一个终端启动时：1．终端通过Client/Server之间的连接发送注册信息到中心网守；2．Server分配给每一个注册的终端一个唯一的端口号（与Server的IP地址对应）。当一个终端呼叫防火墙外的另一个终端时，所有的数据包都通过Client路由到Server，返回的数据也从Server通过Client路由回到终端。当呼叫被建立后，Client确保所有必需的经过防火墙的音视频通道保持开放，这样音视频数据可以通过这些防火墙上开放的通道进行传输。使用这种方法IP地址信息被很好的屏蔽，因为所有的数据包通过Server来路由转发，每个终端似乎看来在直接地和Server进行通信，而不是和别的终端，这保证了终端的IP地址在网络外不可得到。而且这种方法在大多数情况下不用对防火墙配置进行任何修改。对于那些防火墙设置限制打开向外的端口的情况，治理员可以创建简单的原则来答应从Client到Server上两个固定的端口2776和2777的向外的连接。这个方法不仅仅局限于企业应用，服务提供商可以把Server放在ISP网络的中枢向小企业和用户提供防火墙和NAT穿越服务。不管是企业用户还是服务提供商应用，呼叫终端变得如此简单，仅需下载一个Client软件装在PC上，而且不用关心在呼叫建立的路径上存在多少个防火墙或NAT设备。这个方法最大的缺点是所有经过防火墙的通讯都必须经由Server来进行中转，这会引起潜在的瓶颈，这个经由Client和Server的过程会增加少于5ms的延迟。但是这又是必须的，因为Server是防火墙唯一信任的设备。NAT穿越目录[隐藏]1概述2方法1概述2方法[编辑本段]1概述NAT穿越（NATtraversal）涉及TCP/IP网络中的一个常见问题，即在处于使用了NAT设备的私有TCP/IP网络中的主机之间建立连接的问题。会遇到这个问题的通常是那些客户端网络交互应用程序的开发人员，尤其是在对等网络和VoIP领域中。IPsecVPN客户普遍使用NAT-T来达到使ESP包通过NAT的目的。尽管有许多穿越NAT的技术，但没有一项是完美的，这是因为NAT的行为是非标准化的。这些技术中的大多数都要求有一个公共服务器，而且这个服务器使用的是一个众所周知的、从全球任何地方都能访问得到的IP地址。一些方法仅在建立连接时需要使用这个服务器，而其它的方法则通过这个服务器中继所有的数据——这就引入了带宽开销的问题。2方法一、NAT/ALG方式普通NAT是通过修改UDP或TCP报文头部地址信息实现地址的转换，但对于VOIP应用，在TCP/UDP净载中也需带地址信息，ALG方式是指在私网中的VOIP终端在净载中填写的是其私网地址，此地址信息在通过NAT时被修改为NAT上对外的地址。语音和视频协议（H323、SIP、MGCP/H248）的识别和对NAT/Firewall的控制，同时每增加一种新的应用都将需要对NAT/Firewall进行升级。在安全要求上还需要作一些折衷，因为ALG不能识别加密后的报文内容，所以必须保证报文采用明文传送，这使得报文在公网中传送时有很大的安全隐患。NAT/ALG是支持VOIPNAT穿透的一种最简单的方式，但由于网络实际情况是已部署了大量的不支持此种特性的NAT/FW设备，因此，实际应用中，很难采用这种方式。二、MIDCOM方式与NAT/ALG不同的是，MIDCOM的基本框架是采用可信的第三方（MIDCOMAgent）对Middlebox（NAT/FW）进行控制，VOIP协议的识别不由Middlebox完成，而是由外部的MIDCOMAgent完成，因此VOIP使用的协议对Middlebox是透明的.由于识别应用协议的功能从Middlebox移到外部的MIDCOMAgent上，根据MIDCOM的构，在不需要更改Middlebox基本特性的基础上，通过对MIDCOMAgent的升级就可以支持更多的新业务，这是相对NAT/ALG方式的一个很大的优势。在VOIP实际应用中，Middlebox功能可驻留在NAT/Firewall，通过软交换设备（即MIDCOMAgent）对IP语音和视频协议（H323、SIP、MGCP/H248）的识别和对NAT/Firewall的控制，来完成VOIP应用穿越NAT/Firewall.在安全性上，MIDCOM方式可支持控制报文的加密，可支持媒体流的加密，因此安全性比较高。如果在软交换设备上实现对SIP/H323/MGCP/H248协议的识别，就只需在软交换和NAT/FW设备上增加MIDCOM协议即可，而且以后新的应用业务识别随着软交换的支持而支持，此方案是一种比较有前途的解决方案，但要求现有的NAT/FW设备需升级支持MIDCOM协议，从这一点上来说，对已大量部署的NAT/FW设备来说，也是很困难的，同NAT/ALG方式有相同的问题。三、STUN方式解决穿透NAT问题的另一思路是，私网中的VOIP终端通过某种机制预先得到出口NAT上的对外地址，然后在净载中所填写的地址信息直接填写出口NAT上的对外地址，而不是私网内终端的私有IP地址，这样净载中的内容在经过NAT时就无需被修改了，只需按普通NAT流程转换报文头的IP地址即可，净载中的IP地址信息和报文头地址信息是一致的。STUN协议就是基于此思路来解决应用层地址的转换问题。STUN的全称是SimpleTraversalofUDPThroughNetworkAddressTranslators，即UDP对NAT的简单穿越方式。应用程序（即STUNCLIENT）向NAT外的STUNSERVER通过UDP发送请求STUN消息，STUNSERVER收到请求消息，产生响应消息，响应消息中携带请求消息的源端口，即STUNCLIENT在NAT上对应的外部端口。然后响应消息通过NAT发送给STUNCLIENT，STUNCLIENT通过响应消息体中的内容得知其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的局限性在于需要VOIP终端支持STUNCLIENT的功能，同时STUN并不适合支持TCP连接的穿越，因此不支持H323.另外STUN方式不支持对防火墙的穿越，不支持对称NAT（SymmetricNAT）类型（在安全性要求较高的企业网中，出口NAT通常是这种类型）穿越。四、TURN方式TURN方式解决NAT问题的思路与STUN相似，也是私网中的VOIP终端通过某种机制预先得公网上的服务地址（STUN方式得到的地址为出口NAT上外部地址，TURN方式得到地址为TURNServer上的公网地址），然后在报文净载中所要求的地址信息就直接填写该公网地址。[Page]TURN的全称为TraversalUsingRelayNAT，即通过Relay方式穿越NAT.TURN应用模型通过分配TURNServer的地址和端口作为私网中VOIP终端对外的接受地址和端口，即私网终端发出的报文都要经过TURNServer进行Relay转发，这种方式除了具有STUN方式的优点外，还解决了STUN应用无法穿透对称NAT（SymmetricNAT）以及类似的Firewall设备的缺陷，同时TURN支持基于TCP的应用，如H323协议。此外TURNServer控制分配地址和端口，能分配RTP/RTCP地址对（RTCP端口号为RTP端口号加1）作为私网终端用户的接受地址，避免了STUN方式中出口NAT对RTP/RTCP地址端口号的任意分配，使得客户端无法收到对端发来的RTCP报文（对端发RTCP报文时，目的端口号缺省按RTP端口号加1发送）。TURN的局限性在于需要VOIP终端支持TURNClient，这一点同STUN一样对网络终端有要求。此外，所有报文都必须经过TURNServer转发，增大了包的延迟和丢包的可能性。五、ICE方式[2]应该说ICE是目前在NAT穿透[1]中最常用的方式。ICE（交互式连接建立）-InteractiveConnectivityEstablishment是一种综合性的NAT穿越的技术。交互式连接建立是由IETF的MMUSIC工作组开发出来的一种framework，可整合各种NAT穿透技术，如STUN[2]、TURN（Traversal

UsingRelayNAT）、RSIP（RealmSpecific

IP，特定域IP）等。该framework可以让SIP的客户端利用各种NAT穿透方式打穿远程的防火墙。STUN在SIP中的工作原理及过程

STUN是RFC3489规定的一种NAT穿透方式，它采用辅助的方法探测NAT的IP和端口。毫无疑问的，它对穿越早期的NAT起了巨大的作用，并且还将继续在ANT穿透中占有一席之地。

STUN的探测过程需要有一个公网IP的STUNserver，在NAT后面的UAC必须和此server配合，互相之间发送若干个UDP数据包。UDP包中包含有UAC需要了解的信息，比如NAT外网IP，PORT等等。UAC通过是否得到这个UDP包和包中的数据判断自己的NAT类型。

假设有如下UAC（B），NAT（A），SERVER（C），UAC的IP为IPB，NAT的IP为IPA，SERVER的IP为IPC1、IPC2。请注意，服务器C有两个IP，后面你会理解为什么需要两个IP。

（1）NAT的探测过程：（吃个芒果先，呵呵，老妈给的）

STEP1：B向C的IP1的pot1端口发送一个UDP包。C收到这个包后，会把它收到包的源IP和port写到UDP包中，然后把此包通过IP1和port1发还给B。这个IP和port也就是NAT的外网IP和port（如果你不理解，那么请你去看我的BLOG里面的NAT的原理和分类），也就是说你在STEP1中就得到了NAT的外网IP。

熟悉NAT工作原理的朋友可以知道，C返回给B的这个UDP包B一定收到（如果你不知道，去读下我的其它文章）。如果在你的应用中，向一个STUN服务器发送数据包后，你没有收到STUN的任何回应包，那只有两种可能：1、STUN服务器不存在，或者你弄错了port。2、你的NAT拒绝一切UDP包从外部向内部通过（我们公司的NAT就是）。

当B收到此UDP后，把此UDP中的IP和自己的IP做比较，如果是一样的，就说明自己是在公网，下步NAT将去探测防火墙类型，我不想多说。如果不一样，说明有NAT的存在，系统进行STEP2的操作。

STEP2：B向C的IP1发送一个UDP包，请求C通过另外一个IP2和PORT（不同与SETP1的IP1）向B返回一个UDP数据包（现在知道为什么C要有两个IP了吧，虽然还不理解为什么，呵呵）。

我们来分析一下，如果B收到了这个数据包，那说明什么？说明NAT来着不拒，不对数据包进行任何过滤，这也就是STUN标准中的fullconeNAT。遗憾的是，fullconenat太少了，这也意味着你能收到这个数据包的可能性不大。如果没收到，那么系统进行STEP3的操作。

STEP3：B向C的IP2的port2发送一个数据包，C收到数据包后，把它收到包的源IP和port写到UDP包中，然后通过自己的IP2和port2把此包发还给B。

和step1一样，B肯定能收到这个回应UDP包。此包中的port是我们最关心的数据，下面我们来分析：

如果这个port和step1中的port一样，那么可以肯定这个NAT是个CONENAT，否则是对称NAT。道理很简单：根据对称NAT的规则，当目的地址的IP和port有任何一个改变，那么NAT都会重新分配一个port使用，而在step3中，和step1对应，我们改变了IP和port。因此，如果是对称NAT,那这两个port肯定是不同的。

如果在你的应用中，到此步的时候PORT是不同的，恭喜你，你的STUN已经死了。如果不同，那么只剩下了restrictcone和portrestrictcone。系统用step4探测是是那一种。

STEP4：B向C的IP2的一个端口PD发送一个数据请求包，要求C用IP2和不同于PD的STUN是RFC3489规定的一种NAT穿透方式，它采用辅助的方法探测NAT的IP和端口。毫无疑问的，它对穿越早期的NAT起了巨大的作用，并且还将继续在ANT穿透中占有一席之地。

STUN的探测过程需要有一个公网IP的STUNserver，在NAT后面的UAC必须和此server配合，互相之间发送若干个UDP数据包。UDP包中包含有UAC需要了解的信息，比如NAT外网IP，PORT等等。UAC通过是否得到这个UDP包和包中的数据判断自己的NAT类型。

假设有如下UAC（B），NAT（A），SERVER（C），UAC的IP为IPB，NAT的IP为IPA，SERVER的IP为IPC1、IPC2。请注意，服务器C有两个IP，后面你会理解为什么需要两个IP。

（1）NAT的探测过程：（吃个芒果先，呵呵，老妈给的）

STEP1：B向C的IP1的pot1端口发送一个UDP包。C收到这个包后，会把它收到包的源IP和port写到UDP包中，然后把此包通过IP1和port1发还给B。这个IP和port也就是NAT的外网IP和port（如果你不理解，那么请你去看我的BLOG里面的NAT的原理和分类），也就是说你在STEP1中就得到了NAT的外网IP。

熟悉NAT工作原理的朋友可以知道，C返回给B的这个UDP包B一定收到（如果你不知道，去读下我的其它文章）。如果在你的应用中，向一个STUN服务器发送数据包后，你没有收到STUN的任何回应包，那只有两种可能：1、STUN服务器不存在，或者你弄错了port。2、你的NAT拒绝一切UDP包从外部向内部通过（我们公司的NAT就是）。

当B收到此UDP后，把此UDP中的IP和自己的IP做比较，如果是一样的