軟交換網(wǎng)絡(luò)中的NAT穿透技術(shù)研究
引言
隨著軟交換網(wǎng)絡(luò)逐步從試驗走向商用,軟交換網(wǎng)絡(luò)的業(yè)務(wù)應(yīng)用也逐漸被人們所關(guān)注。軟交換業(yè)務(wù)的最大優(yōu)勢在于其可為用戶提供豐富的業(yè)務(wù),特別是為企業(yè)用戶提供語音、數(shù)據(jù)、視頻融合的業(yè)務(wù)。目前其走向成熟并商用的業(yè)務(wù)主要是在IP網(wǎng)上承載語音和視頻業(yè)務(wù)。即是多媒體通信系統(tǒng)標(biāo)準(zhǔn)H.323,SIP,MGCP協(xié)議運用于視頻會議和IP電話中。
1 網(wǎng)絡(luò)地址端口轉(zhuǎn)換(NAPT)技術(shù)簡介
在當(dāng)今的網(wǎng)絡(luò)世界里,使用私有IP地址的網(wǎng)絡(luò)設(shè)備的數(shù)量要遠(yuǎn)遠(yuǎn)大于擁有合法IP地址的設(shè)備數(shù)量。為了能夠讓這些設(shè)備可以訪問私網(wǎng)外部的資源,NAT(網(wǎng)絡(luò)地址轉(zhuǎn)換)技術(shù)也就應(yīng)運而生。當(dāng)私網(wǎng)內(nèi)部設(shè)備試圖訪問外部網(wǎng)絡(luò)時,NAT技術(shù)就可以將其私有的IP地址轉(zhuǎn)換成合法的IP地址。NAT與PAT被同時使用,稱為網(wǎng)絡(luò)地址端口轉(zhuǎn)換(NAPT)。NAPT的運用,緩解了IPv4構(gòu)架下Internet網(wǎng)絡(luò)的IP地址緊張問題,提高私有網(wǎng)絡(luò)內(nèi)部的安全性和可管理性。因此.NAPT被大量運用到各種私網(wǎng)網(wǎng)關(guān)設(shè)備上,它是絕大多數(shù)網(wǎng)絡(luò)路由器設(shè)備的一個基本功能,也是網(wǎng)絡(luò)防火墻功能的重要組成部分。
2 NAPT對軟交換的影響
2.1 NAT問題
圖1所示是一個軟交換網(wǎng)絡(luò)示意圖?,F(xiàn)在假設(shè)有一個如圖1所示的軟交換網(wǎng)絡(luò),在這個網(wǎng)絡(luò)中,終端A與終端B在私網(wǎng)內(nèi),只有私網(wǎng)IP地址,而終端C具有獨立的合法IP地址。為了便于描述,假設(shè)所有終端都是SIP終端,軟交換與終端間的通訊也釆用標(biāo)準(zhǔn)的SIP協(xié)議。這樣,若終端A向終端B發(fā)起呼叫請求,則會產(chǎn)生一個如圖2所示的消息包,這個消息包在經(jīng)過路由器的NAPT后,會變成圖3所示的消息包,其中1050為NAPT動態(tài)分配的端口號。
由于終端B在向軟交換注冊時,通過SIP協(xié)議層的注冊消息告訴軟交換的是它的私有地址,并且在終端B沒有主動對外發(fā)起連接請求時,防火墻不會為其分配可被訪問的IP地址和端口號,因此,軟交換根本無法將INVITE消息發(fā)送給終端B,因而呼叫無法接續(xù)。
2.2 PAT問題
假設(shè)由終端A向終端C發(fā)起呼叫,此時,由于終端C上面沒有防火墻或路由器,軟交換就可以順利地把INVITE消息包轉(zhuǎn)發(fā)到終端C,這個消息中攜帶有SDP信息,可用于終端間的媒體協(xié)商。媒體協(xié)商的主要目的是選擇合適的編解碼器,并建立RTP媒體流的連接。由終端A發(fā)送的INVITE消息中攜帶的SDP信息內(nèi)容如圖4所示,其中10006是終端A建立RTP連接的端口號。
當(dāng)終端C收到SDP信息后,它將試圖與192.168.0.3:10006建立RTP連接,很明顯,這是一個私網(wǎng)內(nèi)部的地址,因此,通話也自然無法建立起來。
從以上分析可以看出,NAPT影響軟交換通信主要有兩方面:一方面,私網(wǎng)內(nèi)設(shè)備都采用內(nèi)部IP地址,雖然經(jīng)過NAPT可以將IP層的地址轉(zhuǎn)換為外部地址,但是對更上面的應(yīng)用層消息中的私有IP地址卻無能為力(稱作NAT問題);另一方面,私網(wǎng)設(shè)備只是在向外部主動發(fā)起連接時,才會被分配到合法IP和端口號。若不做特殊處理,設(shè)備對外部網(wǎng)絡(luò)來說是不可見的,也無法接受軟交換發(fā)來的呼叫請求(這個可以稱作PAT問題)?;赟IP協(xié)議的問題如此,當(dāng)軟交換與終端間使用其它協(xié)議(如H.323,MGCP或H.248協(xié)議)時,類似的問題也同樣存在。
2.3 防火墻和NAT對IP語音和視頻通訊的阻礙
基于IP的語音和視頻通訊協(xié)議(如H.323等),要求終端之間使用IP地址和數(shù)據(jù)端口來建立數(shù)據(jù)通信通道。這樣,為了建立數(shù)據(jù)連接終端,必須隨時偵聽外來的呼叫,而防火墻卻通常被配置成阻止任何不請自到的數(shù)據(jù)包的通過。
即使網(wǎng)絡(luò)管理者打開防火墻上的一個端口來接收呼叫建立數(shù)據(jù)包,例如1720端口,但I(xiàn)P語音和視頻通訊協(xié)議還要求打開許多別的端口接收呼叫控制信息來建立語音和視頻通道,這些端口號事先并不知道,系統(tǒng)是動態(tài)分配的,這也就是說,網(wǎng)絡(luò)管理者為了允許語音和視頻通訊將不得不打開防火墻上所有的端口,防火墻也就失去了存在的意義。由于網(wǎng)絡(luò)安全的原因,幾乎所有企業(yè)都不會讓他們的網(wǎng)絡(luò)防火墻如此開放。
基于目前情況,業(yè)界常用的解決方案有:NAT/ALG方式、MIDCOM方式、STUN方式、TURN方式、Full Proxy方式和SBC等六種。
下面針對企業(yè)網(wǎng)、駐地網(wǎng)小區(qū)用戶接入軟交換網(wǎng)絡(luò)解決方案,對上述幾種方式進行簡單介紹和分析。
3 方案分析
3.1 NAT/ALG方式
普通NAT通常通過修改UDP或TCP報文頭部地址信息來實現(xiàn)地址的轉(zhuǎn)換,但部分承載于TCP/UDP的應(yīng)用,例如多媒體會話、文件共享、游戲等“端到端”的應(yīng)用,在TCP/UDP負(fù)載中也需帶地址信息。一般的方法中,應(yīng)用程序在負(fù)載中填寫的是自身地址,此地址信息在通過NAT時被修改為NAT上對外的地址,即我們常說的ALG方式。
ALG功能目前主要駐留在一些NAT/Firewall設(shè)備中,要求這些設(shè)備本身具備應(yīng)用識別的智能,同時每增加一種新的應(yīng)用,都需要對NAT/Firewall進行升級。
對于軟交換業(yè)務(wù)應(yīng)用,ALG需要支持IP語音和視頻協(xié)議(H323、SIP、MGCP/H248)的識別和對NAT/Firewall的控制,以使軟交換業(yè)務(wù)順利穿透NAT/Firewall
對于ALG應(yīng)用來說,在應(yīng)用業(yè)務(wù)安全要求上需要作一些折衷,因為ALG不能識別加密后的報文內(nèi)容,所以必須保證報文采用明文傳送,這使得報文在公網(wǎng)中傳送時有很大的安全隱患。
3.2 MIDCOM方式
與NAT/ALG不同的是,MIDCOM的框架結(jié)構(gòu)是采用可信的第三方(MIDCOMAgent)對Middle-box(NAT/FW)進行控制的機制,應(yīng)用業(yè)務(wù)識別的智能也由Middlebox轉(zhuǎn)移到外部的MIDCOMAgent上,因此,應(yīng)用協(xié)議對Middlebox是透明的。
由于應(yīng)用業(yè)務(wù)識別的智能可以從Middlebox移到外部的MIDCOMAgent上,根據(jù)MIDCOM的架構(gòu),在不需要更改Middlebox基本特性的基礎(chǔ)上,通過對MIDCOMAgent的升級就可以支持更多的新業(yè)務(wù),這是NAT/ALG方式的一個優(yōu)勢。
在軟交換業(yè)務(wù)實際應(yīng)用中,Middlebox功能可駐留NAT/Firewall,因此,通過軟交換設(shè)備(即MID-COMAgent)對IP語音和視頻協(xié)議(H323、SIP、MGCP/H248)的識別和對NAT/Firewall的控制,就可以作為軟交換業(yè)務(wù)穿越NAT/Firewall的一個解決方案。
出于安全性考慮,MIDCOM方式可支持控制報文的加密,也可支持媒體流的加密,因此,其安全性比較高。
由于軟交換設(shè)備已實現(xiàn)了對SIP/H323/MGCP/H248協(xié)議的識別,只需在軟交換和NAT/FW設(shè)備上增加MIDCOM協(xié)議即可,而且以后新的應(yīng)用業(yè)務(wù)識別隨著軟交換的支持而支持,因此,這種方案是一種比較有前途的解決方案。但是,現(xiàn)有的NAT/FW設(shè)備需要升級支持MIDCOM協(xié)議。
3.3 STUN方式
解決軟交換NAT問題的另一思路是私網(wǎng)接入用戶可通過某種機制預(yù)先得到其地址對應(yīng)的、在出口NAT上的對外地址,然后在報文負(fù)載中所描述的地址信息直接填寫出口NAT上的對外地址,而不是私網(wǎng)內(nèi)用戶的私有IP地址,這樣,報文負(fù)載中的內(nèi)容在經(jīng)過NAT時就無需被修改了,只需按普通NAT流程轉(zhuǎn)換報文頭的IP地址即可,負(fù)載中的IP地址信息和報文頭地址信息是一致的。STUN協(xié)議就是基于此思路來解決應(yīng)用層地址的轉(zhuǎn)換問題。
STUN的全稱是Simple Traversal of UDP Through Network Address Translators,即UDP對NAT的簡單穿越方式。應(yīng)用程序(即STUN CLI-ENT)向NAT外的STUN SERVER可通過UDP發(fā)送請求STUN消息,STUN SERVER收到請求消息后將產(chǎn)生響應(yīng)消息,響應(yīng)消息中攜帶請求消息的源端口,即STUN CLIENT在NAT上對應(yīng)的外部端口。然后,響應(yīng)消息通過NAT發(fā)送給STUN CLI-ENT,STUN CLIENT通過響應(yīng)消息體中的內(nèi)容得知其在NAT上對應(yīng)的外部地址,并且將其填入以后呼叫協(xié)議的UDP負(fù)載中并告知對端,本端的RTP接收地址和端口號為NAT外的地址和端口號。由于通過STUN協(xié)議已在NAT上預(yù)先建立了媒體流的NAT映射表項,故媒體流可順利穿越NAT。
STUN協(xié)議最大的優(yōu)點是無需現(xiàn)有NAT/FW設(shè)備做任何改動。由于實際的網(wǎng)絡(luò)環(huán)境中已有大量的NAT/FW,并且這些NAT/FW并不支持VoIP的應(yīng)用,因此,如果用MIDCOM或NAT/ALG方式來解決此問題,需要替換現(xiàn)有的NAT/FW,故是不太容易的。而采用STUN方式無需改動NAT/FW,這是其最大優(yōu)勢,同時-STUN方式可在多個NAT串聯(lián)的網(wǎng)絡(luò)環(huán)境中使用,而MIDCOM方式無法實現(xiàn)對多級NAT的有效控制。
STUN的局限性在于需要應(yīng)用程序支持STUNCLIENT的功能,即軟交換的網(wǎng)絡(luò)終端需具備STUNClient功能。同時STUN并不適合支持TCP連接的穿越,因此不支持H323應(yīng)用協(xié)議。另外,STUN方式也不支持軟交換業(yè)務(wù)對防火墻的穿越,同時,STUN方式不支持對對稱NAT(SymmetricNAT)類型的穿越,例如在安全性要求較高的企業(yè)網(wǎng)中,出口NAT通常就是這種類型。
3.4 TURN方式
TURN方式解決NAT問題的思路與STUN相似,也是基于私網(wǎng)接入用戶通過某種機制預(yù)先得到其私有地址對應(yīng)在公網(wǎng)的地址(STUN方式得到的地址為出口NAT上的地址,TURN方式得到地址為TURNServer上的地址),然后把報文負(fù)載中所描述的地址信息直接填寫在該公網(wǎng)地址的方式,其實際應(yīng)用原理也是一樣的。
TURN的全稱為TraversalUsingRelayNAT,即通過Relay方式穿越NAT,TURN應(yīng)用模型通過分配TURNServer的地址和端口來作為客戶端對外的接受地址和端口,即私網(wǎng)用戶發(fā)出的報文都要經(jīng)過TURNServer進行Relay轉(zhuǎn)發(fā),這種方式的應(yīng)用模型除了具有STUN方式的優(yōu)點外,還解決了STUN應(yīng)用無法穿透對稱NAT(SymmetricNAT)以及類似的Firewall設(shè)備的缺陷,即無論企業(yè)網(wǎng)/駐地網(wǎng)出口為哪種類型的NAT/FW,都可以實現(xiàn)NAT的穿透,同時,TURN可支持基于TCP的應(yīng)用(如H323協(xié)議)。此外TURNServer可控制分配地址和端口,并能分配RTP/RTCP地址對(RTCP端口號為RTP端口號加1)作為本端客戶的接受地址,從而避免了STUN應(yīng)用模型下出口NAT對RTP/RTCP地址端口號的任意分配,這樣,客戶端將無法收到對端發(fā)過來的RTCP報文(對端發(fā)RTCP報文時,目的端口號缺省按RTP端口號加1發(fā)送)。
TURN的局限性在于其需要終端支持TURN-Client,這一點同STUN一樣,也對網(wǎng)絡(luò)終端有要求。此外,所有報文都必須經(jīng)過TURNServer轉(zhuǎn)發(fā),因而,增大了包的延遲和丟包的可能性。
3.5 FullProxy方式
FullProxy是另外一種解決NAT問題的思路,它通過對私網(wǎng)內(nèi)用戶呼叫的信令和媒體同時做Re-lay來實現(xiàn)出口NAT/FW的穿越,F(xiàn)ullproxy與TURN方式的Relay相比,區(qū)別如下:
首先,TURN方式是在TURNServer與終端通過TURN/STUN協(xié)議交互時分配地址和端口,報文內(nèi)部的地址信息由終端生成,TURNServer對后續(xù)的報文根據(jù)分配的地址和端口信息做地址變換后Re-lay轉(zhuǎn)發(fā);而FullProxy方式是通過對報文進行Relay的設(shè)備對呼叫協(xié)議進行解析與處理來改寫其中攜帶的RTP/RTCP地址信息后轉(zhuǎn)發(fā)信令報文,同時根據(jù)改寫的RTP/RTCP地址信息對媒體報文做地址變換后進行Relay轉(zhuǎn)發(fā)。原理在于當(dāng)私網(wǎng)終端呼叫信令到達(dá)FullProxy時,FullProxy將對呼叫信令協(xié)議進行解析,并對協(xié)議中攜帶的RTP/RTCP信息進行解析與處理,然后在記錄用戶私網(wǎng)內(nèi)RTP/RTCP地址和端口號的同時,修改RTP/RTCP私網(wǎng)地址信息為FullProxy本身對外的公網(wǎng)IP地址,同時修改媒體流端口為FullProxy上分配的外部端口,最后將呼叫信令發(fā)送到軟交換或?qū)Χ?。這樣,呼叫信令以及媒體流就可以通過FullProxy在主被叫之間進行中轉(zhuǎn)。由于FullProxy可以配置多個IP地址(如一個私網(wǎng)IP地址和一個公網(wǎng)IP地址),因此通過FullProxy進行Relay,其軟交換業(yè)務(wù)就可順利通過NAT/FW.
FullProxy方式無需現(xiàn)有NAT做任何改動即可開展軟交換業(yè)務(wù),也可采用普通的設(shè)備,同時私網(wǎng)內(nèi)的終端也無需支持STUN和TURN協(xié)議,這是其一個較大的優(yōu)勢。其局限性同TURN一樣,也是增加了包的延時和丟包的可能性。
由于FullProxy方式會對呼叫協(xié)議進行解析,因此,除了可以處理NAT問題外,還可完成對每次呼叫帶寬等QoS信息的解析與處理,從接入層保證QoS的安全問題。此外,通過對呼叫狀態(tài)的把握,可實現(xiàn)對媒體流的動態(tài)防火墻,保證網(wǎng)絡(luò)安全和防止帶寬盜用等。因此,FullProxy模型可以成為軟交換終端接入層NAT,QoS和安全的統(tǒng)一處理平臺。
在應(yīng)用領(lǐng)域,由于FullProxy的配置很靈活,組網(wǎng)應(yīng)用也很靈活,它除了實現(xiàn)私網(wǎng)地址向公網(wǎng)地址的轉(zhuǎn)換外,還可同時實現(xiàn)公網(wǎng)地址向私網(wǎng)地址的轉(zhuǎn)換,或其它不同地址域之間的變換,以便滿足軟交換不同場合下的組網(wǎng)應(yīng)用。
3.6 SBC(Session Border Controller)方式
SBC本身可以被看作支持VoIP的Proxy,它是一種“可識別應(yīng)用層”的設(shè)備,可以識別第五層和第七層的消息,并且可以處理第五層的眾多會話信令協(xié)議,修改數(shù)據(jù)包頭的地址,從而實現(xiàn)SBC內(nèi)、外網(wǎng)地址和變換。
SBC可以用于協(xié)助VoIP穿越遠(yuǎn)端防火墻/NAT設(shè)備。它一般放置在網(wǎng)絡(luò)核心交換設(shè)備之側(cè)。所有經(jīng)過SBC的信令和媒體流經(jīng)過SBC的協(xié)調(diào)和修改,均可以在系統(tǒng)側(cè)和用戶側(cè)正確傳輸。用戶側(cè)的NAT/Firewall可以接受這種修改后的信令和媒體流并把他們傳送到用戶側(cè)的內(nèi)網(wǎng)。這種利用SBC實現(xiàn)的防火墻穿越技術(shù)可以稱之為“遠(yuǎn)端防火墻穿越”。
SBC還可以幫助SIP/MGCP信令穿越已經(jīng)存在的FW/NAT,而不需要對現(xiàn)有的FW/NAT設(shè)備做任何改變。具體來說,對于SIP終端,SIP終端設(shè)備會周期性發(fā)注冊消息到SBC;而對于MGCP終端,當(dāng)收到MGCP設(shè)備的第一個注冊消息后,SBC會周期性發(fā)AUEP消息到終端,以強制其再不停的周期性回復(fù)200OK消息。這樣,由于不停的有信令消息經(jīng)過防火墻/NAT設(shè)備,可能使防火墻/NAT對通過的消息流始終保持一個確定的端口;同時,當(dāng)注冊信息經(jīng)過SBC時,它將記錄在防火墻上的第三層IP地址和端口等信息,并且將此信息與防火墻后面的終端用戶名或電話號碼等第五層信息進行綁定記錄。這樣,當(dāng)一個信令到來后,SBC將通過防火墻上正確的地址和端口發(fā)送給被叫方。
當(dāng)呼叫建立后,雙向的媒體流端口都是動態(tài)建立的。由于媒體流同樣也通過SBC,而SBC將通過與該媒體流相關(guān)的呼叫(第五層消息中的用戶名或電話號碼)來識別防火墻上的IP地址和端口。因此,SBC可以把相應(yīng)的媒體流發(fā)送到防火墻上的相關(guān)IP地址和端口,然后正確地使媒體流到達(dá)防火墻后的用戶側(cè)。
SBC本身可以被看作支持VoIP的防火墻,不過它們不僅僅有此功能。它們還可以修改IP包的包頭,使IP包能夠順利通過網(wǎng)絡(luò)邊緣設(shè)備(如:FW或NAT)。SBC是一種“可識別應(yīng)用層”的設(shè)備,它可以識別第五層和第七層的消息,并且可以處理第五層的眾多會話信令協(xié)議,修改數(shù)據(jù)包頭的地址,從而實現(xiàn)“遠(yuǎn)端防火墻穿越”。同時,SBC可以通過對會話數(shù)目的限制來實現(xiàn)應(yīng)用層防D.O.S.攻擊。
4 結(jié)語
根據(jù)本文的介紹和對比分析,筆者推薦采用FullProxy和MIDCOM兩種解決方案。因為Full-Proxy方式由于不用對運營商和客戶端的現(xiàn)有網(wǎng)絡(luò)設(shè)備進行任何改造,并具有很強的適應(yīng)性,而且組網(wǎng)靈活,可滿足軟交換網(wǎng)絡(luò)初期多樣化的組網(wǎng)和用戶接入。FullProxy除了可解決NAT問題夕卜,功能還可以大大擴展,同時可完成在接入層實現(xiàn)對會話業(yè)務(wù)QoS和安全的處理,故可發(fā)展成為軟交換網(wǎng)絡(luò)的用戶接入平臺。
MIDCOM方式具有很強的擴展性,一旦NAT/FW設(shè)備支持MIDCOM協(xié)議,MIDCOMAgent便可內(nèi)嵌于軟交換中,可一勞永逸地解決軟交換業(yè)務(wù)的NAT/FW穿透問題,同時由于軟交換自身對用戶呼叫協(xié)議的解析與處理,同樣能動態(tài)下發(fā)呼叫的QoS和安全信息,以便下面的Middlebox(NAT/FW)設(shè)備根據(jù)這些信息采取必要的保證措施。但是,由于目前網(wǎng)上大量的NAT/FW設(shè)備不支持MIDCOM功能,因而需要對設(shè)備進行修改,同時在軟交換網(wǎng)絡(luò)應(yīng)用初期,其軟交換設(shè)備布點數(shù)量過少,網(wǎng)絡(luò)層次較高,也影響了這種方式在現(xiàn)有網(wǎng)絡(luò)情況下的應(yīng)用。