??? 摘 要: NAT穿越是多媒體傳輸技術(shù)中的一個重要研究課題，STUN解決方案能解決部分NAT的穿越問題，但是還有一定的弊端。在STUN技術(shù)的基礎(chǔ)上，介紹了NAT路由器的識別方法，詳細分析并設(shè)計一種解決NAT路由器穿越問題的算法，并對處于不同NAT路由器環(huán)境下的直接通信給出一種解決方案。既提高了NAT路由器的識別效率，也改善了通信質(zhì)量。
??? 關(guān)鍵詞:? NAT；STUN；直接通信；穿越
?
??? NAT是為了解決網(wǎng)絡(luò)IP地址資源緊缺而出現(xiàn)的一種技術(shù)，由于其具有隱藏內(nèi)網(wǎng)IP的功能，增加了內(nèi)網(wǎng)的網(wǎng)絡(luò)安全性，所以得到了廣泛的應(yīng)用。但是，由于外網(wǎng)主機不能首先發(fā)起對處于NAT后主機的訪問，特別是處于兩個內(nèi)網(wǎng)主機不能直接進行通信，這對一些應(yīng)用程序的部署造成一定的困難。比如說網(wǎng)絡(luò)視頻會議系統(tǒng)和VoIP系統(tǒng)。為了解決這個問題，也就是處于內(nèi)網(wǎng)的主機之間能夠穿越它們之間的NAT建立直接通信，已經(jīng)提出了許多方法，STUN(Simple Traversal of UDP Through NetWork Address Translators)技術(shù)就是其中比較重要的一種解決方法，并得到了廣泛的應(yīng)用。
??? 本文主要是基于STUN協(xié)議，對NAT路由器識別問題進行研究，對NAT類型的判斷方法做了改進，詳細分析并提出一種算法來解決NAT路由器穿越問題，對處于NAT路由器后的主機設(shè)計了直接通信方案。
1 NAT(Network Address Translator) 介紹
1.1 NAT簡述
??? NAT即網(wǎng)絡(luò)地址轉(zhuǎn)換，是一個IETF(Internet Engineering Task Force)標(biāo)準(zhǔn)，它允許一個整體的組織或機構(gòu)用一個公用的IP地址出現(xiàn)在網(wǎng)絡(luò)上，歸根到底，NAT就是把內(nèi)部私有的IP地址翻譯成公網(wǎng)上合法的IP地址的一種技術(shù)。
??? NAT負責(zé)把內(nèi)部主機的數(shù)據(jù)包的源地址(私有IP地址)按照一定的規(guī)則翻譯成合法的、唯一的公網(wǎng)IP地址，源數(shù)據(jù)包的端口轉(zhuǎn)換成NAT的一個端口，目的IP地址和端口不變，最終數(shù)據(jù)包經(jīng)過路由器發(fā)送到目的地址。同時，NAT也負責(zé)把外部主機返回的數(shù)據(jù)包的目的地址和端口轉(zhuǎn)換成內(nèi)網(wǎng)的私有地址和端口，源地址和端口不變。這種變換的本質(zhì)是在NAT內(nèi)部維護著一張轉(zhuǎn)換表，負責(zé)由內(nèi)到外和由外到內(nèi)的IP地址與端口的轉(zhuǎn)換。
??? 對于視頻會議和VoIP軟件來說，對位于不同NAT內(nèi)部的主機通信需要靠服務(wù)器來轉(zhuǎn)發(fā)完成，這樣就會增加服務(wù)器的負擔(dān)。為了解決這種問題，要盡量使位于不同NAT內(nèi)部的主機建立直接通信，其中，最重要的一點就是要判斷出NAT的類型，然后才能根據(jù)NAT的類型，設(shè)計出直接通信方案。
1.2 NAT類型
??? 根據(jù)STUN協(xié)議，把NAT分為以下幾種類型
??? (1) 完全錐形(Full Cone)NAT：所有內(nèi)部IP地址和端口的請求都被映射到相同的外部地址和端口，任何外部主機都可以通過映射的外部地址向內(nèi)部主機發(fā)送數(shù)據(jù)包。
?? ?(2) 受限錐形(Restricted Cone)NAT：所有從相同內(nèi)部IP和端口的請求都被映射為相同的外部地址和端口，與Full Cone不同的是，必須是內(nèi)部主機已經(jīng)向外部主機發(fā)送過數(shù)據(jù)包，外部主機才能通過IP地址向內(nèi)部主機發(fā)送數(shù)據(jù)包。
??? (3) 端口受限錐形(Port Restricted Cone)NAT：和Restricted Cone類似，但是包括對端口的限制，外部主機(IP地址X，端口P)向內(nèi)部主機發(fā)送數(shù)據(jù)包當(dāng)且僅當(dāng)滿足內(nèi)部主機先前已經(jīng)向(X,P)發(fā)送過數(shù)據(jù)包。
??? (4) 對稱(Symmetric)NAT：限制最嚴(yán)格的NAT，所有來自同一內(nèi)部IP地址和端口發(fā)送到某一特定目的IP地址和端口的請求，都會映射為同一個目的地址和端口。若同一臺內(nèi)部主機從同一個端口發(fā)送數(shù)據(jù)包，只是目的地址和端口不同，那么映射關(guān)系也是不同的。并且，只有曾經(jīng)收到過內(nèi)部主機請求的外部主機才能向內(nèi)部主機發(fā)送數(shù)據(jù)包。
2 NAT路由器
2.1 STUN技術(shù)簡介
??? STUN技術(shù)能使客戶端應(yīng)用程序發(fā)現(xiàn)它和公共互聯(lián)網(wǎng)之間存在的NAT和防火墻及其類型，還能獲得路由器分配給它的公網(wǎng)IP地址和端口號。它主要由三部分組成：STUN客戶端、STUN服務(wù)器端、NAT路由器。如圖1所示。
?
??? STUN客戶端通過向服務(wù)器端發(fā)送不同的消息類型，根據(jù)服務(wù)器端不同的響應(yīng)來判斷客戶端IP地址類型，如果是內(nèi)部網(wǎng)絡(luò)地址，還可以判斷所經(jīng)過的NAT類型，同時可以得到路由器分配給它的公網(wǎng)IP地址和端口(映射過的)。
??? STUN服務(wù)器端根據(jù)客戶端不同的動作(客戶端發(fā)送不同的消息類型)作出不同的處理，可以獲得客戶端的源地址與端口(映射過得公網(wǎng)IP地址和端口)并返回給客戶端。根據(jù)客戶端發(fā)送的消息類型，按照要求用不同的IP地址和端口返回給客戶端。
2.2 NAT路由器類型判斷
2.2.1 測試方案設(shè)計
??? 根據(jù)RFC3489提供的解決方案，NAT類型的判斷由客戶端來完成。設(shè)計了下面兩種測試方法。
??? 測試1：客戶端(IP:A，PORT:A)向服務(wù)器(IP:B，PORT:B)發(fā)送消息，服務(wù)器響應(yīng)客戶端的請求，做出動作，服務(wù)器(IP:B，PORT:B)發(fā)送Response給客戶端(IP:A，PORT:A)。
??? 測試2：客戶端(IP:A，PORT:A)向服務(wù)器(IP:B，PORT:B)發(fā)送消息，服務(wù)器(IP:B，PORT:C)發(fā)送Response給客戶端(IP:A，PORT:A)。
2.2.2 NAT 路由器類型判斷
??? 由圖2可以得到客戶端所處的網(wǎng)絡(luò)環(huán)境有以下幾種：
??? · 阻塞UDP 的防火墻；
??? ·公開的互聯(lián)網(wǎng)上(有公網(wǎng)IP)；
??? ·對稱型UDP防火墻；
??? ·完全錐形或受限錐形NAT；
??? ·對稱NAT；
??? ·端口受限錐形NAT；
??? ·受限錐形。
?
2.3 NAT路由器類型判斷改進
??? RFC3489給出了判斷NAT路由器類型的解決方案，它需要在公網(wǎng)上部署兩臺服務(wù)器才能對NAT路由器進行判斷，這就需要兩個IP地址才能完成測試，這在Windows環(huán)境下比較難實現(xiàn)，對于當(dāng)今IP地址比較缺乏的情況下，往往要花費的成本比較大。本文對RFC3489所給的解決方案進行了改進，在同一臺服務(wù)器上用不同的端口對客戶端的消息進行響應(yīng)，設(shè)計出以上的測試方案，來判斷出NAT的類型。但是有些情況不能具體識別出固定類型，但是這并不影響后續(xù)工作，本文研究目的是為了在客戶端之間建立直接聯(lián)系。所以這種方法還是很有應(yīng)用價值的。
3 NAT路由器穿越算法設(shè)計
3.1 NAT路由器穿越概述
??? 通過以上的分析，很容易看出，對于處于不同網(wǎng)絡(luò)環(huán)境的客戶端來說，想進行直接通信，首先需要判斷出NAT的類型，根據(jù)NAT路由器的類型來決定處于路由器后面的主機雙方是否可以進行直接通信。以某個公司的網(wǎng)絡(luò)為例，公司通過NAT路由器連接到公網(wǎng)上，公司內(nèi)部通過NAT路由器建立了三個局域網(wǎng)。網(wǎng)絡(luò)環(huán)境(見圖1)處于路由器后面的主機雙方要直接通信需要有STUN服務(wù)器的配合。根據(jù)判斷的NAT路由器的類型確定路由器后面的雙方客戶端是否可以建立直接通信。
3.2 NAT路由器穿越算法
??? 根據(jù)前面分析，NAT路由器的穿越算法可以描述如下：
??? (1) 終端A、B分別登錄服務(wù)器，判斷自己所處的網(wǎng)絡(luò)環(huán)境，即各自所處網(wǎng)絡(luò)中NAT的類型。
??? (2) 從服務(wù)器獲得終端B所處的網(wǎng)絡(luò)NAT的類型，確定是否可以建立直接通信。
??? (3) 不能建立直接通信的情況，程序直接退出
??? (4) 對于可以建立直接通信的網(wǎng)絡(luò)，確定具體的解決方案。有下面幾種情況
??? a．終端A、終端B處于同一網(wǎng)段時，終端A直接向終端B發(fā)送Message消息。終端B響應(yīng)Message消息，回復(fù)Message消息給終端A。
??? b．對于不同網(wǎng)段，分為兩種情況。終端B為對稱NAT的情況，終端A首先向終端B發(fā)送Message消息，然后終端A往服務(wù)器發(fā)送Message2消息。服務(wù)器收到Message2消息后，服務(wù)器再向終端B發(fā)送Message3消息，終端B根據(jù)收到的消息類型做出響應(yīng)，往終端A發(fā)送Message消息；對于終端B為非對稱NAT的情況，終端A首先向服務(wù)器發(fā)送Message2消息，然后再發(fā)送Message消息給終端B。
??? (5) 終端A、終端B退出服務(wù)器。建立直接通信成功。
??? 在發(fā)送消息時，要建立消息來源信息庫，如IP地址，端口號，以及映射關(guān)系。方便處理消息時使用相關(guān)資源。算法流程如圖3所示，終端A(圖中用A標(biāo)識) 與終端B(圖中用B標(biāo)識) 建立直接通信，STUN服務(wù)器為Server。消息類型有Message、Message 2、Message 3三種消息類型。
?
??? 這里以終端B所處的NAT類型為對稱NAT為例，終端A的IP為172.22.2.9，其公網(wǎng)IP為210.80.43.104，Server的IP為202.120.58.178，終端B的IP192.168.101.6，終端B的公網(wǎng)IP是222.191.255.68。圖4為終端A在與終端B建立直接通信的時序圖。
?
??? 圖4中，只對終端A與終端B處于不同的網(wǎng)段內(nèi)作了一個分析。對于二者處于同一個網(wǎng)段內(nèi)的情況，比較容易解決,終端A直接向終端B發(fā)送Message 消息即可建立直接通信。
??? 對于終端B處于非對稱NAT的情況，解決方案的差別之處就在于發(fā)送的消息順序不一樣。非對稱NAT的情況下，終端A首先發(fā)送Message 2消息和服務(wù)器通信，然后在發(fā)送Message消息與終端B進行通信。這與對稱NAT的情況剛好相反。
??? 為了能夠順利的建立直接通信，在建立直接通信成功后，讓客戶端雙方在相互通信3次，確認(rèn)直接通信是否成功，在下面的仿真實驗中可以體現(xiàn)出來。
??? 有三種情況現(xiàn)在還沒有找到比較好的解決辦法：雙方處于阻礙UDP防火墻的NAT路由器；雙方都是對稱NAT的防火墻；一方為對稱NAT，另一方為端口受限NAT。
3.3 算法仿真結(jié)果
??? 對于NAT路由器穿越算法，進行了實驗測試，仿真中，發(fā)送的消息類型(TRANS，MESSAGE，Message3),客戶端實驗結(jié)果如圖5、圖6所示。
?
?
??? 此外，對于雙方客戶端處于同一局域網(wǎng)內(nèi)不同級別的NAT后面理論上是可以直接通信的，但是要取決于最外層的NAT是否支持Loopback translate功能，也就是內(nèi)網(wǎng)主機A向內(nèi)網(wǎng)主機B的最外層NAT外網(wǎng)地址和端口發(fā)送數(shù)據(jù)，最外層的NAT是夠能夠?qū)?shù)據(jù)轉(zhuǎn)發(fā)給主機B，如果最外層NAT支持此功能，則A和B可以建立直接通信，否則不能。
4 NAT路由器穿越算法的優(yōu)缺點
??? NAT技術(shù)的優(yōu)點決定了它的應(yīng)用廣泛性，但是根據(jù)STUN協(xié)議來實現(xiàn)NAT路由器的穿越問題往往需要的開銷比較大，本文提出了一種比較方便的算法，在不增加成本的基礎(chǔ)上能夠準(zhǔn)確地判斷出來NAT路由器的類型，對NAT路由器穿越問題進行了詳細的研究、設(shè)計。這對于中小型的企業(yè)來說，不僅節(jié)省了成本預(yù)算，而且達到了實際的效果。但是對于有些公司部署對稱NAT路由器，該算法還有一些不足之處，還需要進一步研究，對算法進行改進。
??? 本文對STUN協(xié)議提出的NAT識別方法進行了有效地改進，并對NAT路由器的穿越問題進行了詳細地研究，并設(shè)計出比較合理的算法。提高了效率，節(jié)省了成本。并指出了該算法的優(yōu)點和不足。
參考文獻
[1] Rosenberg J, Weinberger J. STUN-Simple Traversal of user Datagram Protocol (UDP) Trough Network Address Translators (NATs). RFC3489, 2003.
[2]?Egevang K. The IP Network Address Translator (NAT). RFC1631, 2001.
[3] ?Hitema C. Short Term NAT Requirements for UDP Based Peer-to-Peer Applications. IETF Draft, 2001.
[4]?P Srisuresh, M Holdrege . IP Network Address Translator(NAT) Terminology and Considerations. RFC2663, 1999.