stun turn ice等穿越NAT方法

STUN（Simple Traversal of User Datagram Protocol through Network Address Translators (NATs)，NAT的UDP簡單穿越）是一種網絡協議，它容許位於NAT（或多重NAT）後的客戶端找出本身的公網地址，查出本身位於哪一種類型的NAT以後以及NAT爲某一個本地端口所綁定的Internet端端口。這些信息被用來在兩個同時處於NAT 路由器以後的主機之間創建UDP通訊。該協議由RFC 3489定義。

[編輯]方案

一旦客戶端得知了Internet端的UDP端口，通訊就能夠開始了。若是NAT是徹底圓錐型的，那麼雙方中的任何一方均可以發起通訊。若是NAT是受限圓錐型或端口受限圓錐型，雙方必須一塊兒開始傳輸。

須要注意的是，要使用STUN RFC中描述的技術並不必定須要使用STUN協議——還能夠另外設計一個協議並把相同的功能集成到運行該協議的服務器上。

SIP之類的協議是使用UDP分組在Internet上傳輸音頻和／或視頻數據的。不幸的是，因爲通訊的兩個末端每每位於NAT以後，所以用傳統的方法是沒法創建鏈接的。這也就是STUN發揮做用的地方。

STUN是一個客戶機－服務器協議。一個VoIP電話或軟件包可能會包括一個STUN客戶端。這個客戶端會向STUN服務器發送請求，以後，服務器就會向STUN客戶端報告NAT路由器的公網IP地址以及NAT爲容許傳入流量傳回內網而開通的端口。

以上的響應同時還使得STUN客戶端可以肯定正在使用的NAT類型——由於不一樣的NAT類型處理傳入的UDP分組的方式是不一樣的。四種主要類型中有三種是可使用的：徹底圓錐型NAT、受限圓錐型NAT和端口受限圓錐型NAT——但大型公司網絡中常常採用的對稱型NAT（又稱爲雙向NAT）則不能使用。

[編輯]算法

STUN 使用下列的算法（取自 RFC 3489）來發現 NAT gateways 以及防火牆（firewalls）:

一旦路經經過紅色箱子的終點時，UDP的溝通是沒有可能性的。一旦經過黃色或是綠色的箱子，就有連線的可能。

Traversal Using Relays around NAT

From Wikipedia, the free encyclopedia

Jump to:  navigation,  search

"TURN" redirects here. For other uses, see  Turn (disambiguation).

Traversal Using Relays around NAT (TURN) is aprotocol that allows for an element behind aNetwork address translator (NAT) or firewall to receive incoming data over TCP or UDP connections. It is most useful for elements behind symmetric NATs or firewalls that wish to be on the receiving end of a connection to a single peer. TURN does not allow for users to runservers on well known ports if they are behind a NAT; it supports the connection of a user behind a NAT to only a singlepeer. In that regard, its role is to provide the same security functions provided by symmetric NATs and firewalls, but toturn the tables so that the element on the inside can be on the receiving end, rather than the sending end, of a connection that is requested by the client.

TURN is specified by RFC 5766. An update to TURN forIPv6 is specified in RFC 6156.

Contents [hide] 1Introduction 2See also 3External links 3.1Implementations

[edit]Introduction

NATs, while providing many benefits, also come with many drawbacks. The most troublesome of those drawbacks is the fact that they break many existing IP applications, and make it difficult to deploy new ones. Guidelines have been developed that describe how to build "NAT friendly" protocols, but many protocols simply cannot be constructed according to those guidelines. Examples of such protocols include multimedia applications and file sharing.

Session Traversal Utilities for NAT (STUN) provides one means for an application to traverse a NAT. STUN allows a client to obtain a transport address (an IP address and port) which may be useful for receiving packets from a peer. However, addresses obtained by STUN may not be usable by all peers. Those addresses work depending on the topological conditions of the network. Therefore, STUN by itself cannot provide a complete solution for NAT traversal.

A complete solution requires a means by which a client can obtain a transport address from which it can receive media from any peer which can send packets to the public Internet. This can only be accomplished by relaying data through a server that resides on the public Internet. This specification describes Traversal Using Relay NAT (TURN), a protocol that allows a client to obtain IP addresses and ports from such a relay.

Although TURN will almost always provide connectivity to a client, it comes at high cost to the provider of the TURN server. It is therefore desirable to use TURN as a last resort only, preferring other mechanisms (such as STUN or direct connectivity) when possible. To accomplish that, the Interactive Connectivity Establishment(ICE) methodology can be used to discover the optimal means of connectivity.

 

　1、NAT/ALG 方式

　　普通NAT是經過修改UDP或TCP報文頭部地址信息實現地址的轉換，但對於VOIP應用，在TCP/UDP淨載中也需帶地址信息，ALG方式是指在私網中的VOIP終端在淨載中填寫的是其私網地址，此地址信息在經過NAT時被修改成NAT上對外的地址。

　　此時固然要求ALG功能駐留在NAT/Firewall設備中，要求這些設備自己具有應用識別的智能。支持IP 語音和視頻協議(H32三、SIP、 MGCP/H248)的識別和對NAT/Firewall的控制，同時每增長一種新的應用都將須要對 NAT/Firewall進行升級。

　　在安全要求上還須要做一些折衷，由於ALG 不能識別加密後的報文內容，因此必須保證報文采用明文傳送，這使得報文在公網中傳送時有很大的安全隱患。

　　NAT/ALG是支持VOIP NAT穿透的一種最簡單的方式，但因爲網絡實際狀況是已部署了大量的不支持此種特性的NAT/FW設備，所以，實際應用中，很難採用這種方式。

　　2、MIDCOM 方式

　　與NAT/ALG不一樣的是，MIDCOM的基本框架是採用可信的第三方(MIDCOM Agent)對Middlebox (NAT/FW)進行控制，VOIP協議的識別不禁Middlebox完成，而是由外部的MIDCOM Agent完成，所以VOIP使用的協議對Middlebox是透明的 .

　　因爲識別應用協議的功能從Middlebox移到外部的MIDCOM Agent上，根據MIDCOM 的構，在不須要更改Middlebox基本特性的基礎上，經過對MIDCOM Agent的升級就能夠支持更多的新業務，這是相對NAT/ALG方式的一個很大的優點。

　　在VOIP實際應用中，Middlebox功能可駐留在NAT/Firewall，經過軟交換設備(即MIDCOM Agent)對IP語音和視頻協議(H32三、SIP、MGCP/H248)的識別和對NAT/Firewall的控制，來完成VOIP應用穿越 NAT/Firewall .在安全性上，MIDCOM方式可支持控制報文的加密，可支持媒體流的加密，所以安全性比較高。

　　若是在軟交換設備上實現對SIP/H323/MGCP/H248協議的識別，就只需在軟交換和NAT/FW設備上增長MIDCOM協議便可，並且之後新的應用業務識別隨着軟交換的支持而支持，此方案是一種比較有前途的解決方案，但要求現有的NAT/FW設備需升級支持MIDCOM協議，從這一點上來講，對已大量佈署的NAT/FW設備來講，也是很困難的，同NAT/ALG方式有相同的問題。

　　3、STUN 方式

　　解決穿透NAT問題的另外一思路是，私網中的VOIP終端經過某種機制預先獲得出口NAT上的對外地址，而後在淨載中所填寫的地址信息直接填寫出口 NAT上的對外地址，而不是私網內終端的私有IP地址，這樣淨載中的內容在通過NAT時就無需被修改了，只需按普通NAT流程轉換報文頭的IP地址便可，淨載中的 IP地址信息和報文頭地址信息是一致的。STUN協議就是基於此思路來解決應用層地址的轉換問題。

　　STUN的全稱是Simple Traversal of UDP Through Network Address Translators，即 UDP對NAT的簡單穿越方式。 應用程序(即STUN CLIENT)向NAT外的STUN SERVER經過UDP發送請求STUN 消息， STUN SERVER收到請求消息，產生響應消息，響應消息中攜帶請求消息的源端口，即STUN CLIENT在NAT上對應的外部端口。而後響應消息經過NAT發送給STUN CLIENT，STUN CLIENT經過響應消息體中的內容得知其NAT上的外部地址，並將其填入之後呼叫協議的UDP負載中，告知對端，本端的RTP接收地址和端口號爲NAT 外部的地址和端口號。因爲經過STUN協議已在NAT上預先創建媒體流的NAT映射表項，故媒體流可順利穿越NAT.

　　STUN協議最大的優勢是無需現有NAT/FW設備作任何改動。因爲實際應用中，已有大量的NAT/FW，而且這些NAT/FW並不支持VoIP的應用，若是用MIDCOM或NAT/ALG方式來解決此問題，須要替換現有的NAT/FW，這是不太容易的。而採用STUN方式無需改動NAT/FW，這是其最大優點，同時STUN方式可在多個NAT串聯的網絡環境中使用，但MIDCOM方式則沒法實現對多級NAT的有效控制。

　　STUN的侷限性在於須要VOIP終端支持STUN CLIENT的功能，同時STUN並不適合支持TCP鏈接的穿越，所以不支持H323.另外 STUN方式不支持對防火牆的穿越，不支持對稱NAT (Symmetric NAT)類型(在安全性要求較高的企業網中，出口NAT一般是這種類型)穿越。

　　4、TURN方式

　　TURN方式解決NAT問題的思路與STUN類似，也是私網中的VOIP終端經過某種機制預先得公網上的服務地址(STUN方式獲得的地址爲出口 NAT上外部地址，TURN方式獲得地址爲TURN Server上的公網地址)，而後在報文淨載中所要求的地址信息就直接填寫該公網地址。

　　TURN的全稱爲Traversal Using Relay NAT，即經過Relay方式穿越NAT.TURN應用模型經過分配 TURN Server的地址和端口做爲私網中VOIP終端對外的接受地址和端口，即私網終端發出的報文都要通過TURN Server進行Relay轉發，這種方式除了具備STUN方式的優勢外，還解決了STUN應用沒法穿透對稱NAT(Symmetric NAT)以及相似的Firewall設備的缺陷，同時TURN支持基於TCP的應用，如H323協議。此外TURN Server控制分配地址和端口，能分配RTP/RTCP地址對(RTCP端口號爲RTP端口號加1)做爲私網終端用戶的接受地址，避免了STUN方式中出口NAT對RTP/RTCP地址端口號的任意分配，使得客戶端沒法收到對端發來的RTCP報文(對端發RTCP報文時，目的端口號缺省按RTP端口號加 1發送)。

　　TURN的侷限性在於須要VOIP終端支持TURN Client，這一點同STUN同樣對網絡終端有要求。此外，全部報文都必須通過TURN Server轉發，增大了包的延遲和丟包的可能性。

 

基於ICE的VoIP穿越NAT改進方案

1 引言

    近年來，隨着數據網絡通訊逐漸融入傳統的話音業務領域，VoIP技術愈來愈成爲當前商業考慮的對象，並正在向一種正式的商業電話模式演進，而會話初始協議(SIP，Session Initiation Protoc01)就是用來確保這種演進可以實現而須要的NGN(下一代網絡)系列協議中重要的一員。SIP是一個用於創建，更改和終止多媒體會話的應用層控制I辦議。SIP因其簡睢、靈活、可擴展性強的特色，已經成爲實現VolP系統的熱點技術。

    隨着計算機網絡技術的不斷髮展，互聯網規模飛速膨脹，大量企業和駐地網採用了私有網絡經過NAT/防火牆出口來接入公共網絡。而因爲SIP包頭中含有不少對於路由、接續SIP信令和創建呼叫鏈接必不可少的地址信息，這樣引起了業界對於SIP2穿越NAT/防火牆問題的研究。

    目前，IETF已經對該問題提出了多種解決方案。例如：ALCes(Application Layer Gateways)、MiddleboxControl Protocol、STUN Simple Traversal of UDPthrough NAT)、TURN(Traversal Using Relay NAT)、RSIP(Realm Specific IP)、Symmetric RTP等。然而，當這些技術應用於不一樣的網絡拓撲時都有着顯著的利弊，以致於只能根據不一樣的接入方式來應用不一樣的方案，因此，未能很好地解決A11-NATⅢ的問題，同時還會給系統引入許多複雜性和脆弱性因素。此外，因爲NAT/防火牆已經大量應用，SIP設備也已經比較成熟，對它們進行升級來支持多媒體通訊穿越NAT/防火牆的代價將至關的大。所以，一種不須要升級任何現有網絡設備，可以穿越各類NAT/防火牆而且方便在現有網絡中實施的解決方案成爲迫切的須要。

    本文試圖尋找一種可以穿越各類類型的NAT/防火牆，無需對現有NAT/防火牆沒備作任何改動的解決方案——ICE解決方案，這種方式比之前的解決方案更加靈活，具備廣闊的應用前景。

   2 現有NAT解決方案的比較分析

    主流的NAT穿越解決方案包括STUN、TURN、Proxy及隧道穿越等，這幾種方式各具優缺點，比較以下：

    (1)STUNml(simple traversal of UDP over NAT)的原理是經過某種機制預先獲得內部私有IP地址對應在出口NAT上的對外公網IP地址，而後在報文負載中所描述的地址信息就直接填寫出口NAT上的對外IP地址。其最大的優勢是無需對現有NAT/防火牆設備作任何改動。侷限性在於須要應用程序支持STUN CLIENT的功能，同時STUN並不適合支持TCP鏈接的穿越。

    (2)TURN即經過Relay方式穿越NAT，也是私網中的SIP終端經過某種機制預先得劍TURN SeI-ver上的公網地址，私網終端發出的報文都要通過TURN Serve：進行Relay轉發。這種方式除了具備STUN方式的優勢外，還解決了STUN應用沒法穿透對稱NAT(SymmetricNAT)以及相似的Firewall設備的缺陷，侷限性在於須要SIP終端支持TURN Client，並增大了包的延遲和丟包的可能性。

    (3)Proxy方式是指經過對私網內用戶呼叫的信令和媒體||d時作Relay來實現對NAT/防火牆的穿越。因爲不用對運營商和客戶端的現有網絡設備進行任何改造，具備很強的適應性，組網靈活，可盡是NGN初期多樣化的組網和用戶接入。

    (4)隧道穿越技術的基本思想是經過把須要穿越的數據流封裝徵某種隧道中，從而繞過NAT/防火牆。它在很大程度上解決了對於不問應用協議須要開發不一樣穿越策略的辦法，可是必須多媒體終端和服務器可以支持隧道，這是一個比較大的限制條件。

    3 穿越NAT/防火牆方案的實現

    3．1 ICE方式

    交互式連通創建方式ICE(Interactive ConnectivityEstablishment)並不是一種新的協議，它不須要對STUN，TURN或RSIP進行擴展就可適用於各類NAT。ICE是經過綜合運用上面某幾種協議，使之徵最適合的狀況下工做，以彌補單獨使用其中任何一種所帶來的固有缺陷。對於SIP來講，ICE只須要定義一些SDP(Sessionescription Protoc01)附加屬性便可，對於別的多媒體信令協議也須要制定一些相應的機制來實現。本文是針對SIP呼叫流程實現ICE的功能。

    這種方式的優勢是能夠根據通信雙方所處的網絡環境，選取適合穿越NAT/防火牆的方式。首先，獲取用戶所徵網絡中NAT的類型，若是用戶沒有設置使用何種方式鏈接，那麼默隊首先使用UDP鏈接，若是必定時間內沒有鏈接成功，接着使用TCP鏈接，一樣若是沒有在必定時間內鏈接成功，那麼將採用其餘方式如Upnp、Httptunnel。若是全部穿越方案都失敗後，將結果返回給用戶，由用戶決定是否重試。

    3．2 ICE算法流程

    ICE算法流程分爲以F幾個過程：

    (1)收集本地傳輸地址

    會話者從服務器上得到主機上一個物理(或虛擬)接口綁定一個端口的本地傳輸地址。

    (2)啓動STUN

    與傳統的STUN不一樣，ICE用戶名和密碼能夠經過信令協議進行交換。

    (3)肯定傳輸地址的優先級

    優先級反映了UA在該地址上接收媒體流的優先級別，取值範圍0到1之間，按照被傳輸媒體流量來肯定。

    (4)構建初始化信息(Initiate Message)

    初始化消息由一系列媒體流組成，每一個媒體流的任意Peer之間實現最人連通可能性的傳輸地址是由公網L轉發服務器(如TURN)提供的地址。

    (5)響應處理

    連通性檢查和執行ICE算法中描述的地址收集過程。

    (6)生成接受信息(Accept Message)

    若接受則發送Accept消息，其構造過程與InitiateMessage相似。

    (7)接受信息處理

    接受過程須要發起者使用Send命令，由服務器轉發至響應者。

    (8)附加ICE過程

    Initiate或Accept消息交換過程結束後，雙方可能仍將繼續收集傳輸地址。

3．3 ICE算法實現

    當將ICE算法集成到SIP呼叫過程的時候，流程應該是：(1)SIP終端註冊，而且訪問STUN(STUNT)服務器，判斷NAT/防火牆類型，以及TCP時三種序列的包的過濾狀況。(2)當發起呼叫信息(INVITE)或接收到呼叫信息迴應(200 OK)以前根據NAT/防火牆類型進行對RTP進行地址收集(任非對稱性NAT/防火牆後須要收集NAT映射地址，在對稱性NAT/防火牆後還須要收集TURN地址)。(3)在RTP的地址端口啓動接收線程RSTUN服務程序。(4)發送SIP消息，收集的地址放列SDP消息中的alt屬性中。(5)SIP終端獲得通信雙方地址後進行地址配對(將雙方地址進行組合)，而且根據雙方網絡狀況去掉無效的地址對。(6)根據地址對發

    送STUN check的包，其中STUN消息的用戶名，密碼從alt屬性中獲得，標識該地址對。(7)當檢測到有效的地址對時(能夠發送RTP媒體流的地址)，中止接收線程STUN服務)，開始傳輸RTP流。

    本文實現採用Winpcap API首先捕獲TCP鏈接的SYN--out包，修改lP包頭的TTL的值，用pcap—sendpacket()。而後使該socket調用listen函數。實現過程當中對應於ICE收集地址的算法描述爲：

    類中m_nCandidateID對應地址序號，m_nPriority表示地址優先級，m_CandidateAddr表示地址(IP地址，端口)。實現ICE算法的實體算法描述爲：

    實現ICE中會話發起者和接收者的步驟基本同樣，僅任處理流程中前後次序稍微有些不一樣，本文中實現的會話流程如圖l所示。

    圖1會話流程

    4 測試

    以安裝了SIP軟終端的雙方都在Full ConeNATNAT/防火牆後爲例，進行實例測試。測試過程：

    (1)將兩臺PC的IP的配置分別爲公網59．64．148．187122和私網10．0．0．5/8l

    (2)從公網中的用戶代理向私網內的用戶代理呼叫，結果可以創建會話，無明顯的延時，話音質量良好；

    (3)從私網內的用戶代理向公網中的用戶代理呼叫，結果可以創建會話，且話音質量良好；

    經過抓包分析能夠肯定，使用該算法能夠成功地穿越NAT/防火牆設備。

    5 結論

    ICE方式的優點是顯而易見的，它消除了現有的機制的許多脆弱性。例如，傳統的STUN有幾個脆弱點，其中一個就是發現過程須要客戶端本身去判斷所在NAT類型，這實際上不是一個可取的作法。而應用ICE以後，這個發現過程己經不須要了。另外一點脆弱性在於STUN，TURN等機制都徹底依賴於一個附加的服務器，而ICE利用服務器分配單邊地址的同時，還容許客戶端直接相連，所以即便STUN或TRUN服務器中有任何一個失敗了，ICE方式仍可以讓呼叫過程繼續下去。此外，傳統的STUN最大的缺陷在於，它不能保證在全部網絡拓撲結構中都正常工做，對於TURN或相似轉發方式工做的協議來講，因爲服務器的負擔太重，很容易出現丟包或者延遲狀況。而ICE方式正好提供了一種負載均衡的解決方案，它將轉發服務做爲優先級最低的服務，從而在最大程度上保證了服務的可靠性和靈活性。此外，ICE的優點還在於對IPv6的支持。因爲普遍的適應能力以及對將來網絡的支持，ICE做爲一種綜合的解決方案將有着很是廣闊的應用前景。