一種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協議的推廣?，F有的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端口上去?！皯脴俗R”和“投遞依據”這兩個功能缺一不可。

2.2 解決方案

根據以上分析，為每個數據報文保持兩個邏輯上的端口號，“NAT投遞端口”和“應用標識端口”?！癗AT投遞端口”就是標準報文中所應用到的端口號，它在報文的頭中，并且可能隨著路徑不同而映射成不一樣的結果。最終呈現在接收端的源網絡地址與發送端的網絡地址存在唯一的映射。發送端應該將這個“投遞端口”與源 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.