VoIP防火器穿越
Version 1.0
2008-9-8
一、 基本知识
1, NAT(The IP Network Address Translator,RFC1631)基础
NAT(网络地址转换)最初的目的是为使用内网IP地址的计算机提供通过少数几台具有公网的IP地址的计算机访问外部网络的功能。NAT 负责将某些内网IP地址的计算机向外部网络发出的IP数据包的源IP地址转换为NAT自己的公网的IP地址,目的IP地址不变, 并将IP数据包转发给路由器,最终到达外部的计算机。同时负责将外部的计算机返回的IP数据包的目的IP地址转换为内网的IP地址,源IP地址不变,并最终送达到内网中的计算机。
NAT的分类:
l 静态NAT(Static NAT):内部网络中的每个主机都被永久映射成外部网络中的某个合法的地址;
l 动态地址NAT(Pooled NAT):在外部网络中定义了一系列的合法地址,采用动态分配的方法映射到内部网络;当远程用户联接上之后,动态地址NAT就会分配给他一个IP地址,用户断开时,这个IP地址就会被释放而留待以后使用;局限:同一个公网的IP地址,某个时间只能由一台私有IP地址的计算机使用;
l 网络地址端口转换NAPT(The IP Network Address/Port Translator):将某些内网计算机向外部网络发出的TCP/UDP数据包的源IP地址转换为NAPT自己的公网的IP地址,源端口转为NAPT自己的一个端口(动态端口转换技术称为PAT,NAT与PAT同时使用,合称NAPT);目的IP地址和端口不变,并将IP数据包发给路由器,最终到达外部的计算机;同时负责将外部的计算机返回的IP数据包的目的IP地址转换内网的IP地址,目的端口转为内网计算机的端口,源IP地址和源端口不变,并最终送达到内网中的计算机。
2, NAPT对UDP的处理
一个内网IP:PORT会被NAPT映射成NAPT自己的IP与某个port的组合,NAPT利用虚拟Session维护两个IP:PORT对的对应关系,并利用超时机制来强制维系Session的存在;
二、 问题产生与方案思路
l NAT问题
NAT技术更改消息包的IP地址,但并不相应更改NGN协议如SIP消息包中应用层负荷中的IP地址,这样SIP消息头及SDP中的地址仍然是内网地址,造成SIP消息及RTP流交互失败;
对于当前一些被广泛使用的、也在负荷中携带私网IP地址的协议,如FTP,一般NAT设备在执行IP头中地址转换时,会同时执行负荷中的IP地址转换,这样就不会产生穿越问题;
另外,NAT只在私网设备主动向外发出请求时才会为其分配公网地址端口,否则对外网它是不可见的,外部设备无法呼叫它;
l PAT问题
与NAT问题类似,PAT问题指因载荷中端口产生的问题;
l 防火墙问题
端口封闭是防火墙技术中常用的方式,而一般RTP端口是在通话建立时动态分配的,这样无法通过在防火墙上设置固定的开放端口的方法来解决RTP流的穿越;另外,防火墙还会使用访问规则控制的方法提供安全性,而NGN协议数据包未必能符合这些规则;
由上导出如下的解决思路:
1, 在私网设备发出的数据包应用层载荷中填写正确的公网地址与端口;这要求设备在发起呼叫前获知其在穿越NAT后使用的地址和端口,这类技术包括STUN、UPnP、TURN等;
2, 引入附加设备解决应用层载荷中的私网地址端口问题,包括ALG、MIDCOM、Full Proxy等技术;
3, 使所有设备分布或“虚拟”分布在同一个网络中,以避免NAPT,如使用VPN技术;
4, 综合方案,如RSTP、ICE;
为解决RTP、RTCP被NAT映射到不同端口的问题,一种方案是对SDP进行了属性扩展,在SDP中直接给出RTCP IP:Port;
三、 各种解决方案
a) STUN
Simple Traversal of UDP Through NAT,RFC3489
l 原理:在公网中部署STUN server,私网中的client向其发生各种请求包,通过处理返回来发现NAT、获知NAT类型、NAT为其分配的公网IP:PORT;
l 组成:私网client、公网server、NAT;
l NAPT分类:
n Full cone完全锥形:内网IP:PORT对应某个公网IP:PORT,任意外部主机发往该公网IP:PORT的数据包都被转发;
n Restricted cone受限锥形:只有私网主机曾向某个外部主机发送过消息,外部主机才可以向内部主机发包——通讯必须先由内部主机发起;
n Port Restricted cone:内部主机向某个特点IP:PORT发送过数据包,从该IP:Port来的数据才被转发;
n Symmetric NAT对称NAT:由内部IP:PORT发往某个特定IP:Port的请求,被映射到某个公网IP:Port——内部某个IP:Port,如果它对端的外网IP:Port不同,则被映射到不同的IP:Port;
l STUN Server,接收client请求,返回client的公网IP:Port;尝试使用其他IP:Port向client发送消息,client检验这些消息是否能收到,这样就可以知道NAT类型;
l STUN Client:
n 测试能否从Server获得返回,并从返回中获得自身公网IP:Port;
n 测试能否收到从不同IP:Port来的消息;
n 测试能否收到从同一IP、不同Port来的消息;
l 特点:
n 无需更改现有NAT设备;
n 需要在公网部署server;
n 终端需支持STUN协议;
n 不支持Symmetric NAT的穿越;
n 不能解决NAT对RTP、RTCP端口任意分配,造成RTCP丢失问题;
l http://sourceforge.net/projects/stun/上有一个实现,可以用于检查本地NAT类型;
b) UPnp
Universal Plug and Play,www.upnp.org;
PnP概念的发展,自动配置、自动发现实现网络设备服务发布与信息交换,目标是家庭、企业网络的0设置;
UPnP网关对外提供标准接口,可以动态配置端口映射、动态打开端口、获取外部地址等功能,client可利用这些功能实现穿越;
——不过是将NAT的控制功能吐了出来;
不支持多层私网,存在安全问题;
c) ALG
Application Layer Gateway
在NAT、firewall上增加一个gateway,由其完成报文修改、实现转发等功能;如处理register消息,记录、处理呼叫状态;
可在NAT上部署一个sip proxy,完成消息转发;
缺点:需要更改NAT,gateway与具体应用协议相关;
d) MIDCOM
MiddleBox Communications
l 原理:NAT具备middlebox功能,受middlebox信任的agent是执行应用层网关功能,而逻辑上位于NAT之外的实体,策略决策点PDP负责middlebox授权及有关策略规则服务,agnet向其注册获得授权;agent可物理上依附于NGN实体之上;
l 看起来midcom与ALG差不多,不过是将网关功能从NAT中分离出来,放到NGN实体上,中间再采用比较通用的协议而已——这与UPnp类似;
e) TURN
Traversal Using Relay NAT
l 原理:私网终端通过某种方式获得其对应的公网地址——TURN服务器上的地址;client找到server后,发送分配请求消息,server打开端口,并将端口告知client;client将其填入自己发出的消息中;client的所有信令、RTP都通过TURN server转发;
l 与STUN不同的地方:client将TURN server分配的IP:Port,而非NAT分配的IP:Port填入自己产生的信令消息中;
l TURN server功能上可分成NAT Proxy与RTP Relay;从文献[1]看来,RTP Relay需要先收到一方的RTP包,然后才能向它转发来自另一方的RTP;这似乎与实际不符;
l 特点:支持所有类型NAT、firewall、支持TCP;
f) Proxy
l 对私网中发出的信令、媒体同时做relay,实现出NAT及防火墙穿越;
l Proxy改写信令中的IP:Port,而TURN中该功能由TURN client负责;
l 信令Proxy与媒体Proxy在同一个设备上实现时称为Full Proxy;
l SBC,Session Border Controller:Full proxy的例子;
l SBC的原理:SBC同时记录SIP头中的IP:Port信息及SIP/IP包的真实IP:Port,它使用真实的IP:Port(而非SIP头中的IP:Port数据)发送消息,这些消息就可以到达NAT后的client;同时SIP UA定期向SBC发送注册消息,以保持它在NAT上与公网IP:Port的对应关系不被改变;对于RTP流穿越,SBC采用类似的技术,
g) RSIP
l 私网主机与外界发生联系时发布特定IP地址所采用的一种协议;
l Client向同时连接私网和公网的server(具备边界路由功能,部署在私网边界)请求公网地址,将其填入自己发出的信令消息中;并且client使用公网地址填写自己的IP包,再加上Tunnel header,利用隧道技术传给RSIP server,这样避免了server更改其IP地址,减轻server的单点负担;
l 特点:使用隧道技术,IP头中地址更改也是由client自身完成;
h) ICE
Interactive Connectivity Establishment
l 综合使用各种技术,使其在最合适的情况下运行,具有很强的适用能力;
l 需要终端支持;
l To Be Continued;
四、 一种SIP穿越方案
在公网上部署一个服务程序,私网里的SIP终端可以通过该服务程序相互间建立呼叫;该方案的优势是无需终端的特殊支持,并且适用于各种NAT;
i) 信令穿越
SIP终端通过向公网服务程序的注册来让外界感知自身的存在;server在处理REGISTER消息时,不但记录contact头域中终端的IP:Port信息,同时记录REGISTER消息实际的源IP:Port——这可能是NAT的IP:Port,并使用后者作为自身后续发出的所有SIP消息的目的地,以保证它们能够穿越NAT到达SIP终端;
SIP终端与服务器之间定期发送keep-alive消息,以保证NAT上的消息通道不会被超时清除;消息发送周期一般可定为85秒;对于SIP,可以使用REGISTER或OPTION作为keep-alive消息,建议使用OPTION,因为一般OPTION的处理可以简单一些;对于MGCP等协议,服务程序可以主动下发AUEP消息作为keep-alive;
因为NAT上消息通道一直存在,所以私网里的SIP终端可以作为被叫接收到外部呼叫;
局限:
1,终端发出REGISTER消息所使用的port必须与REGISTER contact中的port一致,即终端必须在它发出REGISTER所用端口等待后续消息;
2,不适应终端Port在通话过程中改变的情况——某些SIP终端会在INVITE的contact中附带别的port作为自己接收后续SIP消息的端口;
3,适用于TCP等SIP所用其他传输协议吗?
j) 媒体穿越
在公网上部署一个media relay,作为两个私网中SIP终端媒体通信的中转站;SIP消息在经过上述服务程序中转时,必须将SDP中的IP:Port更改为该media relay的IP:Port(这与TURN的处理方式不同,TURN中终端更改自己的SDP IP:Port),这样,终端的媒体流就会发给media relay,并被其转发;
看来这种方式,两个终端都必须先将媒体流发给media relay,才能使media relay知道终端RTP的私网IP:Port对应的公网IP:Port,从而成功转发;这样就不能处理INVITE SDP中媒体带recvonly属性的情况;
Re-INVITE消息也必须发给公网服务程序,由其将SDP中的私网IP:Port转化为media relay的IP:Port,也可能会存在recvonly问题;
文献[4]中提及了两种媒体流穿越方案,mediaproxy与rtpproxy,主要介绍了这两种方式在SER中的配置;没有看出其实现原理及两者的差别;To Be Continued;
媒体流穿越也可以利用ICE实现,ICE允许终端在呼叫建立后进行动态媒体协商,并且可以使媒体流直接在两个终端间建立而无需第三方中转;文献[2]中有一点描述。
五、 SBC
Session Border Controller;
SBC的优势:无需升级NAT设备,无需更改现网拓扑结构,SBC自身位置没有特别要求,只需要IP可达即可(一般部署在核心网边缘),也无需终端的特别支持;
Firewall、NAT穿越只是SBC的功能之一,它还可以提供QoS、security、带宽管理等功能;
SBC产品:华为SE2000系列;市面上SBC产品已经很丰富;
六、 一个现网项目SBC私网穿越分析
位于私网里的SIP终端,通过Internet注册到SBC,SBC再将其注册到Softswitch上;该终端能支持呼入和呼出,媒体流信令流都能正常建立;
信令流分析:
1, 终端发出的REGISTER消息,contact头中使用私网IP:Port,注册过期时间是240秒;SIP Phone实际注册周期约120秒;
2, SBC周期性向REGISTER发出端口发送UDP keep-alive包,周期约8秒;这不需要终端回发任何响应;
3, SBC向终端发起的呼叫,INVITE消息中,Request-URI使用终端的私网IP:Port,但是To头域中是终端的公网IP;
4, 在REGISTER contact中的Port不同于终端实际发出REGISTER消息所用的Port时,SBC仍然会向实际的Port发送消息,而不是contact中指定的Port;
媒体流分析:
在终端上抓包看到,既有终端首先向SBC发出的RTP包,也有先收到了SBC发来的RTP,并且早了3秒;不明白SBC是怎样在接收到终端的RTP前就把RTP包发到终端的,To Be Continued;
七、 NAT穿越的一些权威资料
RFC1631: The IP Network Address Translator,1994
RFC1918: Address Allocation for Private Internets,1996
RFC2663: IP Network Address Translator Terminology and Considerations,1999
RFC3022: Traditional IP Network Address Translator,2001
RFC3489: STUN - Simple Traversal of User Datagram Protocol Through Network Address Translators,2003;
IETF,draft-ietf-behave-turn-09,2008.7;
http://en.wikipedia.org/wiki/TURN;
IETF Draft: NAT and Firewall Scenarios and Solutions for SIP,2003
IETF Draft: Considerations for Selection of Techniques for NAT Traversal,2005
ITU-T H.fwreq(H.323系统多媒体穿越总体需求),2005
ITU-T H.Proxy(基于代理的多媒体系统穿越技术),2005
可恶,在ITU网站上下载资料时竟然要求登录!
参考文献
[1] 徐鹏、杨放春,基于软交换的下一代网络解决方案,北京邮电大学出版社,2007.7;
[2] Adrian Georgescu,Best practices for SIP NAT traversal;
[3] Netport networks,NAT Traversal for Multimedia over IP;
[4] Paul Hazlett, Simon Miles, and Greger V. Teigre,SER - Getting Started,ONsip.org;