NAT解決方案的選擇
目前，根據(jù)對(duì)NAT支持的不同，處理機(jī)制的不同，業(yè)內(nèi)把解決NAT的方法一般有分為以下幾種：
這些方案都有其各自的特點(diǎn)。根據(jù)國(guó)外有關(guān)市場(chǎng)研究人員的報(bào)告指出，不同企業(yè)類型的要求不同，部署成本，安全因素，維護(hù)成本等因素的影響，所以它們對(duì)解決方案的要求也可能有所不同，以下是調(diào)查結(jié)果發(fā)布狀態(tài)：
- 一般家庭用戶選擇簡(jiǎn)單的NAT解決方案，例如UPnp，STUN，TURN， ICE
- 小型企業(yè)用戶大部分用戶可能選擇STUN，TURN， ICE 或者SBC，也可能選擇UPnP的方案。
- 一般中型企業(yè)則選擇SBC，STUN， TURN和企業(yè)級(jí)的SBC加防火墻的方案。
- 比較大的企業(yè)則會(huì)選擇防火墻，SBC的解決方案。
當(dāng)然，選擇是有成本的。對(duì)于VOIP的解決方案，安全是一個(gè)公司的非常重要的考慮因素，用戶也要根據(jù)不同的安全要求對(duì)解決方案進(jìn)行比較全面的分析，以下圖例數(shù)據(jù)表示各種解決方案對(duì)安全的考慮和其可控性的考慮。
從以上數(shù)據(jù)我們可以看到，如果用戶需要更加安全的部署方式，需要對(duì)其訪問(wèn)有非常大的靈活性和可靠性，最好的方式還是選擇SBC。
關(guān)于STUN和TURN的討論
在實(shí)際生產(chǎn)環(huán)境中，我們客戶通常使用的設(shè)備所支持的STUN和TURN都可能有所不同，所以這樣就會(huì)導(dǎo)致一個(gè)解決方案兼容性的問(wèn)題。例如，可能有的物理話機(jī)支持STUN和TURN，但是不支持ICE，有的軟電話可能支持的舊版本的STUN，不支持新標(biāo)準(zhǔn)的STUN。
下面，我們介紹一下關(guān)于STUN的流程機(jī)制。這里我們要注意，一般我們舉例時(shí)使用的是RFC5389來(lái)解釋的，相對(duì)比較舊的STUN版本是RFC3489（classic STUN）。在RFC5389的規(guī)定中，STUN定義為輕量級(jí)的工具，它不是一個(gè)完整的NAT穿透解決方案（RFC3489定義為完整的解決方案），它僅是一個(gè)解決穿透能力的工具。另外，RFC3489的規(guī)定有幾個(gè)方面的不足，很難滿足真正的NAT解決方案。根據(jù)RFC5389的解釋，RFC3489的不足主要表現(xiàn)在：
在實(shí)際部署環(huán)境中，IP和端口有時(shí)可以作為Peer來(lái)進(jìn)行通信，有時(shí)則不能。Classic STUN沒(méi)有提供準(zhǔn)確的方法來(lái)處理這些問(wèn)題。
Classic STUN的算法對(duì)多層NAT可能發(fā)生錯(cuò)誤。
Classic STUN存在安全漏洞，可能有時(shí)駭客會(huì)利用某些端口重新映射時(shí)進(jìn)行地址或者端口串改。
目前，根據(jù)RFC5389對(duì)STUN所執(zhí)行的功能包括：
- 用于ICE連接支持（MMUSIC-ICE）
- 用于客戶端的初始化連接（SIP-OUTBOUND）
- NAT行為發(fā)現(xiàn)（BEHAVE-TURN）。
STUN 簡(jiǎn)單來(lái)說(shuō)，內(nèi)網(wǎng)SIP終端通過(guò)STUN對(duì)STUN發(fā)出請(qǐng)求，STUN回復(fù)一個(gè)響應(yīng)，STUN服務(wù)器告訴使用指定的外網(wǎng)端口和IP地址。STUN使用UDP，默認(rèn)端口是3478。它在響應(yīng)的消息中包含了MAPPED-ADDRESS，RESPONSE-ORIGIN，OTHER-ADDRESS和XOR-MAPPED-ADDRESS這四個(gè)參數(shù)。通常來(lái)說(shuō)，為了支持NAT的映射和過(guò)濾行為機(jī)制，STUN服務(wù)器必須支持兩個(gè)公網(wǎng)IP地址和兩個(gè)不同的端口，分別稱之為主信息地址和可選消息地址。讓我們看看具體的實(shí)現(xiàn)方式。
具體的流程包括：第一步客戶端A 通過(guò)設(shè)置的STUN地址查詢STUN外網(wǎng)地址和端口。第二步，客戶端A對(duì)客戶端B發(fā)生信令消息，通知客戶端B的外網(wǎng)地址和端口，可以對(duì)其發(fā)送媒體�？蛻舳薆然后對(duì)NAT路由器發(fā)送媒體，NAT路由器然后轉(zhuǎn)發(fā)到客戶端 A。
以下圖例是一個(gè)簡(jiǎn)單的STUN流程圖（缺少對(duì)Symmetric 的支持，需要TURN支持）：
在上面的流程中，NAT是如何被檢測(cè)的？RFC 5780 規(guī)定了三個(gè)階段的NAT檢測(cè)方式：
NAT檢測(cè)的具體步驟：
研究人員Baruch 更加詳細(xì)地描述了這個(gè)test的流程，用戶可以查閱此研究人員的文檔做進(jìn)一步了解。具體Test的邏輯順序請(qǐng)讀者參考 RFC5780的4.5 部分。如果讀者需要了解更多的相關(guān)定義，請(qǐng)參RFC 5780 相關(guān)協(xié)議：
現(xiàn)在讓我們看看在SIP中NAT請(qǐng)求和響應(yīng)的示例。
STUN 返回的IP和port number， SIP然后在SIP header 使用這個(gè)新的地址。
大家需要注意以下SIP頭中的rport 1024, 當(dāng)在NAT后的終端收到消息時(shí)，這個(gè)rport 端口會(huì)覆蓋原來(lái)的端口49300端口。這里，實(shí)際上，rport是做路由使用的。關(guān)于rport 端口的修改問(wèn)題，讀者查閱RFC3581 的Server Behavior中rport的修改規(guī)則。用戶必須注意，在有一些網(wǎng)絡(luò)環(huán)境中，系統(tǒng)管理機(jī)制可能對(duì)收到的消息和返回的消息地址端口非常敏感，如果是這樣的話，RFC3581 標(biāo)準(zhǔn)建議開(kāi)啟TLS服務(wù)。另外，用戶也應(yīng)該注意到，如果修改rport了，這里可能涉及到了一個(gè)安全的問(wèn)題，攻擊者在路由路徑中插入了一個(gè)中轉(zhuǎn)服務(wù)器的話，可能導(dǎo)致安全問(wèn)題。
盡管STUN可以解決很多類型的NAT問(wèn)題，但是仍然有很多局限性：
- STUN不支持Symmetric NAT類型，因?yàn)槊恳粋�(gè)新創(chuàng)建的IP：port 的會(huì)話映射可能地址以前STUN檢測(cè)到的數(shù)據(jù)失效。
- 如果防火墻設(shè)置了對(duì)UDP丟棄數(shù)據(jù)包的參數(shù)，也會(huì)導(dǎo)致STUN失敗。
- 因?yàn)閁DP不是一個(gè)長(zhǎng)連接的方式，防火墻可能關(guān)閉一些存活動(dòng)端口，這樣可能導(dǎo)致會(huì)話失敗。
- 終端客戶的網(wǎng)絡(luò)環(huán)境可能導(dǎo)致STUN失敗，因?yàn)橛械慕K端可以抵達(dá)服務(wù)商的服務(wù)器地址，有的SIP終端可能可能不會(huì)抵達(dá)STUN服務(wù)器地址（例如，很多國(guó)內(nèi)用戶使用國(guó)外的STUN地址），這樣的話，SIP之間可能存在多層的NAT問(wèn)題。整個(gè)網(wǎng)絡(luò)環(huán)境會(huì)變得更加復(fù)雜。
關(guān)于TURN的討論
既然STUN存在那么多的問(wèn)題，但是如何解決這些問(wèn)題是技術(shù)研究人員必須面對(duì)的困難。俗話說(shuō)，辦法總比問(wèn)題多。TURN是一個(gè)補(bǔ)充STUN不足的好辦法。TURN的英文全稱如下：
- Traversal Using Relays around NAT （TURN）
- Relay Extensions to Session Traversal Utilities for NAT （STUN）
從英文全稱就可以看出，它僅是STUN的一種拓展，使用了中繼穿透NAT的方式。根據(jù)RFC5766的描述，TURN的設(shè)計(jì)目的是ICE的一部分，但是可以獨(dú)立使用。
在很多應(yīng)用場(chǎng)景中，位于NAT后面的終端可能不能與外網(wǎng)的終端進(jìn)行點(diǎn)對(duì)點(diǎn)的通信，如果需要雙方通信的話，只能借助于一個(gè)外網(wǎng)的中轉(zhuǎn)服務(wù)點(diǎn)來(lái)實(shí)現(xiàn)互通。TURN的作用就是幫助雙方繞過(guò)阻擋的網(wǎng)絡(luò)點(diǎn)，使用中繼的方式，支持終端控制中繼操作從而實(shí)現(xiàn)雙方的數(shù)據(jù)交換，也可以支持終端對(duì)多點(diǎn)終端互通。
TURN和STUN相比，因?yàn)門URN的它本身的拓展，所以它也支持更多的功能，以下是對(duì)于TURN的一個(gè)總結(jié)：
除了本身工作方式類似以為，TURN可以支持SIP消息和媒體的轉(zhuǎn)發(fā)，工作角色可以是一個(gè)代理的形式。
TURN可以支持UDP和TCP，TCP可以支持長(zhǎng)連接，從而保證防火墻對(duì)會(huì)話的連接不會(huì)斷開(kāi)。但是，這里要注意，根據(jù)RFC5766的規(guī)定，如果是TRUN server 到Peer則都使用UDP。大概20%以上的會(huì)話需要使用TURN。
TURN可以支持Symmetric NAT, 但是STUN則不能支持。我們前面已經(jīng)提及。
TURN必須支持公網(wǎng)IP地址。
TURN的本身要求服務(wù)提供商的TURN服務(wù)器部署成本相對(duì)比較高。因?yàn)椋琓URN需要考慮大量會(huì)話，大量轉(zhuǎn)發(fā)數(shù)據(jù)，同時(shí)還要獲取Relays 路徑中的交換數(shù)據(jù)。
以上我們討論的是關(guān)于整個(gè)TURN的使用場(chǎng)景的各種因素，但是還有很多細(xì)節(jié)性的問(wèn)題可能在實(shí)際應(yīng)用中也可能出現(xiàn)，例如，以下圖例是一個(gè)開(kāi)發(fā)人員在測(cè)試WebRTC中關(guān)于使用P2P和SFU時(shí)的數(shù)據(jù)，使用P2P或SFU測(cè)試的結(jié)果是完全不同的。以下是其中一個(gè)數(shù)據(jù)。
TURN服務(wù)器的表現(xiàn)因?yàn)榈乩碓�，配置原因或者其他的原因造成的�?duì)語(yǔ)音時(shí)延也完全不同，以下示例來(lái)自于 Dag-Inge Aas， 在開(kāi)發(fā)WebRTC時(shí)對(duì)于TURN服務(wù)器時(shí)延的實(shí)驗(yàn)數(shù)據(jù)，各個(gè)服務(wù)器的帶寬不同，處理能力不同導(dǎo)致的各種不同的結(jié)果。
如果用戶選擇TURN的話，可以參考Twillio的標(biāo)準(zhǔn)來(lái)做出決定：是否全球部署，是否靠近用戶，是否支持拓展，是否優(yōu)化時(shí)延。
關(guān)于ICE討論
前面我們?cè)敿?xì)討論了STUN和TURN的使用場(chǎng)景和各種影響。讀者可能會(huì)看到，以上兩種方式仍然存在一些問(wèn)題。ICE的出現(xiàn)改善了兩種NAT解決方法的很多問(wèn)題。ICE英文全名是Interactive Connectivity Establishment。RFC5245（更新的RFC6336）對(duì)ICE做了規(guī)定。一般簡(jiǎn)單的定義是：ICE=STUN+TURN+協(xié)商機(jī)制+協(xié)商路徑。以下圖例中表示了ICE的架構(gòu)。
以下是一個(gè)Candidate的消息架構(gòu)體，關(guān)于結(jié)構(gòu)體中每個(gè)參數(shù)的含義，請(qǐng)參閱RFC3245的第三部分（Terminology）。
ICE執(zhí)行的幾個(gè)步驟：
- 發(fā)現(xiàn)收集申請(qǐng)終端信息。收集到終端可通信的地址，終端申請(qǐng)者的類型（host, Reflexive和Relay candidate）。
- 根據(jù)優(yōu)先級(jí)對(duì)candidate 進(jìn)行處理，大部分情況下，首先使用Relay candidate。
- 解析candidate信息，發(fā)送到對(duì)端candidate。
- 對(duì)candidate進(jìn)行配對(duì)處理，保證雙方匹配。
- 檢查配對(duì)的candidated的連接性。
- 計(jì)算ICE是否可以連接成功，如果成功，則發(fā)送確認(rèn)消息。
- 然后進(jìn)行語(yǔ)音流的通信。
以下幾個(gè)步驟比較詳細(xì)地介紹了關(guān)于SIP ICE的協(xié)商過(guò)程：
通過(guò)priority oder，結(jié)合兩個(gè)pair check the ICE開(kāi)始測(cè)試。如果雙方測(cè)試成功，則進(jìn)行下一步的信令交互，例如SIP 2 發(fā)送180消息，發(fā)送200 OK消息。如果開(kāi)始發(fā)送到消息和收到的消息不一致，則需要SIP Phone 1 重新發(fā)送Re-INVITE消息，然后進(jìn)行測(cè)試驗(yàn)證，最后收到200 OK消息。
ICE 測(cè)試成功以后，則雙方開(kāi)始發(fā)送RTP語(yǔ)音。
關(guān)于ICE的支持問(wèn)題，在我們很多常見(jiàn)的環(huán)境中，有的終端可以支持ICE，但是有一些終端可能不支持。用戶可以檢查各種軟電話的ICE配置功能。以下SIP消息中表示終端支持ICE:sip.ice。
如果對(duì)端終端不支持ICE的話，終端只能有兩種選擇：1）繼續(xù)連接，但是不使用ICE，ICE支持一個(gè)自動(dòng)檢測(cè)返回的機(jī)制，通知對(duì)端不支持ICE。2）或者繼續(xù)執(zhí)行一個(gè)可選授權(quán)支持的方式使用ICE，根據(jù)RFC5768對(duì)Mandating Support的規(guī)定， SIP終端可以在INVITE請(qǐng)求的Require中添加一個(gè)ice option。
另外，用戶可能有時(shí)看到這樣的例子，在終端的SIP INVITE頭中沒(méi)有sip.ice, 但是在SDP中確實(shí)有ICE candidate的信息，這也是互相不兼容導(dǎo)致的結(jié)果，但是最終這是一種不支持ICE的標(biāo)識(shí)。
因?yàn)镾IP技術(shù)本身的快速發(fā)展，其實(shí)ICE的版本也在不斷更新。這里，我們簡(jiǎn)單介紹兩個(gè)ICE的“升級(jí)”版本。這里，我稱之為升級(jí)版本僅是對(duì)ICE的一種優(yōu)化，它們并不是在ICE本身的升級(jí)或者更新：
ICE-lite主要功能是簡(jiǎn)化了ICE的復(fù)雜性，例如，我們看到的SBC。
Trickle ICE主要目的是縮短了ICE的協(xié)商處理時(shí)間，避免重新分配已被轉(zhuǎn)發(fā)的candidate，如果需要?jiǎng)t開(kāi)啟。不像ICE的標(biāo)準(zhǔn)處理流程，標(biāo)準(zhǔn)的ICE需要收集candidate的信息狀態(tài)信息，它則一開(kāi)始就和host candidate檢查連接狀態(tài)，同時(shí)并行處理其他的交換機(jī)制。所以，Trickle ICE相對(duì)較低了處理流程花費(fèi)的時(shí)間。
關(guān)于Near-NAT和Far-NAT討論
很多時(shí)候，大家可能會(huì)看到關(guān)于Near End NAT 和Far End NAT的解釋說(shuō)明。從字面意思也可以基本理解這兩個(gè)概念的基本區(qū)別。
Near End NAT是在本地NAT處理機(jī)制中通過(guò)本地ALG或者本地SBC修改了SIP 頭消息，出局時(shí)SIP頭消息變成了公網(wǎng)的IP地址，然后運(yùn)營(yíng)商SBC增加一個(gè)Via到SIP 頭，最后呼叫到對(duì)端終端。下面圖例中的五個(gè)處理流程解釋了Near End NAT的完整過(guò)程。
Far End NAT是本地網(wǎng)絡(luò)對(duì)SIP頭消息不做任何處理，運(yùn)營(yíng)商側(cè)SBC修改SIP頭消息，添加Via，然后呼叫遠(yuǎn)端終端。同時(shí)，運(yùn)營(yíng)商SBC會(huì)對(duì)內(nèi)網(wǎng)SIP終端發(fā)送一個(gè)SIP OPTION 或者NOTIFY消息，保證終端SIP防火墻的端口不被關(guān)閉，通信端口一直處于存活狀態(tài)。
從以上介紹中，我們可以看到，兩者之間的區(qū)別就在于在說(shuō)明地方修改的SIP頭的IP地址，而且Far End NAT的處理方式會(huì)引起路由器需要不斷地接收從運(yùn)營(yíng)商SBC發(fā)送到大量的NOTIFY消息，這樣可能會(huì)導(dǎo)致公司內(nèi)網(wǎng)的不穩(wěn)定。關(guān)于ALG和SBC的解決方案介紹我們會(huì)在下一個(gè)講座中專門介紹這些內(nèi)容。
總結(jié)，在本章節(jié)中，我們首先討論了關(guān)于STUN，TURN和ICE的原理和使用場(chǎng)景，同時(shí)，我們也介紹了它們之間的不同和各種在實(shí)際場(chǎng)景中所支持的功能和其局限性。另外，我們重點(diǎn)介紹了ICE的幾個(gè)協(xié)商流程，最后多兩個(gè)通常使用的NAT概念做了描述和介紹。ICE本身集合了STUN，TURN的各自的優(yōu)勢(shì)，在解決NAT方面可能是目前一種最佳的利器，但是因?yàn)榫W(wǎng)絡(luò)環(huán)境不斷變化，終端客戶的設(shè)備類型也不斷升級(jí)，所以ICE的技術(shù)應(yīng)用仍然在不斷升級(jí)來(lái)支持更多的要求。用戶需要根據(jù)自身特點(diǎn)，網(wǎng)絡(luò)資源，本身成本等不同方式來(lái)解決NAT問(wèn)題。
參考資料：
http://manoftoday.wdfiles.com/local--files/nat/SIPNATtraversal.pdf
https://medium.com/the-making-of-appear-in/webrtc-and-turn-latency-around-the-world-4d172dd59e8e
https://bloggeek.me/turn-public-ip-address/
關(guān)注我們的公眾微信號(hào)：asterisk-cn 獲得更多有價(jià)值的開(kāi)源通信行業(yè)分享，訪問(wèn)技術(shù)論壇獲得關(guān)于開(kāi)源IPPBX的幫助和下載：www.issabel.cn/forum
