关于SIP防火墙穿越的汇总

文档发布

---

关于SIP防火墙穿越的汇总


术语和基础知识


防火墙
　　一个防火墙限制私人内网和公众因特网之间的通讯，典型地防火墙就是丢弃那些它认为未经许可的数据包。在数据包穿越一个防火墙时，它检查但是不修改包里的 IP地址和TCP/ UDP 端口信息。


网络地址转换(NAT)
　　当数据包穿过NAT时，NAT不仅检查同时也修改数据的包头信息，并且允许更多的在NAT后的主机分享少数公网IP地址(通常只有1个)。
NAT的类型和说明


NAT通常有2种主要类型
•        Basic Nat
　　一个Basic NAT映射一个内在的私有IP地址到一个公网IP地址，但当数据包穿过NAT时，不更换它的TCP/UDP端口号。Basic Nat通常是只用在一些具备公共IP地址池的NAT上，通过它可以地址绑定，即代表一台内部主机。
•        Network Address/Port Translator (NAPT)
　　但是最通常的，当数据包穿过NAT时，一个NAPT检查并修改它的TCP/UDP端口，那么就可以允许多台内网主机同时共享一个单独的公网IP地址了。
　　关于 NAT 的分类和术语，[NAT-TRAD] 和 [NAT-TERM]中有更多的信息。那些将来分类的NAPT的附加术语在较近的工作[STUN]中被定义。当一个内网的主机经过一个NAT和外部进行TCP或者UDP连接的期间，NAPT分配一个公网IP 住址和端口，以便来自外部终端响应的数据包能被NAPT接收，解释，并转发给内网的主机。这个结果是由 NAPT 建立一个(私有IP地址，私有端口)和(公网IP地址，公网端口)之间的端口绑定实现的。在这个期间NAPT将为绑定的端口执行地址翻译。一个关于P2P应用的问题是，当一个内部主机从一个私有IP，私有端口同时与外网上的多台不同的主机建立多个连接时，NAT是如何运作的。
Cone NAT
　　建立一个端口，把一个(私有IP，私有端口)和(公用IP，公用端口)绑定后，对于以后来自同一私有IP和端口号的应用连接，cone NAT将重复使用这个绑定的端口，只要有一个连接会话，这个绑定端口就会保持激活状态。
　　例如，下面图表中，推想一下客户端A通过一个cone NAT同时建立2个外部会话，从同样的内部网络终端(10.0.0.1:1234)到2个不同的外部服务器，S1和S2。cone NAT只会分配一个公用的终端，155.99.25.11:62000，都会到两个会话，并在地址转换期间确保客户端端口的一致。Basic NAT和防火墙不修改通过的数据包中的端口号，这些类型可以被认为是一种特殊的Cone Nat。

Symmetric NAT
    对称的NAT(Symmetric NAT)，与Cone NAT有明显差别，在所有会话期间中不会保持绑定(私有IP，私有端口)和(公共IP，公共端口)的端口不变。相反，它会为每个新对话重新分配一个新的公共端口。
　　
    举例来说，设想客户A从同样端口上要发起两个外部对话，一个和S1连接，另一个和S2连接。Symmetric NAT可能会为第一个会话分配一个公共的端点 155.99.25.11:62000，而为第二个会话分配一个不同的公共端点155.99.25.11:62001。为了地址转换，NAT可以区分这两个会话传输的目的，因为和这些会话有关的外部端点(就是S1、S2)是不同的，甚至在通过地址转换时丢失了客户端的目的标示。(即丢了S1、S2的IP地址NAT也知道如何区分，我是这么理解的，可能有误)。

　　Cone NAT和Symmetric NAT之间的比较与TCP/UDP之间的比较有些类似。(TCP需要绑定，UDP不需要，Cone NAT需要绑定，Symmetric NAT不需要)

　　按照NAT从已知的公共IP，公共端口接收的数据限制，Cone NAT可以更进一步的进行分类。这种分类通常都是UDP连接的，因为NAT和防火墙会拒绝任何无条件的TCP连接，除非明确地以别的方式配置。
Full Cone NAT
    在给一个新的外部会话建立了一个公共/私有的端口绑定后，一个full cone NAT就可以通过这个公共端口从公网上的任何外部端点接收数据通讯了。Full cone NAT也常常叫做"混合"NAT。

Restricted Cone NAT
    当网络主机发一个或者几个数据包给外部主机后，一个受限的cone NAT(Restricted Cone NAT)才会接受来自这个外部(源)IP地址的数据包。受限的cone NAT有效的运用了防火墙的原理，拒绝没有要求的数据，只接收已知道的外部IP地址传来的数据。(偏开原文，大意就是网络主机需要发一个请求给外部IP地址要求要数据，NAT才会接收这个外部IP地址传来的数据，不然不接收。)

Port-Restricted Cone NAT
    一个端口受限的cone NAT(Port-Restricted Cone NAT)，也是这样，只接收那些网络主机曾经发给一个外部IP地址和端口相匹配的数据。一个Port-Restricted cone NAT可以和对称 NAT一样(symmetric NAT)，保护内部节点不接收未被请求的数据包，但是保持一个私有端口在连接过程中不变。(即不仅请求的IP和外部发来数据的IP是一样的，PORT也要是一样，这样才接收数据。对称NAT也有这个效果，但这种cone NAT保持端口不变，而对称NAT要变端口号的)。由此可见，Symmetric Cone条件最严格，Partial/Restricted Cone次之，Full Cone条件最宽松。
Firewall的基本策略：
    Firewall会判断所有的包是来自内部（Inside）还是外部(Outside)。
    允许所有来自inside的包发出去。
    允许来自Outside的包发进来，但这个连接必须是由Inside发起的。
    禁止所有连接由Outside发起的包发进来。
    firewall会允许几个信任的outside主机，他们可以发起建立连接，并发包进来。
　　所有NAT和Firewall都是对于TCP/IP层以下进行处理和过滤的，而SIP应用的地址是在应用层。所以必须采用其他的途径来解决这一问题。
解决方案
针对不同的NAT类型，可以有不同的解决方案。

1．客户端解决方案
　　客户端解决方案主要包括：STUN(simpletraversalof UDP through NAT)、TURN（Traversal Using Relay NAT）、ICE（Interactive Connectivity Establishment）。
　　STUN是一个轻量级的协议，允许应用程序探测当前在它们与公网之间是否存在NAT、防火墙以及它们的类型，并且具备能够探测到NAT所分配的公网地址和端口的能力。STUN协议中定义了两个实体：STUNClient和STUNServer。STUNClient嵌入在终端系统的应用程序中，比如SIP UA，它向STUN Server发送请求；STUN Server接收请求并产生STUN响应，它是无状态的。SIP终端在建立呼叫之前，通过向处在公网上的STUN服务器发送STUN请求，得到信令和媒体流在NAT上的映射地址，并且将这些地址填写到SIP消息中的Via、Contact字段以及SDP中的媒体流传输地址，替代原有的私有地址。但是，STUN只能工作在全通NAT、地址限制NAT以及端口限制NAT的网络环境下，在对称性NAT的情况下，SIP UA通过STUN请求得到的映射地址是无效的。
　　TURN协议在语法和操作上均与STUN相似，其优点是提供了对对称性NAT的穿越。处在公网的TURN服务器为客户端提供本身的一个外部IP地址和端口，并且负责中转通信双方的媒体流。TURN协议虽然支持所有类型的NAT穿越，但是它需要中转通信双方的媒体流，使得媒体流在传输过程中增加了一跳，不可避免地增加了包的延迟和丢包的可能性，而且完全使用TURN方式需要大量的TURN服务器，在有大量用户时，TURN服务器会成为系统瓶颈，因此我们应该尽量避免使用这种方法。目前，TURN的使用越来越少。
　　ICE目前已经被推认为在非对称性NAT环境下首选的客户端解决方案。ICE本身是一种方法，它利用STUN,TURN等任何符合UNSAF的协议来提供一个通用的解决方案。

2.路由边界解决方案
　　路由边界解决方案主要包括：应用层网关ALG、通用即插即用UPnP、中间盒通信MIDCOM。
　　应用层网关可以设计成能够识别指定IP协议（比如H.323和SIP协议）的防火墙，也被叫做ALGFirewall。它不是简单地察看包头信息来决定数据包是否可以通过，而是更深层的分析数据包负载内的数据，也就是应用层的数据。H.323和SIP协议都在负载中放了重要的控制信息，例如语音和视频终端使用哪一个数据端口来接收对方终端的语音和视频数据。通过分析哪一个端口需要打开，防火墙动态地打开那些被应用的端口，而所有别的端口依然安全地保持关闭状态。如果网络中有多层防火墙和NAT，则在呼叫路径上的每个防火墙都必须被升级以支持ALG功能。
　　UPnP是为了在电脑、智能设备和智能家电之间建立无所不在的网络连接而提出的协议体系。由微软公司发起，在1999年成立了一个开放的产业联盟UPnPForum，制订了一系列标准。其中的IGD(internetgatewaydevice)工作委员会提出了穿透NAT的解决方案，很多NAT设备制造商已经在新产品中支持这个协议。它以Internet 标准和技术(例如，TCP/IP、HTTP和XML)为基础，使这样的设备彼此可自动连接和协同工作，从而使网络(尤其是家庭网络)对更多的人成为可能。
　　MIDCOM是一种新出现的概念，其目的是使用第三方应用程序(包括硬件设备)来控制FireWall/NAT设备动态地决定安全策略，以适应VoIP业务。第三方的应用程序使用MIDCOM定义的协议(或私有协议)控制FireWall/NAT设备，根据“MultiMediaoverIP”的需要动态地打开呼叫信令、媒体流互通的IP地址和端口号，这样Firewall/NAT系统就无须嵌入过多的对“MultiMediaover IP”协议分析、解析的功能，而只需要维持已经存在的安全策略及转发机制，从而实现Firewall/NAT设备的穿透。
3．服务器端解决方案
　　服务器端解决方案主要包括：B2BUA（Back-to-BackUserAgent）、服务器端RTP中继。

　　B2BUA是一个接收请求并充当UAS处理请求的逻辑实体，主要是通过两个UA以Back-to-Back的工作模式控制经过它的呼叫。B2BUA与SIP代理服务器不同，B2BUA可以接收呼叫，并能对其进行修改，以其它形式代表发起呼叫的UA向终端目标发起呼叫，并能充当呼叫双方的媒体协商代表或对其进行监控管理。B2BUA可以对经过它的来自于私网的呼叫进行处理完成NAT的穿越。为适应所有类型NAT的环境，B2BUA也需要做媒体流的中介，因此，对于通信双方来说，呼叫控制信令和媒体流在传输过程中均增加了一跳，随着用户的增加，B2BUA将成为系统瓶颈。

　　服务器端RTP中继的方式相对B2BUA有所改进，它将B2BUA所完成的功能集成到了SIP代理服务器上，由SIP系统中的代理服务器完成信令部分的NAT处理修改，另外增设独立运行的媒体中继服务器来完成媒体流的中继。也就是说，将信令部分的NAT穿越和媒体流部分的NAT穿越分离开来，由不同的功能组件完成。服务器端RTP中继方式相对B2BUA来说，具有更好的可扩展性，但由于在发展期，对于软硬件支持方面来说，不是很成熟。
结论：
    客户端解决方案，虽然无需对现有NAT做任何改动，但对SIPUA的要求较高，需要支持相应的协议，而且到目前为止还无法解决通信双方均处在对称性NAT的情况；

    路由边界的各种解决方案，均需要对NAT设备升级，但目前网络实际已部署了大量的不支持相关特性的NAT设备，因而这种方式可行性较差；

    服务器端解决方案，通过中继RTP数据包来解决所有类型NAT的穿越，缺点就是增加了包的时延和丢包的可能性。

　　具体采用哪种方式解决SIP 防火墙问题需要从以下角度进行综合考虑：
     （1）升级要求：我们只能接受小规模的改造，所以只考虑对服务器端的改造，在极小一部分用户这边考虑一些客户端改造，不考虑更换边缘设备的解决方案；
     （2）网络业务量：我们的网络业务量很大，所以要考虑好大业务量下的问题；
     （3）语音质量：此解决方案是否影响语音质量，增加时延或丢包率；
     （4）运营投资：运营是否随着规模增大，需要做大量投资；
     （5）客户投资：客户是否需要做投资；
     （6）兼容性：此解决方案是否只能在特定环境下生效，是否可以支持各种应用方案，是否可以穿越各种NAT和防火墙；
     （7）扩展性：此方案是否支持大规模应用。
接触到的所有产品情况
    PortaSIP内置B2BUA，可以满足我们的要求；
    Cisco SIP Proxy Server无支持，需要自己架设STUN以及Outbound Proxy服务器，是否能够满足需要调研；
    Nortel需要加Nortel专有的RTP proxy（使用RTP中继方式实现），满足我们的要求；
    华为的解决方案是使用ALG防火墙，满足我们的要求，但需要做一些边缘设备的升级；
    我们自己的试验平台，只能使用STUN或者Outbound Proxy。
    SER，可以在PortaOne网站免费下载PortaOne nathelper RTP proxy来解决这个问题（使用RTP中继方式实现）。

使用SIP部署因特网通信

SIP概念
•        应用层信令协议
•        使用在建立、维护和终止多媒体会话
•        因特网多媒体架构的一部分
•        可以使用UDP、TCP、TLS（transport layer security）、SCTP(scream control transmission protocol)、等等
•        基于HTTP
     类似于基于文本的结构(信令象电子邮件结构)
     使用URI（uniform resource indicators），类似于URL
•        应用包括（但不仅仅限于）以下几点：
     语音、视频、游戏、即时消息、呼叫控制等等


因特网多媒体架构（Internet Multimedia Protocols）

    简单说明一下，SDP协议是Session Description protocol，RTSP是Real Time Streaming Protocol，RTP 是 Real-time Transport Protocol，加上sip是比较重要的


SIP 请求信令和回复信令

    这里说明一下：只有6种信令，invite，ack，options，cancel，bye，register，信令的意义可以参考net130上的相关文章。这里强调的是信令的种类和HTTP的消息很类似，比如这个404错误
SIP联合资源符（Uniform Resource Indicators）
•        和邮件地址一样的：user@domain
•        URI的两种情况：
　　sip：henry@siptest.wcom.com是一个普通sip的URI
　　sips：henry@siptest.wcom.com是一个安全（security）sip的URI
有关协议
SDP - Session Description Protocol，会话描述协议
•         用来描述媒体会话
•        携带在sip消息中，作为消息的内容
•        是一个基于文本的协议
•        在大多数常见媒体类型中，使用RTP/AVP的profiles
•        在RFC 2327中定义
RTP - Real-time Transport Protocol，实时传输协议
•        用来在IP层上传输媒体数据包
•        RTP加上了说明性的数据包头部，它包括：
　　媒体源的名字
　　时间戳
　　编码解码类型
　　序列号
•        由H. Schulzrinne et al在RFC 1889中定义
•        Profiles定义可以在RFC 1890中找到


一个最简化的SIP通信结构

    在图中，有3种或者说3类设备：1、User Agent，用户代理；2、Proxy server，代理服务器；3、DNS服务器和定位服务器。
1) UA，用户代理： 用来发送和接收SIP信令，也是末端设备，包括：
•        SIP电话
•        台式机/笔记本上安装的SIP客户端
•        PDA
•        手机
•        同样，PSTN的网关，也是一种特殊的SIP UA
2) Proxy server，代理服务器： 代表用户代理（UA）设备转发或者代理SIP信令和路由信令。而且很多人都会认为这个服务器功能很简单，这是在理想状况下的模型，但是实际上，建设一个运营系统的时候，SIP proxy往往要和计费系统有一定的联系，这样，就会造成计费系统需要根据实际情况调整SIP proxy的路由状况。类似于这样的功能在实际建设中会有很多，所以后面会附上一个实际的运营软件系统来分析sip和计费是如何共同工作的。参考下面两个服务器决定路由：
•        DNS
•        Location Server
代理服务器有以下几种类型：
•        无国界
•        带国界的传输
•        带国界的呼叫
3) DNS服务器和定位服务器
•        Location Server定位服务器
a) 有Sip用户代理的位置数据库
b) 在代理服务器路由的时候，被代理服务器查询
c) 在用户代理注册的时候，更新数据库
•        DNS服务器
基本就是解析域名到电话号码，到IP地址等等这样的功能


Sip消息头格式和说明
下面是一个典型的sip消息头
INVITE sip：wh@200.201.202.203 SIP/2.0
Via： SIP/2.0/UDP proxy.munich.de：5060;branch=82.1
Via： SIP/2.0/UDP 100.101.102.103：5060
Max-Forwards： 70
To： Heisenberg
From： E. Schroedinger
Call-ID： 105637921@100.101.102.103
CSeq： 1 INVITE
Contact： sip：schroed5244@100.101.102.103
Content-Type： application/sdp
Content-Length： 159
可以看出，这个消息和电子邮件消息头很类似，下面将分别仔细阐述：
1. 开始第一行包括以下信息：
•        方法或者说请求类型：INVITE
•        请求的URI指出了那个设备发出的请求，如此例：
•        sip：wh@200.201.202.203
•        SIP版本号是SIP/2.0
2. 通过Via头信息，我们知道了在sip网络中，这个请求的相关路由信息(第2行到第4行)：
•        上面的Via头信息是在这个路径下的代理服务器插入的
•        下面的Via头信息是由UA插入的
•        Via头信息用来由过来的路而返回的，对方服务器发出的路由响应信息
3. Max-Forwards是一个被代理服务器消耗的计数，每转发一次递减，当计数为0，请求就被丢弃，而且一个483 Too Many Hops响应就被系统发出。常常用来作为路由环路检测。
4. 对话信息Dialog（以前也叫做call leg），包括在第行到第行：
•        对于一个呼叫来说，在To标记、from标记和Call-ID中，所有的请求和回应将会使用相同的Dialog信息
•        Call-ID是一个唯一的标识符，格式是一个伪随机字符串+@+主机名
5. CSeq 命令分割数（Command Sequence Number）
•        在呼叫开始的时候初始化为1
•        在每次并发的请求中递加
•        用来判断一个新的请求是不是重发的
•        常常包含请求的类型（如ack，invite等等）