摘 要 主要探討了NGN軟終端和IAD的NAT問題，介紹了ALG、MidCom、STUN、協(xié)議修改、Proxy等幾種私網(wǎng)穿越方法，并分析了方案的可行性和適用性
關(guān)鍵詞 NGN 軟終端 IAD NAT私網(wǎng)穿越
1 引言
目前NGN（軟交換）技術(shù)已逐步從試驗走向商用，在應(yīng)用過程中遇到了很多實際問題，特別是NGN用戶的接入問題。NGN是一個基于分組網(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)進行互通，或者說目前的NAT/FW大多只是支持HTTP的數(shù)據(jù)應(yīng)用協(xié)議穿透，而無法支持這種會話型業(yè)務(wù)的控制與媒體的NAT/FW穿透，因此私網(wǎng)穿越問題的解決顯得更加迫切，成為目前NGN網(wǎng)絡(luò)業(yè)務(wù)開展的最大障礙。目前，解決這一問題的主要方案有ALG、STUN、MidCom和Proxy等。
2 穿越技術(shù)介紹
2.1 ALG方案
NAT和NAPT只能對IP報文的頭部地址和TCP/UDP頭部的端口信息進行轉(zhuǎn)換，對于報文的數(shù)據(jù)部分可能包含IP地址或端口信息的特殊協(xié)議（如H.323、SIP、MGCP等），則無法實現(xiàn)有效的轉(zhuǎn)換，這就可能導(dǎo)致問題發(fā)生。例如，一個使用內(nèi)部IP地址的FTP服務(wù)器可能在和外網(wǎng)主機建立會話的過程中需要將自己的IP地址發(fā)送給對方，而這個地址信息是放在IP報文的數(shù)據(jù)部分，NAT無法對它進行轉(zhuǎn)換，當外網(wǎng)主機接收到這個私有地址并使用它，這時FTP服務(wù)器將表現(xiàn)為不可達。
解決這些特殊協(xié)議的NAT轉(zhuǎn)換問題的一個方法就是在NAT實現(xiàn)中采用ALG（Application Level Gateway，應(yīng)用級網(wǎng)關(guān)）功能。ALG是能夠識別指定IP協(xié)議（如H.323、SIP或MGCP）的設(shè)備。它通過與NAT交互以建立狀態(tài)，使用NAT的狀態(tài)信息來改變封裝在IP報文數(shù)據(jù)部分中的特定數(shù)據(jù)，并完成其他必需的工作以使應(yīng)用協(xié)議可以跨越不同范圍運行。例如，一個“目的站點不可達”的ICMP報文，該報文數(shù)據(jù)部分包含了造成錯誤的數(shù)據(jù)報A的首部（注意，NAT在發(fā)送A之前進行了地址轉(zhuǎn)換，所以源地址不是內(nèi)部主機的真實地址）。如果開啟了ICMP ALG功能，在NAT轉(zhuǎn)發(fā)ICMP報文之前，它將與NAT交互，打開ICMP報文并轉(zhuǎn)換其數(shù)據(jù)部分的報文A首部的地址，使這些地址表現(xiàn)為內(nèi)部主機的確切地址形式，并完成其他一些必需工作后，由NAT降這個ICMP報文轉(zhuǎn)發(fā)出去。
ALG可以是單獨的連接于外網(wǎng)和內(nèi)網(wǎng)之間的設(shè)備，也可以是內(nèi)置于NAT內(nèi)的插件。ALG典型的組網(wǎng)方式如圖1所示。
點擊放大圖片
ALG是支持NCN應(yīng)用最簡單的方式，但由于目前網(wǎng)絡(luò)中已大量部署了不支持NCN業(yè)務(wù)應(yīng)用的NAT/FW設(shè)備，因此不推薦采用這種方式，理由如下：
（1）目前網(wǎng)上大量的NAT/FW設(shè)備因不具備ALG能力而需要更換或升級；
（2）NGN業(yè)務(wù)的ALG生產(chǎn)廠商少，沒有一套產(chǎn)品特性需求基線；
（3）NAT/FW設(shè)備廠商一般不是IP業(yè)務(wù)領(lǐng)域的專業(yè)廠商，難以支持業(yè)務(wù)的變化（如SIP的擴展多種多樣）；
（4）用戶普遍希望運營商在不改變已有網(wǎng)絡(luò)設(shè)備（NAT）的情況下就可以提供新的IP業(yè)務(wù)，用戶不愿意重新購買NAT/FW設(shè)備，更無法判斷各種ALG的可行性。
2.2 MidCom方案
MidCom（Middlebox Communications）方案是通過在第三方實體和FW/NAT之間建立中間盒來通信，使FW/NAT設(shè)備變?yōu)榭煽氐囊环N新的概念。如圖2所示，MidCom包括MidCom Agent和Middlebox，Agent通過MidCom協(xié)議通知Middlebox建立相應(yīng)的NAT映射表項。
點擊放大圖片
一般情況下，Middlebox集成在NAT或FW設(shè)備中，Agent可在軟交換、代理服務(wù)器或終端上實現(xiàn)。
由于應(yīng)用業(yè)務(wù)識別的智能從Middlebox移到外部的MidCom Agent上，因此，根據(jù)MidCom的架構(gòu)，在不需要更改Middlebox基本特性的基礎(chǔ)上，通過對MidCom Agent的升級就可以支持更多的新業(yè)務(wù)。這是相對于NAT/ALG方式的一個很大的優(yōu)勢。
從安全性考慮，MidCom方式支持控制報文和媒體流的加密，因此安全性比較高。
2.3 協(xié)議修改
由于目前的多媒體應(yīng)用協(xié)議無法穿越NAT/FW，因此可以考慮通過修改協(xié)議以適應(yīng)NAT/FW。
對于H.323，SIP，MGCP，H.248等協(xié)議，為支持NAT/FW穿越而做的修改尚未形成標準，還在起步研究階段，因此本文不做詳細探討。
2.4 STUN方案
STUN（Simple Traversal of UDP Through NATs）是由IETF研制的一種UDP流協(xié)議穿透NAT的協(xié)議。如圖3所示，位于內(nèi)部網(wǎng)絡(luò)的STUN client（NAT內(nèi)）通過UDP發(fā)送請求STUN消息給外部網(wǎng)絡(luò)的STUN Server（NAT外），STUN Server收到請求消息后產(chǎn)生響應(yīng)消息（響應(yīng)消息中攜帶請求消息的源端口，即STUN Client在NAT上對應(yīng)的外部端口），響應(yīng)消息通過NAT發(fā)送給STUN Client，STUN Client通過響應(yīng)消息體中的內(nèi)容得知其在NAT上對應(yīng)的外部地址，然后將該地址填入以后的呼叫協(xié)議的UDP負載中，并且告知對端，本端的RTP接收地址和端口號為NAT外的地址和端口號。由于通過STUN協(xié)議已在NAT上預(yù)先建立媒體流的NAT映射表項，因此媒體流可順利穿越NAT。
點擊放大圖片
需要注意的是，終端設(shè)備需要集成STUN Client功能，STUN Server可以集成在相應(yīng)的應(yīng)用所屬的部件上（如在NGN應(yīng)用中可以集成到SoftSwtich上）或者是由獨立的設(shè)備提供。
STUN協(xié)議最大的優(yōu)點是無需現(xiàn)有NAT/FW設(shè)備做任何改動。目前，網(wǎng)絡(luò)中已有大量的NAT/FW，而且這些NAT/FW并不支持VoIP應(yīng)用。如果采用MidCom或NAT/ALG方式，則需要替換現(xiàn)有的NAT/FW，實施起來難度較大，且MidCom方式無法實現(xiàn)對多級NAT的有效控制。如果采用STUN方式，不但無需改動NAT/FW，而且能夠很好地適應(yīng)多個NAT串聯(lián)的網(wǎng)絡(luò)環(huán)境。
但STUN也有以下幾個方面的局限性：
（1）需要應(yīng)用程序支持STUN Client的功能，即NGN的網(wǎng)絡(luò)終端需具備STUN Client功能；
（2）STUN不支持TCP連接的穿越，也就表示不支持H.323協(xié)議；
（3）STUN方案不支持NGN業(yè)務(wù)對FW的穿越，不能穿越對稱NAT（Symmetric NAT）類型（在安全性要求較高的企業(yè)網(wǎng)中，出口NAT通常就是采用這種類型）。
2.5 Proxy方案
Proxy方案是指通過對私網(wǎng)內(nèi)用戶呼叫的信令和媒體同時做Relay來實現(xiàn)出口NAT/FW的穿越。對于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ò)的邊緣或匯聚層，是會話信令和媒體的聚合點。信令Proxy與媒體Proxy可以在一個設(shè)備上實現(xiàn)，也可以分離實現(xiàn)，當在同一個設(shè)備上實現(xiàn)時稱為Full Proxy。NGN終端通過Proxy設(shè)備連接到軟交換上，如圖4所示。
點擊放大圖片
在網(wǎng)絡(luò)中，信令Proxy和媒體Proxy各自擔負著不同的工作。
（1）信令Proxy：Proxy設(shè)備對NCN用戶而言，可看作是軟交換系統(tǒng)，即用戶的注冊和呼叫消息都會發(fā)給Proxy設(shè)備，Proxy設(shè)備經(jīng)過信令處理后再轉(zhuǎn)發(fā)給軟交換系統(tǒng)。同時，Proxy設(shè)備對軟交換系統(tǒng)又可看作是用戶，軟交換系統(tǒng)首先將呼叫被叫的請求發(fā)給Proxy設(shè)備，Proxy設(shè)備經(jīng)過信令處理后再轉(zhuǎn)發(fā)給真正的被叫用戶。Proxy設(shè)備通過對信令進行處理和分析，得到本次會話的地址變換狀況、帶寬需求等信息，并根據(jù)當前網(wǎng)絡(luò)資源占用情況等信息來決定媒體流是否通過Full Proxy設(shè)備網(wǎng)關(guān)，從而起到網(wǎng)絡(luò)保護、防止帶寬盜用等作用。
（2）媒體Proxy：Proxy設(shè)備是媒體流的必經(jīng)之處，所有域內(nèi)用戶與外界互通的媒體流都經(jīng)過Proxy設(shè)備進行處理和轉(zhuǎn)發(fā)。Proxy設(shè)備網(wǎng)關(guān)首先檢查報文的合法性，并根據(jù)信令處理結(jié)果來制定媒體流轉(zhuǎn)發(fā)策略（如FW、QoS和地址轉(zhuǎn)換策略），通過指定內(nèi)網(wǎng)/外網(wǎng)用戶RTP流的接收地址和端口這種方式來確保無論采用何種組網(wǎng)方案，媒體流都能得到正確轉(zhuǎn)發(fā)和嚴格的QoS保證、安全控制。
Full Proxy方式由于不用對運營商和客戶端的現(xiàn)有網(wǎng)絡(luò)設(shè)備進行任何會話型業(yè)務(wù)用戶改造，具有很強的適應(yīng)性，組網(wǎng)靈活，可滿足NGN初期多樣化的組網(wǎng)和用戶接入。除了解決NAT問題外，功能還可以大大擴展，同時可在接入層實現(xiàn)對會話業(yè)務(wù)QoS和安全的處理，可以發(fā)展成為NGN網(wǎng)絡(luò)的用戶接入平臺。
3 方案的簡單對比
上述幾種穿越技術(shù)的簡單對比見表1。
