軟交換網(wǎng)絡(luò)中的NAT穿透技術(shù)研究

引言

隨著軟交換網(wǎng)絡(luò)逐步從試驗(yàn)走向商用，軟交換網(wǎng)絡(luò)的業(yè)務(wù)應(yīng)用也逐漸被人們所關(guān)注。軟交換業(yè)務(wù)的最大優(yōu)勢(shì)在于其可為用戶(hù)提供豐富的業(yè)務(wù)，特別是為企業(yè)用戶(hù)提供語(yǔ)音、數(shù)據(jù)、視頻融合的業(yè)務(wù)。目前其走向成熟并商用的業(yè)務(wù)主要是在IP網(wǎng)上承載語(yǔ)音和視頻業(yè)務(wù)。即是多媒體通信系統(tǒng)標(biāo)準(zhǔn)H.323,SIP,MGCP協(xié)議運(yùn)用于視頻會(huì)議和IP電話(huà)中。

1  網(wǎng)絡(luò)地址端口轉(zhuǎn)換（NAPT）技術(shù)簡(jiǎn)介

在當(dāng)今的網(wǎng)絡(luò)世界里，使用私有IP地址的網(wǎng)絡(luò)設(shè)備的數(shù)量要遠(yuǎn)遠(yuǎn)大于擁有合法IP地址的設(shè)備數(shù)量。為了能夠讓這些設(shè)備可以訪(fǎng)問(wèn)私網(wǎng)外部的資源，NAT（網(wǎng)絡(luò)地址轉(zhuǎn)換）技術(shù)也就應(yīng)運(yùn)而生。當(dāng)私網(wǎng)內(nèi)部設(shè)備試圖訪(fǎng)問(wèn)外部網(wǎng)絡(luò)時(shí)，NAT技術(shù)就可以將其私有的IP地址轉(zhuǎn)換成合法的IP地址。NAT與PAT被同時(shí)使用，稱(chēng)為網(wǎng)絡(luò)地址端口轉(zhuǎn)換（NAPT）。NAPT的運(yùn)用，緩解了IPv4構(gòu)架下Internet網(wǎng)絡(luò)的IP地址緊張問(wèn)題，提高私有網(wǎng)絡(luò)內(nèi)部的安全性和可管理性。因此.NAPT被大量運(yùn)用到各種私網(wǎng)網(wǎng)關(guān)設(shè)備上，它是絕大多數(shù)網(wǎng)絡(luò)路由器設(shè)備的一個(gè)基本功能，也是網(wǎng)絡(luò)防火墻功能的重要組成部分。

2  NAPT對(duì)軟交換的影響

2.1  NAT問(wèn)題

圖1所示是一個(gè)軟交換網(wǎng)絡(luò)示意圖?，F(xiàn)在假設(shè)有一個(gè)如圖1所示的軟交換網(wǎng)絡(luò),在這個(gè)網(wǎng)絡(luò)中，終端A與終端B在私網(wǎng)內(nèi)，只有私網(wǎng)IP地址，而終端C具有獨(dú)立的合法IP地址。為了便于描述，假設(shè)所有終端都是SIP終端，軟交換與終端間的通訊也釆用標(biāo)準(zhǔn)的SIP協(xié)議。這樣,若終端A向終端B發(fā)起呼叫請(qǐng)求，則會(huì)產(chǎn)生一個(gè)如圖2所示的消息包，這個(gè)消息包在經(jīng)過(guò)路由器的NAPT后，會(huì)變成圖3所示的消息包，其中1050為NAPT動(dòng)態(tài)分配的端口號(hào)。

由于終端B在向軟交換注冊(cè)時(shí)，通過(guò)SIP協(xié)議層的注冊(cè)消息告訴軟交換的是它的私有地址,并且在終端B沒(méi)有主動(dòng)對(duì)外發(fā)起連接請(qǐng)求時(shí)，防火墻不會(huì)為其分配可被訪(fǎng)問(wèn)的IP地址和端口號(hào)，因此，軟交換根本無(wú)法將INVITE消息發(fā)送給終端B,因而呼叫無(wú)法接續(xù)。

2.2  PAT問(wèn)題

假設(shè)由終端A向終端C發(fā)起呼叫，此時(shí)，由于終端C上面沒(méi)有防火墻或路由器，軟交換就可以順利地把INVITE消息包轉(zhuǎn)發(fā)到終端C,這個(gè)消息中攜帶有SDP信息,可用于終端間的媒體協(xié)商。媒體協(xié)商的主要目的是選擇合適的編解碼器，并建立RTP媒體流的連接。由終端A發(fā)送的INVITE消息中攜帶的SDP信息內(nèi)容如圖4所示，其中10006是終端A建立RTP連接的端口號(hào)。

當(dāng)終端C收到SDP信息后，它將試圖與192.168.0.3：10006建立RTP連接,很明顯，這是一個(gè)私網(wǎng)內(nèi)部的地址，因此，通話(huà)也自然無(wú)法建立起來(lái)。

從以上分析可以看出,NAPT影響軟交換通信主要有兩方面:一方面，私網(wǎng)內(nèi)設(shè)備都采用內(nèi)部IP地址，雖然經(jīng)過(guò)NAPT可以將IP層的地址轉(zhuǎn)換為外部地址，但是對(duì)更上面的應(yīng)用層消息中的私有IP地址卻無(wú)能為力（稱(chēng)作NAT問(wèn)題）；另一方面，私網(wǎng)設(shè)備只是在向外部主動(dòng)發(fā)起連接時(shí)，才會(huì)被分配到合法IP和端口號(hào)。若不做特殊處理，設(shè)備對(duì)外部網(wǎng)絡(luò)來(lái)說(shuō)是不可見(jiàn)的，也無(wú)法接受軟交換發(fā)來(lái)的呼叫請(qǐng)求（這個(gè)可以稱(chēng)作PAT問(wèn)題）。基于SIP協(xié)議的問(wèn)題如此，當(dāng)軟交換與終端間使用其它協(xié)議（如H.323,MGCP或H.248協(xié)議）時(shí)，類(lèi)似的問(wèn)題也同樣存在。

2.3  防火墻和NAT對(duì)IP語(yǔ)音和視頻通訊的阻礙

基于IP的語(yǔ)音和視頻通訊協(xié)議（如H.323等），要求終端之間使用IP地址和數(shù)據(jù)端口來(lái)建立數(shù)據(jù)通信通道。這樣，為了建立數(shù)據(jù)連接終端，必須隨時(shí)偵聽(tīng)外來(lái)的呼叫，而防火墻卻通常被配置成阻止任何不請(qǐng)自到的數(shù)據(jù)包的通過(guò)。

即使網(wǎng)絡(luò)管理者打開(kāi)防火墻上的一個(gè)端口來(lái)接收呼叫建立數(shù)據(jù)包，例如1720端口，但I(xiàn)P語(yǔ)音和視頻通訊協(xié)議還要求打開(kāi)許多別的端口接收呼叫控制信息來(lái)建立語(yǔ)音和視頻通道，這些端口號(hào)事先并不知道，系統(tǒng)是動(dòng)態(tài)分配的，這也就是說(shuō)，網(wǎng)絡(luò)管理者為了允許語(yǔ)音和視頻通訊將不得不打開(kāi)防火墻上所有的端口，防火墻也就失去了存在的意義。由于網(wǎng)絡(luò)安全的原因，幾乎所有企業(yè)都不會(huì)讓他們的網(wǎng)絡(luò)防火墻如此開(kāi)放。

基于目前情況，業(yè)界常用的解決方案有:NAT/ALG方式、MIDCOM方式、STUN方式、TURN方式、Full Proxy方式和SBC等六種。

下面針對(duì)企業(yè)網(wǎng)、駐地網(wǎng)小區(qū)用戶(hù)接入軟交換網(wǎng)絡(luò)解決方案，對(duì)上述幾種方式進(jìn)行簡(jiǎn)單介紹和分析。

3  方案分析

3.1  NAT/ALG方式

普通NAT通常通過(guò)修改UDP或TCP報(bào)文頭部地址信息來(lái)實(shí)現(xiàn)地址的轉(zhuǎn)換,但部分承載于TCP/UDP的應(yīng)用，例如多媒體會(huì)話(huà)、文件共享、游戲等“端到端”的應(yīng)用，在TCP/UDP負(fù)載中也需帶地址信息。一般的方法中，應(yīng)用程序在負(fù)載中填寫(xiě)的是自身地址，此地址信息在通過(guò)NAT時(shí)被修改為NAT上對(duì)外的地址，即我們常說(shuō)的ALG方式。

ALG功能目前主要駐留在一些NAT/Firewall設(shè)備中，要求這些設(shè)備本身具備應(yīng)用識(shí)別的智能，同時(shí)每增加一種新的應(yīng)用，都需要對(duì)NAT/Firewall進(jìn)行升級(jí)。

對(duì)于軟交換業(yè)務(wù)應(yīng)用,ALG需要支持IP語(yǔ)音和視頻協(xié)議（H323、SIP、MGCP/H248）的識(shí)別和對(duì)NAT/Firewall的控制，以使軟交換業(yè)務(wù)順利穿透NAT/Firewall

對(duì)于ALG應(yīng)用來(lái)說(shuō)，在應(yīng)用業(yè)務(wù)安全要求上需要作一些折衷，因?yàn)锳LG不能識(shí)別加密后的報(bào)文內(nèi)容，所以必須保證報(bào)文采用明文傳送，這使得報(bào)文在公網(wǎng)中傳送時(shí)有很大的安全隱患。

3.2  MIDCOM方式

與NAT/ALG不同的是,MIDCOM的框架結(jié)構(gòu)是采用可信的第三方（MIDCOMAgent）對(duì)Middle-box（NAT/FW）進(jìn)行控制的機(jī)制，應(yīng)用業(yè)務(wù)識(shí)別的智能也由Middlebox轉(zhuǎn)移到外部的MIDCOMAgent上，因此，應(yīng)用協(xié)議對(duì)Middlebox是透明的。

由于應(yīng)用業(yè)務(wù)識(shí)別的智能可以從Middlebox移到外部的MIDCOMAgent上，根據(jù)MIDCOM的架構(gòu)，在不需要更改Middlebox基本特性的基礎(chǔ)上，通過(guò)對(duì)MIDCOMAgent的升級(jí)就可以支持更多的新業(yè)務(wù),這是NAT/ALG方式的一個(gè)優(yōu)勢(shì)。

在軟交換業(yè)務(wù)實(shí)際應(yīng)用中，Middlebox功能可駐留NAT/Firewall,因此，通過(guò)軟交換設(shè)備（即MID-COMAgent）對(duì)IP語(yǔ)音和視頻協(xié)議（H323、SIP、MGCP/H248）的識(shí)別和對(duì)NAT/Firewall的控制，就可以作為軟交換業(yè)務(wù)穿越NAT/Firewall的一個(gè)解決方案。

出于安全性考慮,MIDCOM方式可支持控制報(bào)文的加密，也可支持媒體流的加密，因此，其安全性比較高。

由于軟交換設(shè)備已實(shí)現(xiàn)了對(duì)SIP/H323/MGCP/H248協(xié)議的識(shí)別，只需在軟交換和NAT/FW設(shè)備上增加MIDCOM協(xié)議即可，而且以后新的應(yīng)用業(yè)務(wù)識(shí)別隨著軟交換的支持而支持，因此，這種方案是一種比較有前途的解決方案。但是，現(xiàn)有的NAT/FW設(shè)備需要升級(jí)支持MIDCOM協(xié)議。

3.3  STUN方式

解決軟交換NAT問(wèn)題的另一思路是私網(wǎng)接入用戶(hù)可通過(guò)某種機(jī)制預(yù)先得到其地址對(duì)應(yīng)的、在出口NAT上的對(duì)外地址，然后在報(bào)文負(fù)載中所描述的地址信息直接填寫(xiě)出口NAT上的對(duì)外地址，而不是私網(wǎng)內(nèi)用戶(hù)的私有IP地址，這樣，報(bào)文負(fù)載中的內(nèi)容在經(jīng)過(guò)NAT時(shí)就無(wú)需被修改了，只需按普通NAT流程轉(zhuǎn)換報(bào)文頭的IP地址即可，負(fù)載中的IP地址信息和報(bào)文頭地址信息是一致的。STUN協(xié)議就是基于此思路來(lái)解決應(yīng)用層地址的轉(zhuǎn)換問(wèn)題。

STUN的全稱(chēng)是Simple Traversal of UDP Through Network Address Translators,即UDP對(duì)NAT的簡(jiǎn)單穿越方式。應(yīng)用程序（即STUN CLI-ENT）向NAT外的STUN SERVER可通過(guò)UDP發(fā)送請(qǐng)求STUN消息,STUN SERVER收到請(qǐng)求消息后將產(chǎn)生響應(yīng)消息，響應(yīng)消息中攜帶請(qǐng)求消息的源端口，即STUN CLIENT在NAT上對(duì)應(yīng)的外部端口。然后，響應(yīng)消息通過(guò)NAT發(fā)送給STUN CLI-ENT,STUN CLIENT通過(guò)響應(yīng)消息體中的內(nèi)容得知其在NAT上對(duì)應(yīng)的外部地址，并且將其填入以后呼叫協(xié)議的UDP負(fù)載中并告知對(duì)端，本端的RTP接收地址和端口號(hào)為NAT外的地址和端口號(hào)。由于通過(guò)STUN協(xié)議已在NAT上預(yù)先建立了媒體流的NAT映射表項(xiàng),故媒體流可順利穿越NAT。

STUN協(xié)議最大的優(yōu)點(diǎn)是無(wú)需現(xiàn)有NAT/FW設(shè)備做任何改動(dòng)。由于實(shí)際的網(wǎng)絡(luò)環(huán)境中已有大量的NAT/FW,并且這些NAT/FW并不支持VoIP的應(yīng)用，因此，如果用MIDCOM或NAT/ALG方式來(lái)解決此問(wèn)題，需要替換現(xiàn)有的NAT/FW,故是不太容易的。而采用STUN方式無(wú)需改動(dòng)NAT/FW,這是其最大優(yōu)勢(shì)，同時(shí)-STUN方式可在多個(gè)NAT串聯(lián)的網(wǎng)絡(luò)環(huán)境中使用，而MIDCOM方式無(wú)法實(shí)現(xiàn)對(duì)多級(jí)NAT的有效控制。

STUN的局限性在于需要應(yīng)用程序支持STUNCLIENT的功能，即軟交換的網(wǎng)絡(luò)終端需具備STUNClient功能。同時(shí)STUN并不適合支持TCP連接的穿越，因此不支持H323應(yīng)用協(xié)議。另外，STUN方式也不支持軟交換業(yè)務(wù)對(duì)防火墻的穿越，同時(shí)，STUN方式不支持對(duì)對(duì)稱(chēng)NAT（SymmetricNAT）類(lèi)型的穿越，例如在安全性要求較高的企業(yè)網(wǎng)中，出口NAT通常就是這種類(lèi)型。

3.4  TURN方式

TURN方式解決NAT問(wèn)題的思路與STUN相似,也是基于私網(wǎng)接入用戶(hù)通過(guò)某種機(jī)制預(yù)先得到其私有地址對(duì)應(yīng)在公網(wǎng)的地址（STUN方式得到的地址為出口NAT上的地址,TURN方式得到地址為T(mén)URNServer上的地址），然后把報(bào)文負(fù)載中所描述的地址信息直接填寫(xiě)在該公網(wǎng)地址的方式，其實(shí)際應(yīng)用原理也是一樣的。

TURN的全稱(chēng)為T(mén)raversalUsingRelayNAT,即通過(guò)Relay方式穿越NAT,TURN應(yīng)用模型通過(guò)分配TURNServer的地址和端口來(lái)作為客戶(hù)端對(duì)外的接受地址和端口，即私網(wǎng)用戶(hù)發(fā)出的報(bào)文都要經(jīng)過(guò)TURNServer進(jìn)行Relay轉(zhuǎn)發(fā),這種方式的應(yīng)用模型除了具有STUN方式的優(yōu)點(diǎn)外，還解決了STUN應(yīng)用無(wú)法穿透對(duì)稱(chēng)NAT（SymmetricNAT）以及類(lèi)似的Firewall設(shè)備的缺陷，即無(wú)論企業(yè)網(wǎng)/駐地網(wǎng)出口為哪種類(lèi)型的NAT/FW,都可以實(shí)現(xiàn)NAT的穿透，同時(shí),TURN可支持基于TCP的應(yīng)用（如H323協(xié)議）。此外TURNServer可控制分配地址和端口，并能分配RTP/RTCP地址對(duì)（RTCP端口號(hào)為RTP端口號(hào)加1）作為本端客戶(hù)的接受地址，從而避免了STUN應(yīng)用模型下出口NAT對(duì)RTP/RTCP地址端口號(hào)的任意分配，這樣，客戶(hù)端將無(wú)法收到對(duì)端發(fā)過(guò)來(lái)的RTCP報(bào)文（對(duì)端發(fā)RTCP報(bào)文時(shí)，目的端口號(hào)缺省按RTP端口號(hào)加1發(fā)送）。

TURN的局限性在于其需要終端支持TURN-Client,這一點(diǎn)同STUN一樣，也對(duì)網(wǎng)絡(luò)終端有要求。此外，所有報(bào)文都必須經(jīng)過(guò)TURNServer轉(zhuǎn)發(fā)，因而,增大了包的延遲和丟包的可能性。

3.5  FullProxy方式

FullProxy是另外一種解決NAT問(wèn)題的思路，它通過(guò)對(duì)私網(wǎng)內(nèi)用戶(hù)呼叫的信令和媒體同時(shí)做Re-lay來(lái)實(shí)現(xiàn)出口NAT/FW的穿越，F(xiàn)ullproxy與TURN方式的Relay相比，區(qū)別如下：

首先,TURN方式是在TURNServer與終端通過(guò)TURN/STUN協(xié)議交互時(shí)分配地址和端口，報(bào)文內(nèi)部的地址信息由終端生成,TURNServer對(duì)后續(xù)的報(bào)文根據(jù)分配的地址和端口信息做地址變換后Re-lay轉(zhuǎn)發(fā);而FullProxy方式是通過(guò)對(duì)報(bào)文進(jìn)行Relay的設(shè)備對(duì)呼叫協(xié)議進(jìn)行解析與處理來(lái)改寫(xiě)其中攜帶的RTP/RTCP地址信息后轉(zhuǎn)發(fā)信令報(bào)文，同時(shí)根據(jù)改寫(xiě)的RTP/RTCP地址信息對(duì)媒體報(bào)文做地址變換后進(jìn)行Relay轉(zhuǎn)發(fā)。原理在于當(dāng)私網(wǎng)終端呼叫信令到達(dá)FullProxy時(shí),FullProxy將對(duì)呼叫信令協(xié)議進(jìn)行解析，并對(duì)協(xié)議中攜帶的RTP/RTCP信息進(jìn)行解析與處理，然后在記錄用戶(hù)私網(wǎng)內(nèi)RTP/RTCP地址和端口號(hào)的同時(shí)，修改RTP/RTCP私網(wǎng)地址信息為FullProxy本身對(duì)外的公網(wǎng)IP地址，同時(shí)修改媒體流端口為FullProxy上分配的外部端口，最后將呼叫信令發(fā)送到軟交換或?qū)Χ?。這樣，呼叫信令以及媒體流就可以通過(guò)FullProxy在主被叫之間進(jìn)行中轉(zhuǎn)。由于FullProxy可以配置多個(gè)IP地址（如一個(gè)私網(wǎng)IP地址和一個(gè)公網(wǎng)IP地址），因此通過(guò)FullProxy進(jìn)行Relay,其軟交換業(yè)務(wù)就可順利通過(guò)NAT/FW.

FullProxy方式無(wú)需現(xiàn)有NAT做任何改動(dòng)即可開(kāi)展軟交換業(yè)務(wù),也可采用普通的設(shè)備，同時(shí)私網(wǎng)內(nèi)的終端也無(wú)需支持STUN和TURN協(xié)議，這是其一個(gè)較大的優(yōu)勢(shì)。其局限性同TURN一樣，也是增加了包的延時(shí)和丟包的可能性。

由于FullProxy方式會(huì)對(duì)呼叫協(xié)議進(jìn)行解析，因此,除了可以處理NAT問(wèn)題外，還可完成對(duì)每次呼叫帶寬等QoS信息的解析與處理，從接入層保證QoS的安全問(wèn)題。此外，通過(guò)對(duì)呼叫狀態(tài)的把握，可實(shí)現(xiàn)對(duì)媒體流的動(dòng)態(tài)防火墻，保證網(wǎng)絡(luò)安全和防止帶寬盜用等。因此,FullProxy模型可以成為軟交換終端接入層NAT,QoS和安全的統(tǒng)一處理平臺(tái)。

在應(yīng)用領(lǐng)域，由于FullProxy的配置很靈活，組網(wǎng)應(yīng)用也很靈活，它除了實(shí)現(xiàn)私網(wǎng)地址向公網(wǎng)地址的轉(zhuǎn)換外，還可同時(shí)實(shí)現(xiàn)公網(wǎng)地址向私網(wǎng)地址的轉(zhuǎn)換，或其它不同地址域之間的變換，以便滿(mǎn)足軟交換不同場(chǎng)合下的組網(wǎng)應(yīng)用。

3.6  SBC（Session Border Controller）方式

SBC本身可以被看作支持VoIP的Proxy,它是一種“可識(shí)別應(yīng)用層”的設(shè)備，可以識(shí)別第五層和第七層的消息，并且可以處理第五層的眾多會(huì)話(huà)信令協(xié)議,修改數(shù)據(jù)包頭的地址，從而實(shí)現(xiàn)SBC內(nèi)、外網(wǎng)地址和變換。

SBC可以用于協(xié)助VoIP穿越遠(yuǎn)端防火墻/NAT設(shè)備。它一般放置在網(wǎng)絡(luò)核心交換設(shè)備之側(cè)。所有經(jīng)過(guò)SBC的信令和媒體流經(jīng)過(guò)SBC的協(xié)調(diào)和修改，均可以在系統(tǒng)側(cè)和用戶(hù)側(cè)正確傳輸。用戶(hù)側(cè)的NAT/Firewall可以接受這種修改后的信令和媒體流并把他們傳送到用戶(hù)側(cè)的內(nèi)網(wǎng)。這種利用SBC實(shí)現(xiàn)的防火墻穿越技術(shù)可以稱(chēng)之為“遠(yuǎn)端防火墻穿越”。

SBC還可以幫助SIP/MGCP信令穿越已經(jīng)存在的FW/NAT,而不需要對(duì)現(xiàn)有的FW/NAT設(shè)備做任何改變。具體來(lái)說(shuō)，對(duì)于SIP終端,SIP終端設(shè)備會(huì)周期性發(fā)注冊(cè)消息到SBC；而對(duì)于MGCP終端，當(dāng)收到MGCP設(shè)備的第一個(gè)注冊(cè)消息后，SBC會(huì)周期性發(fā)AUEP消息到終端，以強(qiáng)制其再不停的周期性回復(fù)200OK消息。這樣，由于不停的有信令消息經(jīng)過(guò)防火墻/NAT設(shè)備，可能使防火墻/NAT對(duì)通過(guò)的消息流始終保持一個(gè)確定的端口；同時(shí)，當(dāng)注冊(cè)信息經(jīng)過(guò)SBC時(shí)，它將記錄在防火墻上的第三層IP地址和端口等信息,并且將此信息與防火墻后面的終端用戶(hù)名或電話(huà)號(hào)碼等第五層信息進(jìn)行綁定記錄。這樣，當(dāng)一個(gè)信令到來(lái)后，SBC將通過(guò)防火墻上正確的地址和端口發(fā)送給被叫方。