首頁>>>技術(shù)>>>NGN

NGN：穿越NAT/FW等私網(wǎng)的解決方案

2007/01/22

1 引言

　　目前NGN（軟交換）技術(shù)已逐步從試驗(yàn)走向商用，在應(yīng)用過程中遇到了很多實(shí)際問題，特別是NGN用戶的接入問題。NGN是一個(gè)基于分組網(wǎng)承載的網(wǎng)絡(luò)，用戶接入都是通過IP地址來尋址的。由于IP地址緊缺以及安全等各種原因，所以大量的企業(yè)網(wǎng)和駐地網(wǎng)都采用私有IP地址通過出口的NAT/FW接入公網(wǎng)。

　　NGN網(wǎng)絡(luò)最大的好處就是能為用戶提供豐富的業(yè)務(wù)，特別是為企業(yè)用戶提供語音、數(shù)據(jù)、視頻融合的IP Centrex業(yè)務(wù)，但是像H.323、SIP、MGCP、H.248等在IP上承載語音和視頻的協(xié)議的控制通道/媒體通道難以穿越傳統(tǒng)的NAT/FW設(shè)備與公網(wǎng)進(jìn)行互通，或者說目前的NAT/FW大多只是支持HTTP的數(shù)據(jù)應(yīng)用協(xié)議穿透，而無法支持這種會(huì)話型業(yè)務(wù)的控制與媒體的NAT/FW穿透，因此私網(wǎng)穿越問題的解決顯得更加迫切，成為目前NGN網(wǎng)絡(luò)業(yè)務(wù)開展的最大障礙。目前，解決這一問題的主要方案有ALG、STUN、MidCom和Proxy等。

2 穿越技術(shù)介紹

　　2.1 ALG方案

　　NAT和NAPT只能對(duì)IP報(bào)文的頭部地址和TCP/UDP頭部的端口信息進(jìn)行轉(zhuǎn)換，對(duì)于報(bào)文的數(shù)據(jù)部分可能包含IP地址或端口信息的特殊協(xié)議（如H.323、SIP、MGCP等），則無法實(shí)現(xiàn)有效的轉(zhuǎn)換，這就可能導(dǎo)致問題發(fā)生。例如，一個(gè)使用內(nèi)部IP地址的FTP服務(wù)器可能在和外網(wǎng)主機(jī)建立會(huì)話的過程中需要將自己的IP地址發(fā)送給對(duì)方，而這個(gè)地址信息是放在IP報(bào)文的數(shù)據(jù)部分，NAT無法對(duì)它進(jìn)行轉(zhuǎn)換，當(dāng)外網(wǎng)主機(jī)接收到這個(gè)私有地址并使用它，這時(shí)FTP服務(wù)器將表現(xiàn)為不可達(dá)。

　　解決這些特殊協(xié)議的NAT轉(zhuǎn)換問題的一個(gè)方法就是在NAT實(shí)現(xiàn)中采用ALG（Application Level Gateway，應(yīng)用級(jí)網(wǎng)關(guān)）功能。ALG是能夠識(shí)別指定IP協(xié)議（如H.323、SIP或MGCP）的設(shè)備。它通過與NAT交互以建立狀態(tài)，使用NAT的狀態(tài)信息來改變封裝在IP報(bào)文數(shù)據(jù)部分中的特定數(shù)據(jù)，并完成其他必需的工作以使應(yīng)用協(xié)議可以跨越不同范圍運(yùn)行。例如，一個(gè)“目的站點(diǎn)不可達(dá)”的ICMP報(bào)文，該報(bào)文數(shù)據(jù)部分包含了造成錯(cuò)誤的數(shù)據(jù)報(bào)A的首部（注意，NAT在發(fā)送A之前進(jìn)行了地址轉(zhuǎn)換，所以源地址不是內(nèi)部主機(jī)的真實(shí)地址）。如果開啟了ICMP ALG功能，在NAT轉(zhuǎn)發(fā)ICMP報(bào)文之前，它將與NAT交互，打開ICMP報(bào)文并轉(zhuǎn)換其數(shù)據(jù)部分的報(bào)文A首部的地址，使這些地址表現(xiàn)為內(nèi)部主機(jī)的確切地址形式，并完成其他一些必需工作后，由NAT降這個(gè)ICMP報(bào)文轉(zhuǎn)發(fā)出去。

　　ALG可以是單獨(dú)的連接于外網(wǎng)和內(nèi)網(wǎng)之間的設(shè)備，也可以是內(nèi)置于NAT內(nèi)的插件。

　　ALG是支持NCN應(yīng)用最簡單的方式，但由于目前網(wǎng)絡(luò)中已大量部署了不支持NCN業(yè)務(wù)應(yīng)用的NAT/FW設(shè)備，因此不推薦采用這種方式，理由如下：
  1. 目前網(wǎng)上大量的NAT/FW設(shè)備因不具備ALG能力而需要更換或升級(jí)；


  2. NGN業(yè)務(wù)的ALG生產(chǎn)廠商少，沒有一套產(chǎn)品特性需求基線；


  3. NAT/FW設(shè)備廠商一般不是IP業(yè)務(wù)領(lǐng)域的專業(yè)廠商，難以支持業(yè)務(wù)的變化（如SIP的擴(kuò)展多種多樣）；


  4. 用戶普遍希望運(yùn)營商在不改變已有網(wǎng)絡(luò)設(shè)備（NAT）的情況下就可以提供新的IP業(yè)務(wù)，用戶不愿意重新購買NAT/FW設(shè)備，更無法判斷各種ALG的可行性。

　　2.2 MidCom方案

　　MidCom（Middlebox Communications）方案是通過在第三方實(shí)體和FW/NAT之間建立中間盒來通信，使FW/NAT設(shè)備變?yōu)榭煽氐囊环N新的概念。MidCom包括MidCom Agent和Middlebox，Agent通過MidCom協(xié)議通知Middlebox建立相應(yīng)的NAT映射表項(xiàng)。

　　一般情況下，Middlebox集成在NAT或FW設(shè)備中，Agent可在軟交換、代理服務(wù)器或終端上實(shí)現(xiàn)。

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

　　從安全性考慮，MidCom方式支持控制報(bào)文和媒體流的加密，因此安全性比較高。

　　2.3 協(xié)議修改

　　由于目前的多媒體應(yīng)用協(xié)議無法穿越NAT/FW，因此可以考慮通過修改協(xié)議以適應(yīng)NAT/FW。

　　對(duì)于H.323，SIP，MGCP，H.248等協(xié)議，為支持NAT/FW穿越而做的修改尚未形成標(biāo)準(zhǔn)，還在起步研究階段，因此本文不做詳細(xì)探討。

　　2.4 STUN方案

　　STUN（Simple Traversal of UDP Through NATs）是由IETF研制的一種UDP流協(xié)議穿透NAT的協(xié)議。位于內(nèi)部網(wǎng)絡(luò)的STUN client（NAT內(nèi)）通過UDP發(fā)送請(qǐng)求STUN消息給外部網(wǎng)絡(luò)的STUN Server（NAT外），STUN Server收到請(qǐng)求消息后產(chǎn)生響應(yīng)消息（響應(yīng)消息中攜帶請(qǐng)求消息的源端口，即STUN Client在NAT上對(duì)應(yīng)的外部端口），響應(yīng)消息通過NAT發(fā)送給STUN Client，STUN Client通過響應(yīng)消息體中的內(nèi)容得知其在NAT上對(duì)應(yīng)的外部地址，然后將該地址填入以后的呼叫協(xié)議的UDP負(fù)載中，并且告知對(duì)端，本端的RTP接收地址和端口號(hào)為NAT外的地址和端口號(hào)。由于通過STUN協(xié)議已在NAT上預(yù)先建立媒體流的NAT映射表項(xiàng)，因此媒體流可順利穿越NAT。

　　需要注意的是，終端設(shè)備需要集成STUN Client功能，STUN Server可以集成在相應(yīng)的應(yīng)用所屬的部件上（如在NGN應(yīng)用中可以集成到SoftSwtich上）或者是由獨(dú)立的設(shè)備提供。

　　STUN協(xié)議最大的優(yōu)點(diǎn)是無需現(xiàn)有NAT/FW設(shè)備做任何改動(dòng)。目前，網(wǎng)絡(luò)中已有大量的NAT/FW，而且這些NAT/FW并不支持VoIP應(yīng)用。如果采用MidCom或NAT/ALG方式，則需要替換現(xiàn)有的NAT/FW，實(shí)施起來難度較大，且MidCom方式無法實(shí)現(xiàn)對(duì)多級(jí)NAT的有效控制。如果采用STUN方式，不但無需改動(dòng)NAT/FW，而且能夠很好地適應(yīng)多個(gè)NAT串聯(lián)的網(wǎng)絡(luò)環(huán)境。

　　但STUN也有以下幾個(gè)方面的局限性：

  1. 需要應(yīng)用程序支持STUN Client的功能，即NGN的網(wǎng)絡(luò)終端需具備STUN Client功能；


  2. STUN不支持TCP連接的穿越，也就表示不支持H.323協(xié)議；


  3. STUN方案不支持NGN業(yè)務(wù)對(duì)FW的穿越，不能穿越對(duì)稱NAT（Symmetric NAT）類型（在安全性要求較高的企業(yè)網(wǎng)中，出口NAT通常就是采用這種類型）。
　　2.5 Proxy方案

　　Proxy方案是指通過對(duì)私網(wǎng)內(nèi)用戶呼叫的信令和媒體同時(shí)做Relay來實(shí)現(xiàn)出口NAT/FW的穿越。對(duì)于NGN網(wǎng)絡(luò)的私網(wǎng)穿越問題，目前業(yè)界已基本傾向Proxy方式，并且在Proxy方案中還增加了網(wǎng)絡(luò)安全、防止終端漫游等特性。

　　Proxy設(shè)備是在原來網(wǎng)絡(luò)結(jié)構(gòu)的基礎(chǔ)上，采用網(wǎng)絡(luò)疊加方式，部署在IP網(wǎng)絡(luò)的邊緣或匯聚層，是會(huì)話信令和媒體的聚合點(diǎn)。信令Proxy與媒體Proxy可以在一個(gè)設(shè)備上實(shí)現(xiàn)，也可以分離實(shí)現(xiàn)，當(dāng)在同一個(gè)設(shè)備上實(shí)現(xiàn)時(shí)稱為Full Proxy。NGN終端通過Proxy設(shè)備連接到軟交換上。

　　在網(wǎng)絡(luò)中，信令Proxy和媒體Proxy各自擔(dān)負(fù)著不同的工作。

　�。�1）信令Proxy：Proxy設(shè)備對(duì)NCN用戶而言，可看作是軟交換系統(tǒng)，即用戶的注冊(cè)和呼叫消息都會(huì)發(fā)給Proxy設(shè)備，Proxy設(shè)備經(jīng)過信令處理后再轉(zhuǎn)發(fā)給軟交換系統(tǒng)。同時(shí)，Proxy設(shè)備對(duì)軟交換系統(tǒng)又可看作是用戶，軟交換系統(tǒng)首先將呼叫被叫的請(qǐng)求發(fā)給Proxy設(shè)備，Proxy設(shè)備經(jīng)過信令處理后再轉(zhuǎn)發(fā)給真正的被叫用戶。Proxy設(shè)備通過對(duì)信令進(jìn)行處理和分析，得到本次會(huì)話的地址變換狀況、帶寬需求等信息，并根據(jù)當(dāng)前網(wǎng)絡(luò)資源占用情況等信息來決定媒體流是否通過Full Proxy設(shè)備網(wǎng)關(guān)，從而起到網(wǎng)絡(luò)保護(hù)、防止帶寬盜用等作用。

　　（2）媒體Proxy：Proxy設(shè)備是媒體流的必經(jīng)之處，所有域內(nèi)用戶與外界互通的媒體流都經(jīng)過Proxy設(shè)備進(jìn)行處理和轉(zhuǎn)發(fā)。Proxy設(shè)備網(wǎng)關(guān)首先檢查報(bào)文的合法性，并根據(jù)信令處理結(jié)果來制定媒體流轉(zhuǎn)發(fā)策略（如FW、QoS和地址轉(zhuǎn)換策略），通過指定內(nèi)網(wǎng)/外網(wǎng)用戶RTP流的接收地址和端口這種方式來確保無論采用何種組網(wǎng)方案，媒體流都能得到正確轉(zhuǎn)發(fā)和嚴(yán)格的QoS保證、安全控制。

　　Full Proxy方式由于不用對(duì)運(yùn)營商和客戶端的現(xiàn)有網(wǎng)絡(luò)設(shè)備進(jìn)行任何會(huì)話型業(yè)務(wù)用戶改造，具有很強(qiáng)的適應(yīng)性，組網(wǎng)靈活，可滿足NGN初期多樣化的組網(wǎng)和用戶接入。除了解決NAT問題外，功能還可以大大擴(kuò)展，同時(shí)可在接入層實(shí)現(xiàn)對(duì)會(huì)話業(yè)務(wù)QoS和安全的處理，可以發(fā)展成為NGN網(wǎng)絡(luò)的用戶接入平臺(tái)。

網(wǎng)絡(luò)通訊服務(wù)網(wǎng)


相關(guān)鏈接:
英國：推動(dòng)融合環(huán)境下的市場競爭 2007-01-17
借助SOA和SIP在固網(wǎng)和無線網(wǎng)絡(luò)上提供下一代網(wǎng)絡(luò)業(yè)務(wù) 2007-01-17
四種最新城域電信級(jí)以太網(wǎng)技術(shù) 2007-01-15
城域電信級(jí)以太網(wǎng)崛起 2007-01-15
運(yùn)營商網(wǎng)絡(luò)技術(shù)轉(zhuǎn)型趨勢(shì) 2007-01-15

分類信息:     技術(shù)_NGN及軟交換_文摘