一种SCTP报文的NAT穿越方法

付晓强， 方旭明， 祝建建

（西南交通大学 信息编码与传输省重点实验室，四川 成都 610031）

0 引言

IP网络的发展使通过信令网关在IP网络中组建IP信令网成为可能，七号信令系统仍将继续在IP信令网中发挥重要作用。IETF的信令传输工作组(SIGTRAN)为了在IP网络上传输 NO.7信令而制定了流控制传输协议(SCTP： RFC 4960[1])，用于IP网络中承载PSTN信令。

SCTP最突出的特点就是多宿主特性，它具有单个SCTP站点支持多个IP地址的能力。多宿主性的优点就是当发生网络故障时，连接的可靠性能够得到更大的保障[2]。在异构移动网络融合的应用中，SCTP也可以利用其支持的多宿主性来提供传输层的解决方案。除此之外，SCTP还具有多流并发，4次握手建立连接，平滑关闭等特性。

在进一步推广应用SCTP的过程中，现有的IP网络中普遍存在的网络地址转换[3]设备无法兼容SCTP报文的转发，使得一些可以应用SCTP协议各类特性的场景不得不与其失之交臂，限制了SCTP协议的推广。现有的IPv4网络在今后很长一段时间内仍将是主流的组网形式，占据大多数的网络应用场景，现有商用的 NAT设备也将大规模存在，这都将滞后SCTP协议在网络通信领域的发展应用。

针对NAT对SCTP产生限制的两个具体问题，分别提出了新的解决方案。

1 NAT丢弃SCTP报文问题

1.1 问题描述

在同一个私有局域网中，收发端应用层程序使用SCTP作为传输层协议进行通信时能够成功传输，然而，当客户端和服务端分布在不同层级的两个网络中，并且它们的通信需要穿越NAT设备时，客户端无法建立起到服务器端的连接。通过抓包分析，发现服务器端无法收到客户端的发送请求（INIT报文）。

根据以上现象描述，分析得知报文在穿越NAT设备时丢失。NAT设备为了完成完整的内网和外网地址转换功能，必须对传输层协议的端口号进行转换。而现有IPv4网络中的大多数 NAT设备对传输层协议的支持仅限于传输控制协议(TCP)和用户数据报协议（UDP），不支持流控制传输协议SCTP。这导致现有商用的NAT设备收到SCTP报文后无法对其进行内网与外网地址间的映射，而直接丢弃，造成了SCTP无法在含有NAT设备的现有IP网络中使用。

1.2 解决方案

利用 NAT对用户数据报协议报文的既有支持，将需要发送的SCTP报文伪装成UDP报文，骗过NAT设备继续向前传递，直至到达接收端，对报文进行还原后再进入 SCTP报文处理流程。该方法具体实施过程如下。

在使用SCTP协议的终端的网络协议栈中部署UDP封装/解封装层。该层位于SCTP协议层和网际协议IP层之间，主要工作是在 SCTP报文前包裹一层UDP隧道头，伪装成UDP包，利用NAT对UDP报文原生的支持来克服NAT对SCTP协议的不兼容性。UDP隧道头的主要包含：一个标准的UDP头，以及一个UDP隧道头的标识符号，用以标明此报文为包含着 SCTP内容的UDP隧道报文，用以与标准的UDP报文相区分。

该流程包括了发送端和接收端对报文进行UDP隧道头的处理的流程。

该流程包括如下步骤：

①发送端的UDP封装层收到传输层发来的SCTP报文后，在SCTP报文头前插入UDP隧道头，它的目标端口域和本地端口域取自于原SCTP报文中的目标端口域和本地端口域；

②发送端的 IP层将此报文看作标准的 UDP报文进行处理；

③接收端收到NAT发送过来的UDP报文后，根据UDP隧道头的标识符号判断此报文是标准 UDP报文还是包裹着UDP隧道头的SCTP报文；

④若是UDP隧道报文，则将报文送入UDP解封装层，该层提取UDP隧道头中的目的端口域和本地端口域的信息，分别填充到标准SCTP头中的对应域中，UDP隧道头将会被删掉，还原成标准的SCTP报文。若是标准的UDP报文，则送入标准的 UDP协议栈进行处理。提出的内容不影响标准TCP/IP协议栈的工作流程。

1.3 实验测试与验证

实验环境采用Ubuntu 9.10 Linux系统，内核版本是2.6.30，内核中应用了LKSCTP工作组的SCTP模块。这里所做的改进都是基于LKSCTP开源代码以及内核中TCP/IP协议栈的。

通过Wireshark软件对网络中的流量进行抓包分析，UDP封装层修改后的连接初始化（INIT）报文从一个私有地址发出，经 NAT转换后到达外网，并可以在内网中正常地接收到回复（INIT_ACK），表明经修改的报文可以成功穿越NAT。另外，在多层次 NAT级联的网络环境进行的实验中，成功验证本方案可以实现多层NAT的连续穿越。

2 多路径NAT端口映射不一致问题

2.1 问题描述

在绝大多数多路径场景中，通信的两端之间的各路径上都会分别遇到各自的NAT网关，此时不同NAT网关内的地址将分别被映射到不同的端口，而对于同一个关联，对端只认同一个端口号，这就造成另一条路径会被放弃，如图1所示。

主机1与主机2之间先通过路径1建立连接,NAT网关1完成了192.168.150.136：5687与12.10.12.100：10372之间的地址转换映射。在另一路径中,同一个端口号5687在NAT网关2的转换后就映射成了不同的端口21983。而在现有的NAT网络中,主机1所无法左右自己内网的端口号将被路径上的NAT映射成什么端口号，这导致了主机2将抛弃来自它所不认识的端口号的报文。此例中,主机1和主机2只能通过先建立的路径1通信,之后来自路径2的报文将被视为不可识别的报文而被丢弃。

图1 多路径场景下网络地址转换穿越

端口号的本意是唯一地标识某网络地址上某应用。但是自从有了 NAT网关的出现，端口号不仅仅表达着应用服务的标识，而且可以作为从外网到达 NAT设备的报文将被投递哪个主机的路由依据，如上例中，当主机 2发送报文到NAT1网关的10372端口时，NAT1查找缓冲区内的端口映射表：主机192.168.3.100的5687端口＜-＞12.10.12.98的10372端口，然后将此报文投递到主机192.168.3.100的5687端口上去。“应用标识”和“投递依据”这两个功能缺一不可。

2.2 解决方案

根据以上分析，为每个数据报文保持两个逻辑上的端口号，“NAT投递端口”和“应用标识端口”。“NAT投递端口”就是标准报文中所应用到的端口号，它在报文的头中，并且可能随着路径不同而映射成不一样的结果。最终呈现在接收端的源网络地址与发送端的网络地址存在唯一的映射。发送端应该将这个“投递端口”与源 IP地址共同记录下来作为这个报文的源地址。这样才能保证接收者的地址列表里存放可达的对端地址。

“应用标识端口”是为了标识当前应用层关联的，所以与“投递端口”不同，它不随着路径的改变而变化。在报文接收函数的端口验证功能中，为检验出一个正确的关联，应该对“应用标识端口”进行验证，而不是标准报文头中的端口字段。由于原有的SCTP协议中没有这个“标识端口”的概念，所以在报文的头部要存放“标识端口”只能借助其他的字段。

2.3 实验测试与验证

通过在Linux下的代码实现，可以克服这个NAT的阻断限制，在多路径都存在NAT的场景下，实现SCTP连接建立和路径切换。

从收发端的抓包分析可以看出数据流的收发，路径添加以及主路径变换的流程。两条路径中的 NAT都对报文分别进行了地址映射，并且接收端可以先后接受两条路径上的数据，不会因端口不同而丢弃新路径上的数据，克服了3.1节描述的多路径NAT映射不一致的问题。

3 结语

关注于解决 SCTP在当前的 IPv4网络实施中所遇到的NAT阻断问题。从修改收发端的SCTP协议的部分功能出发，针对NAT对SCTP报文阻断的两个问题提出了解决方案。这两个方案不需要对IPv4网络中的NAT设备做任何修改就可以实现SCTP报文的NAT穿越，能够帮助SCTP更快地实现在当前网络中的应用。这里所提到的解决方案，在未来具备SCTP兼容性的NAT设备中同样可以适用。

[1] STEWART R. Stream Control Transmission Protocol[S]. New York：IETF,2007.

[2] 沈伊,夏靖波,周汉勋. SCTP协议在雷达情报传输中的应用研究[J].通信技术,2008,41(03)：5-7

[3] EGEVANG K. The IP Network Address Translator (NAT)[S]. New York：IETF, 1994.