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中继方式实现）。