一種SCTP報文的NAT穿越方法

付曉強， 方旭明， 祝建建

（西南交通大學 信息編碼與傳輸省重點實驗室，四川 成都 610031）

0 引言

IP網(wǎng)絡的發(fā)展使通過信令網(wǎng)關在IP網(wǎng)絡中組建IP信令網(wǎng)成為可能，七號信令系統(tǒng)仍將繼續(xù)在IP信令網(wǎng)中發(fā)揮重要作用。IETF的信令傳輸工作組(SIGTRAN)為了在IP網(wǎng)絡上傳輸 NO.7信令而制定了流控制傳輸協(xié)議(SCTP： RFC 4960[1])，用于IP網(wǎng)絡中承載PSTN信令。

SCTP最突出的特點就是多宿主特性，它具有單個SCTP站點支持多個IP地址的能力。多宿主性的優(yōu)點就是當發(fā)生網(wǎng)絡故障時，連接的可靠性能夠得到更大的保障[2]。在異構(gòu)移動網(wǎng)絡融合的應用中，SCTP也可以利用其支持的多宿主性來提供傳輸層的解決方案。除此之外，SCTP還具有多流并發(fā)，4次握手建立連接，平滑關閉等特性。

在進一步推廣應用SCTP的過程中，現(xiàn)有的IP網(wǎng)絡中普遍存在的網(wǎng)絡地址轉(zhuǎn)換[3]設備無法兼容SCTP報文的轉(zhuǎn)發(fā)，使得一些可以應用SCTP協(xié)議各類特性的場景不得不與其失之交臂，限制了SCTP協(xié)議的推廣?，F(xiàn)有的IPv4網(wǎng)絡在今后很長一段時間內(nèi)仍將是主流的組網(wǎng)形式，占據(jù)大多數(shù)的網(wǎng)絡應用場景，現(xiàn)有商用的 NAT設備也將大規(guī)模存在，這都將滯后SCTP協(xié)議在網(wǎng)絡通信領域的發(fā)展應用。

針對NAT對SCTP產(chǎn)生限制的兩個具體問題，分別提出了新的解決方案。

1 NAT丟棄SCTP報文問題

1.1 問題描述

在同一個私有局域網(wǎng)中，收發(fā)端應用層程序使用SCTP作為傳輸層協(xié)議進行通信時能夠成功傳輸，然而，當客戶端和服務端分布在不同層級的兩個網(wǎng)絡中，并且它們的通信需要穿越NAT設備時，客戶端無法建立起到服務器端的連接。通過抓包分析，發(fā)現(xiàn)服務器端無法收到客戶端的發(fā)送請求（INIT報文）。

根據(jù)以上現(xiàn)象描述，分析得知報文在穿越NAT設備時丟失。NAT設備為了完成完整的內(nèi)網(wǎng)和外網(wǎng)地址轉(zhuǎn)換功能，必須對傳輸層協(xié)議的端口號進行轉(zhuǎn)換。而現(xiàn)有IPv4網(wǎng)絡中的大多數(shù) NAT設備對傳輸層協(xié)議的支持僅限于傳輸控制協(xié)議(TCP)和用戶數(shù)據(jù)報協(xié)議（UDP），不支持流控制傳輸協(xié)議SCTP。這導致現(xiàn)有商用的NAT設備收到SCTP報文后無法對其進行內(nèi)網(wǎng)與外網(wǎng)地址間的映射，而直接丟棄，造成了SCTP無法在含有NAT設備的現(xiàn)有IP網(wǎng)絡中使用。

1.2 解決方案

利用 NAT對用戶數(shù)據(jù)報協(xié)議報文的既有支持，將需要發(fā)送的SCTP報文偽裝成UDP報文，騙過NAT設備繼續(xù)向前傳遞，直至到達接收端，對報文進行還原后再進入 SCTP報文處理流程。該方法具體實施過程如下。

在使用SCTP協(xié)議的終端的網(wǎng)絡協(xié)議棧中部署UDP封裝/解封裝層。該層位于SCTP協(xié)議層和網(wǎng)際協(xié)議IP層之間，主要工作是在 SCTP報文前包裹一層UDP隧道頭，偽裝成UDP包，利用NAT對UDP報文原生的支持來克服NAT對SCTP協(xié)議的不兼容性。UDP隧道頭的主要包含：一個標準的UDP頭，以及一個UDP隧道頭的標識符號，用以標明此報文為包含著 SCTP內(nèi)容的UDP隧道報文，用以與標準的UDP報文相區(qū)分。

該流程包括了發(fā)送端和接收端對報文進行UDP隧道頭的處理的流程。

該流程包括如下步驟：

①發(fā)送端的UDP封裝層收到傳輸層發(fā)來的SCTP報文后，在SCTP報文頭前插入UDP隧道頭，它的目標端口域和本地端口域取自于原SCTP報文中的目標端口域和本地端口域；

②發(fā)送端的 IP層將此報文看作標準的 UDP報文進行處理；

③接收端收到NAT發(fā)送過來的UDP報文后，根據(jù)UDP隧道頭的標識符號判斷此報文是標準 UDP報文還是包裹著UDP隧道頭的SCTP報文；

④若是UDP隧道報文，則將報文送入UDP解封裝層，該層提取UDP隧道頭中的目的端口域和本地端口域的信息，分別填充到標準SCTP頭中的對應域中，UDP隧道頭將會被刪掉，還原成標準的SCTP報文。若是標準的UDP報文，則送入標準的 UDP協(xié)議棧進行處理。提出的內(nèi)容不影響標準TCP/IP協(xié)議棧的工作流程。

1.3 實驗測試與驗證

實驗環(huán)境采用Ubuntu 9.10 Linux系統(tǒng)，內(nèi)核版本是2.6.30，內(nèi)核中應用了LKSCTP工作組的SCTP模塊。這里所做的改進都是基于LKSCTP開源代碼以及內(nèi)核中TCP/IP協(xié)議棧的。

通過Wireshark軟件對網(wǎng)絡中的流量進行抓包分析，UDP封裝層修改后的連接初始化（INIT）報文從一個私有地址發(fā)出，經(jīng) NAT轉(zhuǎn)換后到達外網(wǎng)，并可以在內(nèi)網(wǎng)中正常地接收到回復（INIT_ACK），表明經(jīng)修改的報文可以成功穿越NAT。另外，在多層次 NAT級聯(lián)的網(wǎng)絡環(huán)境進行的實驗中，成功驗證本方案可以實現(xiàn)多層NAT的連續(xù)穿越。

2 多路徑NAT端口映射不一致問題

2.1 問題描述

在絕大多數(shù)多路徑場景中，通信的兩端之間的各路徑上都會分別遇到各自的NAT網(wǎng)關，此時不同NAT網(wǎng)關內(nèi)的地址將分別被映射到不同的端口，而對于同一個關聯(lián)，對端只認同一個端口號，這就造成另一條路徑會被放棄，如圖1所示。

主機1與主機2之間先通過路徑1建立連接,NAT網(wǎng)關1完成了192.168.150.136：5687與12.10.12.100：10372之間的地址轉(zhuǎn)換映射。在另一路徑中,同一個端口號5687在NAT網(wǎng)關2的轉(zhuǎn)換后就映射成了不同的端口21983。而在現(xiàn)有的NAT網(wǎng)絡中,主機1所無法左右自己內(nèi)網(wǎng)的端口號將被路徑上的NAT映射成什么端口號，這導致了主機2將拋棄來自它所不認識的端口號的報文。此例中,主機1和主機2只能通過先建立的路徑1通信,之后來自路徑2的報文將被視為不可識別的報文而被丟棄。

圖1 多路徑場景下網(wǎng)絡地址轉(zhuǎn)換穿越

端口號的本意是唯一地標識某網(wǎng)絡地址上某應用。但是自從有了 NAT網(wǎng)關的出現(xiàn)，端口號不僅僅表達著應用服務的標識，而且可以作為從外網(wǎng)到達 NAT設備的報文將被投遞哪個主機的路由依據(jù)，如上例中，當主機 2發(fā)送報文到NAT1網(wǎng)關的10372端口時，NAT1查找緩沖區(qū)內(nèi)的端口映射表：主機192.168.3.100的5687端口＜-＞12.10.12.98的10372端口，然后將此報文投遞到主機192.168.3.100的5687端口上去。“應用標識”和“投遞依據(jù)”這兩個功能缺一不可。

2.2 解決方案

根據(jù)以上分析，為每個數(shù)據(jù)報文保持兩個邏輯上的端口號，“NAT投遞端口”和“應用標識端口”?！癗AT投遞端口”就是標準報文中所應用到的端口號，它在報文的頭中，并且可能隨著路徑不同而映射成不一樣的結(jié)果。最終呈現(xiàn)在接收端的源網(wǎng)絡地址與發(fā)送端的網(wǎng)絡地址存在唯一的映射。發(fā)送端應該將這個“投遞端口”與源 IP地址共同記錄下來作為這個報文的源地址。這樣才能保證接收者的地址列表里存放可達的對端地址。

“應用標識端口”是為了標識當前應用層關聯(lián)的，所以與“投遞端口”不同，它不隨著路徑的改變而變化。在報文接收函數(shù)的端口驗證功能中，為檢驗出一個正確的關聯(lián)，應該對“應用標識端口”進行驗證，而不是標準報文頭中的端口字段。由于原有的SCTP協(xié)議中沒有這個“標識端口”的概念，所以在報文的頭部要存放“標識端口”只能借助其他的字段。

2.3 實驗測試與驗證

通過在Linux下的代碼實現(xiàn)，可以克服這個NAT的阻斷限制，在多路徑都存在NAT的場景下，實現(xiàn)SCTP連接建立和路徑切換。

從收發(fā)端的抓包分析可以看出數(shù)據(jù)流的收發(fā)，路徑添加以及主路徑變換的流程。兩條路徑中的 NAT都對報文分別進行了地址映射，并且接收端可以先后接受兩條路徑上的數(shù)據(jù)，不會因端口不同而丟棄新路徑上的數(shù)據(jù)，克服了3.1節(jié)描述的多路徑NAT映射不一致的問題。

3 結(jié)語

關注于解決 SCTP在當前的 IPv4網(wǎng)絡實施中所遇到的NAT阻斷問題。從修改收發(fā)端的SCTP協(xié)議的部分功能出發(fā)，針對NAT對SCTP報文阻斷的兩個問題提出了解決方案。這兩個方案不需要對IPv4網(wǎng)絡中的NAT設備做任何修改就可以實現(xiàn)SCTP報文的NAT穿越，能夠幫助SCTP更快地實現(xiàn)在當前網(wǎng)絡中的應用。這里所提到的解決方案，在未來具備SCTP兼容性的NAT設備中同樣可以適用。

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

[2] 沈伊,夏靖波,周漢勛. SCTP協(xié)議在雷達情報傳輸中的應用研究[J].通信技術,2008,41(03)：5-7

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