防火墙H33协议处理流程及H33ALG应用.docx

防火墙H33协议处理流程及H33ALG应用.docx

《防火墙H33协议处理流程及H33ALG应用.docx》由会员分享，可在线阅读，更多相关《防火墙H33协议处理流程及H33ALG应用.docx（12页珍藏版）》请在冰点文库上搜索。

防火墙H33协议处理流程及H33ALG应用

一．H.323协议简介

H.323协议簇是ITU的一个标准协议栈，它是一个有机的整体，根据功能可以将它分为4类协议，也就是说该协议从系统的总体框架（H.323）、视频编解码（H.263）、音频编解码（G.723.1）、系统控制（H.245）、数据流的复用（H.225）等各方面作了比较详细的规定。

H323系统中的信息流是视频、音频和控制消息的组合。

系统控制的协议包括H.323、H245和H225.0，而Q.931和RTP/RTCP是H225.0的主要组成部分。

整个系统控制由H.245控制信道、H225.0呼叫信令信道和RAS（注册、许可、状态）信道提供。

H.225它主要处理传输路径问题，描述了如何操作网络包上的视频、音频、数据和控制信息使其提供H.323装备会话服务。

H.225主要有两个部分：

呼叫信令和RAS（注册、接入允许和状态）。

H.225详细定义了Q.931信令信息的使用和支持。

在IP网络的TCP端口1720需要创建一个可靠的TCP呼叫控制信道，该端口完成Q.931呼叫控制信息的初始化，从而实现连接、维持和呼叫分离功能。

H.245是H.323多媒体通信体系中的控制信令协议，其主要用于处于通信中的H.323终点或终端间的端到端H.245信息交换。

H.245制定了一个控制信道分段和重新装配的协议层（CCSRL，ControlChannelSegmentationandReassemblyLayer），它可以在易出错环境下保证应用的可靠性。

H.245提供了一种功能交换的功能，它支持两端设备通过协商确定一组通用的功能集。

二．防火墙H.323ALG功能简介

当内部网络的H.323终端穿越防火墙与公网上的H.323终端进行通信时，由于NAT功能只能将传输层的IP及端口进行转换，无法对H.323协议应用层携带的内部数据进行转换，应用层中内部数据直接被转发至公网，后续协议信息处理时会出现问题；而H323ALG则可以实现应用层数据转换，协议数据发至Internet时，将其应用层内部信息转换成公网信息，实现完全隐藏内部终端达到通信正常的目的。

另外，应用防火墙一般只开放特定端口的数据进入内部网络，H.323协议属于多通道协议，控制连接使用端口1720，数据交换使用端口为临时协商，无法事先预知，若无ALG功能，协商出数据交换通道所用端口后，外部网络终端尝试对内部终端数据交换的端口进行连接时，防火墙会对其进行阻断，从而数据传输通道无法建立；开启H.323ALG功能后，会在对应用层转换的IP地址及端口进行转换的同时，将其信息进行记录，使其在外部网络终端尝试对内部终端数据交换的端口进行连接时，防火墙进行协议识别，对后续相关协议报文执行放通策略，从而成功建立传输通道。

三．H.323ALG的典型应用组网

四．一次基本的H323协议连接过程及防火墙处理流程

1.客户端与服务器建立TCP三次握手连接

2.建立TCP连接之后，主叫终端通过H.225协议发送setup消息至被叫终端，表示主叫方希望建立通话（FW开启了H323ALG功能）

1）内网主叫终端抓包报文

2）外网被叫终端抓包报文

由上面2个报文可以明显看出ALG对协议应用层的数据进行了处理。

3.被叫终端返回CallProceeding给主叫终端，表示被叫终端正在处理。

4.被叫终端返回Alerting报文给主叫终端，表示被叫用户已被振铃。

1）内网主叫终端抓包报文

2）外网被叫终端抓包报文

5.被叫终端返回Connect报文给主叫终端，表示被叫用户已摘机并告知被叫终端已开放特定端口来进行下一阶段的协议协商过程。

1）内网主叫终端抓包报文

2）外网被叫终端抓包报文

6.主叫方收到Connect报文后，进入H.245协商阶段，H.245整个协商阶段包括能力交换、主从确定、打开逻辑通道（通道打开之后传输数据）、关闭逻辑通道、断开H.245TCP连接。

1）内网主叫终端抓包报文（TCP三次握手阶段）

2）内网主叫终端抓包报文（打开逻辑通道阶段（能力交换、主从确定阶段省略））

3）外网被叫终端抓包报文

由以上报文可以看出后续数据传输被叫方将使用1503端口来建立连接。

7.通道建立之后，进行数据传输（主叫方将使用多个端口与被叫方的1503端口进行连接来进行视频、音频数据的传输）

8.数据传输完成后（通讯结束）后，由主叫方发起EndSessionCommand与ReleaseComplete消息来释放连接

1）内网主叫方抓包报文

2）外网被叫终端抓包报文

完成上述报文交互之后，断开TCP连接，至此已完成整个H323呼叫流程。

注：

防火墙会话如下（与上述抓包无关联，仅作参考）

五．H323在防火墙中的几种应用场景

1.内部终端向外网终端发起会话，防火墙做SNAT；

由于h323通话setup消息中被叫方只关注应用层中destCallSignalAdress字段信息（检查目的IP是否为自己，确认其是想要和自己通信）与传输层的源IP（主叫方IP），符合以上条件后才会进行后续协议协商；当发起方为内部终端时，目的IP即为被叫终端的IP，不需ALG转换；Netmeeting软件数据传输通道都是由主叫方发起，不存在Untrust到Trust的阻断问题；基于以上两点，在此种场景下，是否开启ALG都对其通讯无影响；但是没有开启ALG功能时，不会对setup消息中sourceCallSignalAdress字段的私网IP进行转换而将其地址暴露在公网中；

2.外网终端向内部终端发起会话，防火墙做DNAT；

当主叫方在外部网络时，若没有开启ALG功能，H323的setup消息中字段信息destCallSignalAdress仍为防火墙目的NAT前的IP地址（没有转换为私网地址），被叫方在收到该消息后发现其不是想和自己进行通讯，会直接返回releaseComplete消息来结束通讯请求；故在此种应用环境下，必须开启ALG功能才能正常通讯。

补充（转）：

H.323之童话故事篇

说了这么多的呼叫流程，大家是不是有些头晕眼花，没有关系，看了下面的小故事，相信大家对于H.323一次呼叫过程就有了比较全面的了解。

请看：

在H.323的王国里有许多成员（各种H.323节点），为了确保这个王国的正常运转，颂布了许多法令（H.323协议簇，其中主要有RAS、Q.931、H.245、TCP/IP、RTP/RTCP、UDP），无论是国王、还是臣民，大家都严格遵守这些法规。

在这里将介绍H.323王国最重要的两个角色国王（GK）、臣民（GW）是如何遵照法规（RAS、Q.931、H.245）通信的。

其中国王与臣民之间的通信遵守RAS协议，臣民与臣民间的通信遵守Q.931、H.245协议。

首先，臣民（GW）应向国王注册。

一个臣民（GW）诞生后，会使用RAS协议去寻找自己的国王（GK），他高声问到：

“谁是我的国王请回答我！

”，这时可能会有一个或者多个国王来响应：

“你是我的臣民（GW），到我这里来注册吧，这是我的地址。

”，当然国王也可以拒绝臣民（GW）的请求：

“你不是我的臣民（GW），别来烦我。

”

如果臣民（GW）幸运地得到了多个国王的青睐，他可以选择一个国王并向他注册。

注册成功后，臣民（GW）就可以享受国王提供的各种服务（如接入控制、带宽管理、地址翻译等功能）。

这时，当臣民（GW）与另一臣民（GW）通信时，不需要知道对方的地址，只需告诉国王想要和谁通信，国王会把对方的地址找来给他。

对于那些没有找到国王的臣民（GW）来说就有点惨了，因为没有国王的帮助，他只能与自己相当熟悉的臣民（GW）通信（即知道对方的地址）。

臣民（GW）向国王注册可以有一个生命期，过了这个有效期，臣民（GW）还要再向国王注册。

下面看看H.323的国王与臣民是如何帮助PSTN王国的臣民通过IP网相互通信的（即IP电话是如何实现的）。

一个PSTN王国的臣民C想通过IP网送给他远方的朋友D一份特别的礼物，他跑去找与自己相熟的H.323王国的臣民A（GW），并把朋友的电话告诉他，请他帮助通过IP网找这个朋友（即一个PSTN用户拨打IP电话，呼入GW）。

臣民A（GW）看不懂这个电话号码，他应该怎么做才能找到那位朋友呢？

向国王（GK）寻求帮助，解析电话号码。

由于在H.323王国里是使用IP协议通信的，所以臣民A（GW）拿到对方的电话号码是没有办法与对方联系的，他只有去寻找与对方相知的臣民B（目的GW）的地址。

于是臣民A（GW）将电话号码发送给他注册的国王（GK），让国王帮助寻找臣民B（目的GW）的地址。

首先国王会对臣民A（GW）的请求进行认证，认证通过后，国王才会去寻找臣民B（目的GW）的地址。

如果国王不知道臣民B（目的GW）的地址（即这个GW未在该GK上注册），他会向其它的国王（GK）询问有谁知道臣民B（目的GW）的地址。

当国王得到臣民B（目的GW）的地址后，就将该地址（呼叫信令传输地址=目的GW的IP地址+端口号）发回给臣民A（GW）。

这样，就可以在这两个臣民（GW）间建立联系（建立呼叫信令信道，开始Q.931协议流程）。

臣民A（GW）告诉臣民B（目的GW）：

“我的朋友C有礼物要送给你的朋友D，他的电话是XXX，他在家吗？

（即被叫用户C是否空闭）”，臣民B（目的GW）赶紧告诉D，别走开，有人要送礼物给你（即目的GW提醒被叫用户，并将该用户空闭态置为忙）。

然后臣民B（目的GW）通知臣民A（GW）“一切搞掂”（即GWB向GWA发送CONNECTION消息后），双方开始讨论采用什么方式将朋友C的礼物送给朋友D（即开始H.245协议流程，进行能力的协商）。

臣民A（GW）说：

“朋友C的礼物是：

播放一首凯利金的《GOINGHOME》萨克斯曲给他听，我可以将这首曲子编辑为CD、VCD两种格式，你可以解读吗？

”臣民B（目的GW）：

“我这里的设备还没有升级呢，不好意思目前我只能解读CD格式的曲子”（这就是H.245中的所谓能力协商，通过协商，获得双方都可以接受的语音编解码类型）。

臣民B（目的GW）通知臣民A（GW）传送曲子所使用的地址（即H.245中的打开RTP/RCTP通道，用于传送媒体流），这样，这份礼物在IP网的传送通道打开了。

这时，朋友C开始通过电话线向远方的朋友D播放乐曲，优美的乐曲经过电话线传送到臣民A（GW）处，臣民A（GW）将曲子压缩成CD的格式（进行语音编码压缩，并打成IP包发送到IP网上），通过IP网传送给臣民B（GW），臣民B（GW）再将编码解读还原成曲子通过电话线传送给朋友D。

（IP电话就是这样拨通了！

！

！

）