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.
一、NAT/ALG 方式
普通NAT是通過修改UDP或TCP報文頭部地址信息實現地址的轉換，但對於VOIP應用，在TCP/UDP淨載中也需帶地址信息，ALG方式是指在私網中的VOIP終端在淨載中填寫的是其私網地址，此地址信息在通過NAT時被修改爲NAT上對外的地址。
此時當然要求ALG功能駐留在NAT/Firewall設備中，要求這些設備本身具備應用識別的智能。支持IP 語音和視頻協議(H323、SIP、 MGCP/H248)的識別和對NAT/Firewall的控制，同時每增加一種新的應用都將需要對 NAT/Firewall進行升級。
在安全要求上還需要作一些折衷，因爲ALG 不能識別加密後的報文內容，所以必須保證報文采用明文傳送，這使得報文在公網中傳送時有很大的安全隱患。
NAT/ALG是支持VOIP NAT穿透的一種最簡單的方式，但由於網絡實際情況是已部署了大量的不支持此種特性的NAT/FW設備，因此，實際應用中，很難採用這種方式。
二、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語音和視頻協議(H323、SIP、MGCP/H248)的識別和對NAT/Firewall的控制，來完成VOIP應用穿越 NAT/Firewall .在安全性上，MIDCOM方式可支持控制報文的加密，可支持媒體流的加密，因此安全性比較高。
如果在軟交換設備上實現對SIP/H323/MGCP/H248協議的識別，就只需在軟交換和NAT/FW設備上增加MIDCOM協議即可，而且以後新的應用業務識別隨着軟交換的支持而支持，此方案是一種比較有前途的解決方案，但要求現有的NAT/FW設備需升級支持MIDCOM協議，從這一點上來說，對已大量佈署的NAT/FW設備來說，也是很困難的，同NAT/ALG方式有相同的問題。
三、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通常是這種類型)穿越。
四、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作爲一種綜合的解決方案將有着非常廣闊的應用前景。