几种方式解决SIP穿越NAT总结.docx
- 文档编号:11928024
- 上传时间:2023-04-16
- 格式:DOCX
- 页数:16
- 大小:634.64KB
几种方式解决SIP穿越NAT总结.docx
《几种方式解决SIP穿越NAT总结.docx》由会员分享,可在线阅读,更多相关《几种方式解决SIP穿越NAT总结.docx(16页珍藏版)》请在冰豆网上搜索。
几种方式解决SIP穿越NAT总结
几种方式解决SIP穿越NAT总结
————————————————————————————————作者:
————————————————————————————————日期:
ﻩ
SIP穿越NAT的几种方式
多媒体会话信令协议是在准备建立媒体流传输的代理之间交换信息的协议,媒体流与信令流截然不同,它们所采用的网络通道也不一致。
由于协议自身设计上的原因,使得媒体流无法直接穿透网络地址转换/防火墙(NAT/Firewall)。
因为它们生存期的目标只是为了建立一个在信息中携带IP地址的分组流,这在遇到NAT/Firewall时会带来许多问题。
而且这些协议的目标是通过建立P2P(PeertoPeer)媒体流以减小时延,而协议本身很多方面却与NAT存在兼容性问题,这也是穿透NAT/Firewall的困难所在。
而NAT仍是解决当前公用IP地址紧缺和网络安全问题的最有力手段,所以解决NAT穿越成为首要问题。
以SIP通信为例,呼叫建立和媒体通信的建立是依赖SIP消息首部和SDP消息所描述的地址和端口信息进行的,呼叫双方分别在内网和外网上,内网是通过NAT设备连接到外网,由于NAT设备工作在IP和TCP/UDP层,所以它不对SDP等应用层数据进行NAT变换,因此会造成寻址失败,从而导致呼叫无法正常建立。
另外,VOIP设备的主要通信协议(如SIP和H.323)要求终端之间使用IP地址和端口号来建立端到端的数据侦听外来的呼叫,而防火墙却通常被配置阻止任何不请自到的数据分组通过。
需要网络管理者打开防火墙上的一个端口来接收呼叫建立数据分组,例如5060端口(SIP的通信端口),但IP语音和视频通信协议还要求打开许多别的端口接收呼叫控制信息来建立语音和视频通信,这些端口号事先并不知道,是动态分配的,也就是说网络管理者为了允许语音和视频通信将不得不打开防火墙上所有的端口,防火墙就失去了存在的意义。
所以当前的问题还有需要解决监听端口的问题。
如下图SIP呼叫不成功示意图
分析:
1 d:
211.83.100.100:
23766s:
192.168.1.166:
1010
2d:
211.83.100.100:
23766 s:
211.83.100.166:
9993
3.d:
211.83.100.166:
9993s:
211.83.100.100:
23766
4.d:
192.168.1.166:
1010s:
211.83.100.100:
23766
5.d:
211.83.100.110:
23788 s:
211.83.100.100:
2020
6.d:
211.83.100.100:
3399 s:
211.83.100.110:
23788
7.d:
211.83.100.166:
9993s:
211.83.100.100:
23766
8.d:
192.168.1.166:
1010s:
211.83.100.100:
23766
9.d:
211.83.100.100:
3399s:
211.83.100.110:
23788
10.d:
211.83.100.166:
9993s:
211.83.100.100:
23766
11.d:
192.168.1.166:
1010 s:
211.83.100.100:
23766
12.d:
211.83.100.110:
23788s:
192.168.1.166:
1010
d:
211.83.100.110:
23788s:
211.83.100.166:
9993
13.d:
192.168.1.166 s:
211.83.100.110:
23788A对Binvite 时在SDP中带上了RTP协商的端口和私网IP,B回复200OK时告知RTP时的端口和私网地址,B收到A的RTP包后回复,因为RTP包记录是私网地址,所以RTP包被丢弃。
目前主流的几种解决方式有ALG、STUN、TURN、ICE,我们分别来介绍它们的工作原理及工作流程。
1.ALG
1.1工作原理
ALG是指能识别特定应用层协议(如SIP、H.323或MGCP协议)的防火墙。
它不是简单地查看分组首部信息来解决数据分组是否可以通过,而是更深层地分析负载内容的数据,也就是应用层的数据。
SIP和H.323协议都在负载中放了重要的控制信息。
通过分析哪一个端口需要打开。
防火墙动态的打开那些被应用的端口,而所有别的端口依然安全地保持关闭状态。
ALG是支持VOIP应用最简单的一种方式,但该方案的缺点非常明显:
每增加一种新的应用都将需要对 NAT/Firewall进行升级。
在安全要求上还需要作一些折衷,因为ALG 不能识别加密后的报文内容,所以必须保证报文采用明文传送,这使得报文在公网中传送时有很大的安全隐患。
SIP响应消息用于对请求消息进行响应,指示呼叫或注册的成功或失败状态。
在请求与响应报文中需要进行ALG处理的地址字段类型主要有:
Via、Record_Route、Contact、SDP。
ALG处理流程为如下三个步骤:
首先,ALG根据会话标识的协议类型对报文进行解码,若解码发现报文为不需要做ALG或解码发现为错误字段时退出,解码发现需进行字段转换时进一步处理;其次,ALG查找接口上的NAT配置,根据NAT配置转换报文中的IP地址、端口、call-id等信息并建立关联表,关联表记录了载荷地址的转换关系;最后,ALG调整报文载荷中的长度字段,如sip messageheader的content-length字段标识messagebody的长度,ALG对messagebody中的地址转换后,messagebody长度可能变化,content-length字段值需要置为变化后的值。
1.2工作流程示意图
分析:
1d:
211.83.100.100:
23766s:
192.168.1.166:
1010
2 d:
211.83.100.100:
23766s:
211.83.100.166:
9993
9.d:
211.83.100.166:
9993 s:
211.83.100.100:
23766
10.d:
192.168.1.166:
1010s:
211.83.100.100:
23766
11.d:
211.83.100.110:
23788s:
211.83.100.100:
2020
12.d:
211.83.100.100:
3399s:
211.83.100.110:
23788
13.d:
211.83.100.166:
9993s:
211.83.100.100:
23766
14.d:
192.168.1.166:
1010s:
211.83.100.100:
23766
9.d:
211.83.100.100:
3399s:
211.83.100.110:
23788
10.d:
211.83.100.166:
9993s:
211.83.100.100:
23766
11.d:
192.168.1.166:
1010 s:
211.83.100.100:
23766
12.d:
211.83.100.110:
23788 s:
192.168.1.166:
1010
d:
211.83.100.110:
23788s:
211.83.100.166:
9993
ALGNAT对A发给B的RTP包中的内容进行解码,发现私网地址就转换为公网IP,并做映射建立关联表,最后调整报文载荷中的长度字段。
13.d:
211.83.100.166:
9993s:
211.83.100.110:
23788
A对Binvite时在SDP中带上了RTP协商的端口和私网IP,B回复200OK时告知RTP时的端口和私网地址,B收到A的RTP包是经过ALGNAT修改后的数据包,就知道目的地址发给211.83.100.166:
9993
14.d:
192.168.1.166:
1010s:
211.83.100.166:
9993
2.STUN
2.1工作原理
STUN的全称是SimpleTraversalofUDP Through NAT,即UDP对NAT的简单穿越方式。
是一种网络协议它允许位于NAT(或多重NAT)后的客户端找出自己的公网地址,查出自己位于哪种类型的NAT之后以及NAT为某一个本地端口所绑定的Internet端端口。
这些信息被用来在两个同时处于NAT 路由器之后的主机之间建立UDP通信。
该协议由RFC3489定义。
1)应用程序(即STUNCLIENT)向NAT外的STUNSERVER通过UDP发送请求STUN消息询问自身的转换后地址,
2)STUNSERVER收到请求消息,产生响应消息,响应消息中携带请求消息的源端口,即STUNCLIENT在NAT上对应的外部端口。
响应消息通过NAT发送给STUNCLIENT,
3)STUN CLIENT通过响应消息体中的内容得知其在NAT上对应的外部地址,并且将其填入以后呼叫协议的UDP负载中,告知对端,同时还可以在终端注册时直接注册这个转换后的公有IP地址,这样就解决SIP穿越NAT的通信建立问题以及作为被叫时的问题。
4)本端的接收地址和端口号为NAT外的地址和端口号。
由于通过STUN协议已在NAT上预先建立媒体流的NAT映射表项,故媒体流可顺利穿越NAT。
2.2网络结构图
2.3工作流程示意图
A:
192.168.0.10 ANAT:
192.168.1.1 211.83.100.100
STUNSERVER:
211.83.100.110
B:
192.168.11.11BNAT:
192.168.11.1 211.83.100.120
分析:
1d:
211.83.100.110:
1111 s:
192.168.0.10:
1010
2 d:
211.83.100.110:
1111s:
211.83.100.100:
2020
3 d:
211.83.100.100:
2020s:
211.83.100.100:
2020
4d:
192.168.0.10:
1010s:
211.83.100.100:
2020
5 d:
211.83.100.120:
2222s:
192.168.11.11:
3030
6d:
211.83.100.120:
2222s:
211.83.100.120:
4040
7d:
211.83.100.120:
4040 s:
211.83.100.120:
2222
8d:
192.168.11.11:
3030s:
211.83.100.120:
2222
A与B接收到STUN的响应消息就得到信令和媒体流在NAT上的映射地址,并将这些地址写到SIP消息中的Via,Contact字段以及SDP中的媒体流传送地址,代替原有的私网地址。
如A的SDP带的端口为10000,B的SDP带的端口为20000,A、B相互告知对端它的端口,最后终端注册时直接用这个转换后的公有IP地址注册。
所以端口10000BNAT是打开的,端口20000 ANAT是打开的,所以RTP包可路由。
9d:
211.83.100.120:
4040s:
211.83.100.100:
8888
10d:
211.83.100.100:
8888s:
211.83.100.120:
4040
2.4需要注意
1)NAT/PAT对于地址转换关系是有一定生命期的,某个地址转换后在一段时间内没有被使用将会被清除,当这个业务流再次出现时,将会建立一个新的地址转换关系,这就意味着STUN的询问过程以及终端的注册过程都需要再执行一遍才能保证通信的正确。
解决这个问题一个比较通行的方案是采用某种方式保持NAT/PAT的转换关系,例如在NAT/PAT生命期内重复注册一次,比如NAT/PAT的生命期是3分钟,那么就将注册重复周期设置为2分钟。
2)另外STUNserver并非指一个专用的服务器,而是指一种功能、一个协议,我们可以在softswitch或者任何一个需要此功能的服务器上内置此协议,后面代码也包含一个简单的Server实现。
3)但是在NAT采用对称模式(symmetric NAT)工作时,STUN的方案就会出现问题。
假如我们在softswitch上提供STUNserver功能,终端A通过STUN可以获得NAT为终端A与softswitch之间通信分配的地址A',并将这个地址注册在softswitch上,当一个公网上的终端B呼叫终端A时,A'和B通过softswitch完成呼叫建立过程。
当B试图向A'发送媒体流时,问题就出现了。
因为对称NAT只允许从softswitch发送数据给地址A',从B发送的媒体流将被丢弃。
所以STUN无法应用于工作在对称模式的NAT.
4)STUN协议最大的优点是无需现有NAT/FW设备做任何改动,同时STUN方式可在多个NAT串联的网络环境中使用. STUN的局限性在于STUN并不适合支持TCP连接的穿越,同时STUN方式不支持对对称NAT(SymmetricNAT).
5)解决穿透NAT问题的另一思路是,私网中的VOIP终端通过某种机制预先得到出口NAT上的对外地址,然后在净载中所填写的地址信息直接填写出口NAT上的对外地址,而不是私网内终端的私有IP地址,这样净载中的内容在经过NAT时就无需被修改了,只需按普通NAT流程转换报文头的IP地址即可,净载中的IP地址信息和报文头地址信息是一致的。
STUN协议就是基于此思路来解决应用层地址的转换问题。
6)一旦客户端得知了Internet端的UDP端口,通信就可以开始了。
如果NAT是完全圆锥型的,那么双方中的任何一方都可以发起通信。
如果NAT是受限圆锥型或端口受限圆锥型,双方必须一起开始传输。
7)需要注意的是,要使用STUNRFC中描述的技术并不一定需要使用STUN协议——还可以另外设计一个协议并把相同的功能集成到运行该协议的服务器上。
8)SIP之类的协议是使用UDP分组在Internet上传输音频和/或视频数据的。
不幸的是,由于通信的两个末端往往位于NAT之后,因此用传统的方法是无法建立连接的。
这也就是STUN发挥作用的地方。
9)STUN是一个客户机-服务器协议。
一个VoIP电话或软件包可能会包括一个STUN客户端。
这个客户端会向STUN服务器发送请求,之后,服务器就会向STUN客户端报告NAT路由器的公网IP地址以及NAT为允许传入流量传回内网而开通的端口。
10)以上的响应同时还使得STUN客户端能够确定正在使用的NAT类型——因为不同的NAT类型处理传入的UDP分组的方式是不同的。
四种主要类型中有三种是可以使用的:
完全圆锥型NAT、受限圆锥型NAT和端口受限圆锥型NAT——但大型公司网络中经常采用的对称型NAT(又称为双向NAT)则不能使用。
3.TURN
3.1工作原理
TURN的全称为Traversal UsingRelayNAT,即通过Relay方式穿越NAT,TURN应用模型通过分配TURNServer的地址和端口作为客户端对外的接受地址和端口,即私网用户发出的报文都要经过TURNServer进行Relay转发。
这种方式又称SPAN(SimpleProtocolforAugmentingNATs)方式. TURN方式解决NAT问题的思路与STUN相似,也是基于私网接入用户通过某种机制预先得到其私有地址对应在公网的地址(STUN方式得到的地址为出口NAT上的地址,TURN方式得到地址为TURNServer上的地址),然后在报文负载中所描述的地址信息直接填写该公网地址的方式,实际应用原理也是一样的。
这种方式除了具有STUN方式的优点外,还解决了STUN应用无法穿透对称NAT(Symmetric NAT)以及类似的Firewall设备的缺陷,即无论企业网/驻地网出口为哪种类型的NAT/FW,都可以实现NAT的穿透,同时TURN支持基于TCP的应用,如H323协议。
此外TURN Server控制分配地址和端口,能分配RTP/RTCP地址对(RTCP端口号为RTP端口号加1)作为私网终端用户的接受地址,避免了STUN方式中出口NAT对RTP/RTCP地址端口号的任意分配,使得客户端无法收到对端发来的RTCP报文(对端发RTCP报文时,目的端口号缺省按RTP端口号加1发送)。
TURN的局限性在于需要VOIP终端支持TURN Client,这一点同STUN一样对网络终端有要求。
此外所有报文都必须经过TURNServer转发,增大了包的延迟和丢包的可能性。
3.2网络拓扑图
3.3工作流程示意图
A:
192.168.0.10 A NAT:
192.168.1.1 211.83.100.100
STUN SERVER:
211.83.100.110
B:
192.168.11.11 BNAT:
192.168.11.1 211.83.100.120
分析:
d:
211.83.100.110:
1111s:
192.168.0.10:
1010
2d:
211.83.100.110:
1111 s:
211.83.100.100:
2020
3 d:
211.83.100.100:
2020 s:
211.83.100.100:
2020
4 d:
192.168.0.10:
1010 s:
211.83.100.100:
2020
5 d:
211.83.100.120:
2222s:
192.168.11.11:
3030
6d:
211.83.100.120:
2222s:
211.83.100.110:
4040
7 d:
211.83.100.110:
4040 s:
211.83.100.120:
2222
8d:
192.168.11.11:
3030s:
211.83.100.120:
2222
A与B接收到TURN的响应消息就得到信令和媒体流在NAT上的映射地址,并将这些地址写到SIP消息中的Via,Contact字段以及SDP中的媒体流传送地址,代替原有的私网地址。
如A的SDP带的端口为10000,B的SDP带的端口为20000,A、B相互告知对端它的端口,所以端口10000BNAT是打开的,端口20000 ANAT是打开的,所以RTP包可路由。
9 d:
211.83.100.110:
1111 s:
211.83.100.100:
5556
10 d:
211.83.100.120:
2222s:
211.83.100.110:
1111
d:
192.168.11.11:
3030s:
211.83.100.120:
2222
11d:
211.83.100.110:
4040s:
211.83.100.120:
6555
12d:
211.83.100.100:
5556s:
211.83.100.110:
4040
d:
192.168.0.10:
1010 s:
211.83.100.100:
2020
4.ICE
4.1工作原理
交互式连通建立方式ICE(Interactive ConnectivityEstablishment)并非一种新的协议,它不需要对STUN、TURN或RSIP进行扩展就可适用于各种NAT。
ICE是通过综合运用上面某几种协议,使之在最适合的情况下工作,以弥补单独使用其中任何一种所带来的固有缺陷。
ICE跟STUN和TURN不一样,ICE不是一种协议,而是一个framework,它整合了STUN和TURN。
使用ICE方式穿透NAT,必须映射ICE定义的参数到SIP消息格式中,同时对其SDP属性进行简单扩展—在SDP的Media块中定义一个新的属性“alt”来支持ICE。
它包含一个候选IP地址和端口,SDP的接受端可以用该地址来替换m和c中的地址。
Media块中可能会有多个alt属性,这时每个alt应该包括不重复的IP地址和端口。
对于SIP来说,ICE只需要定义一些SDP(SessionDescriptionProtocol)附加属性即可,对于别的多媒体信令协议也需要制定一些相应的机制来实现。
其思想是:
建立媒体流信道时,发出很多种选择,有本地端口,STUN端口,TURN端口,并给出这些端口的优先级,由被叫方自主选择端口,根据一定的算法和联通性测试,选出最好的端口来通信。
ICE算法流程分为以F几个过程:
(1)收集本地传输地址
会话者从服务器上获得主机上一个物理(或虚拟)接口绑定一个端口的本地传输地址。
(2)启动STUN
与传统的STUN不同,ICE用户名和密码可以通过信令协议进行交换。
(3)确定传输地址的优先级
优先级反映了UA在该地址上接收媒体流的优先级别,取值范围0到1之间,按照被传输媒体流量来确定。
(4)构建初始化信息(InitiateMessage)
初始化消息由一系列媒体流组成,每个媒体流的任意Peer之间实现最人连通可能性的传输地址是由公网L转发服务器(如TURN)提供的地址。
(5)响应处理
连通性检查和执行ICE算法中描述的地址收集过程。
(6)生成接受信息(AcceptMessage)
若接受则发送Accept消息,其构造过程与InitiateMessage类似。
(7)接受信息处理
接受过程需要发起者使用Send命令,由服务器转发至响应者。
(8)附加ICE过程
Initiate或Accept消息交换过程结束后,双方可能仍将继续收集传输地址。
(9)ICE到SIP的映射
4.2网络拓扑图
4.3工作流程示意图
举例:
通信双方同时处于对称式NAT/FW内部,现在SIP终端A要与B进行VoIP通信。
A所在的内部地址是10.0.1.9,外部地址是211.35.29.30;B的内部地址是192.168.1.6,外部地址是202.205.80.130;STUN/TURN服务器的地址是218.65.228.110。
首先A发起请求,进行地址收集,如下图,收集了STUN服务映射的地址M:
211.36.2930:
9988,第二次收集了TURN服务映射的地址M:
218.65.228.110:
8076,第二次的IP和端口都改变了是因为NAT是对称型,重新映射一条路径。
B进行地址收集,和A的过程是一致的。
如下图,收集了STUN服务映射的地址M:
202.205.80.130:
10892,第二次收集了TURN服务映射的地址M:
218.65.228.110:
8078
B的连通性检查,如图,第1步,B对于A的私有地址是不可路由的
第3步,由于目标地址d:
211.35.29.30:
9988被源地址S:
218.65.228.110:
3478所映射,所以B对于A又不可路由,所以B到A的媒体流将发送至218.65.228.110:
8076地址。
A的联通性检查,如图,与B原理一样,A对于B的私有地址和STUN来源地址的连通性检查结果均为失败,而到B的TURN来源地址和到B的peer-derived地址成功(本例中它们都具有相同的优先级0.4)。
相同优先级下我们通常采用peer-derived地址,所以A发送到B的媒体流将使用218.65.228.110:
5556地址。
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 方式 解决 SIP 穿越 NAT 总结
![提示](https://static.bdocx.com/images/bang_tan.gif)