VoIP防火器穿越

Version 1.0

2008-9-8

一、      基本知識

1，  NAT（The IP Network Address Translator，RFC1631）基礎

NAT（網絡位址轉換）最初的目的是為使用内網IP位址的計算機提供通過少數幾台具有公網的IP位址的計算機通路外部網絡的功能。NAT 負責将某些内網IP位址的計算機向外部網絡

發出的 IP 資料包的源IP 位址轉換為NAT 自己的公網的IP 位址

，目的IP位址不變, 并将IP資料包轉發給路由器，最終到達外部的計算機。同時負責将外部的計算機傳回的IP資料包的目的IP位址轉換為内網的IP位址，源IP位址不變，并最終送達到内網中的計算機。

NAT的分類：

l        

靜态NAT

(Static NAT)：内部網絡中的每個主機都被永久映射成外部網絡中的某個合法的位址；

l        

動态位址NAT

(Pooled NAT)：在外部網絡中定義了一系列的合法位址，采用動态配置設定的方法映射到内部網絡；當遠端使用者聯接上之後，動态位址NAT就會配置設定給他一個IP位址，使用者斷開時，這個IP位址就會被釋放而留待以後使用；局限：同一個公網的IP位址，某個時間隻能由一台私有IP位址的計算機使用；

l        

網絡位址端口轉換NAPT

（The IP Network Address/Port Translator）：将某些内網計算機向外部網絡發出的TCP/UDP資料包的源IP位址轉換為NAPT自己的公網的IP位址，源端口轉為NAPT自己的一個端口（動态端口轉換技術稱為PAT，NAT與PAT同時使用，合稱NAPT）；目的IP位址和端口不變，并将IP資料包發給路由器，最終到達外部的計算機；同時負責将外部的計算機傳回的IP資料包的目的IP位址轉換内網的IP位址，目的端口轉為内網計算機的端口，源IP位址和源端口不變，并最終送達到内網中的計算機。

2，  NAPT對UDP的處理

一個内網IP:PORT會被NAPT映射成NAPT自己的IP與某個port的組合，NAPT利用虛拟Session維護兩個IP：PORT對的對應關系，并利用逾時機制來強制維系Session的存在；

二、      問題産生與方案思路

l       NAT問題

NAT技術更改消息包的IP位址，但并不相應更改NGN協定如SIP消息包中應用層負荷中的IP位址，這樣SIP消息頭及SDP中的位址仍然是内網位址，造成SIP消息及RTP流互動失敗；

對于目前一些被廣泛使用的、也在負荷中攜帶私網IP位址的協定，如FTP，一般NAT裝置在執行IP頭中位址轉換時，會同時執行負荷中的IP位址轉換，這樣就不會産生穿越問題；

另外，NAT隻在私網裝置主動向外送出請求時才會為其配置設定公網位址端口，否則對外網它是不可見的，外部裝置無法呼叫它；

l       PAT問題

與NAT問題類似，PAT問題指因載荷中端口産生的問題；

l       防火牆問題

端口封閉是防火牆技術中常用的方式，而一般RTP端口是在通話建立時動态配置設定的，這樣無法通過在防火牆上設定固定的開放端口的方法來解決RTP流的穿越；另外，防火牆還會使用通路規則控制的方法提供安全性，而NGN協定資料包未必能符合這些規則；

由上導出如下的解決思路：

1，  在私網裝置發出的資料包應用層載荷中填寫正确的公網位址與端口；這要求裝置在發起呼叫前獲知其在穿越NAT後使用的位址和端口，這類技術包括STUN、UPnP、TURN等；

2，  引入附加裝置解決應用層載荷中的私網位址端口問題，包括ALG、MIDCOM、Full Proxy等技術；

3，  使所有裝置分布或“虛拟”分布在同一個網絡中，以避免NAPT，如使用VPN技術；

4，  綜合方案，如RSTP、ICE；

為解決RTP、RTCP被NAT映射到不同端口的問題，一種方案是對SDP進行了屬性擴充，在SDP中直接給出RTCP IP:Port；

三、      各種解決方案

a)     STUN

Simple Traversal of UDP Through NAT，RFC3489

l         原理：在公網中部署STUN server，私網中的client向其發生各種請求包，通過處理傳回來發現NAT、獲知NAT類型、NAT為其配置設定的公網IP:PORT；

l         組成：私網client、公網server、NAT；

l         NAPT分類：

n         Full cone完全錐形：内網IP:PORT對應某個公網IP:PORT，任意外部主機發往該公網IP:PORT的資料包都被轉發；

n         Restricted cone受限錐形：隻有私網主機曾向某個外部主機發送過消息，外部主機才可以向内部主機發包——通訊必須先由内部主機發起；

n         Port Restricted cone：内部主機向某個特點IP:PORT發送過資料包，從該IP:Port來的資料才被轉發；

n         Symmetric NAT對稱NAT：由内部IP:PORT發往某個特定IP:Port的請求，被映射到某個公網IP:Port——内部某個IP:Port，如果它對端的外網IP:Port不同，則被映射到不同的IP:Port；

l         STUN Server，接收client請求，傳回client的公網IP:Port；嘗試使用其他IP:Port向client發送消息，client檢驗這些消息是否能收到，這樣就可以知道NAT類型；

l         STUN Client：

n         測試能否從Server獲得傳回，并從傳回中獲得自身公網IP:Port；

n         測試能否收到從不同IP:Port來的消息；

n         測試能否收到從同一IP、不同Port來的消息；

l         特點：

n         無需更改現有NAT裝置；

n         需要在公網部署server；

n         終端需支援STUN協定；

n         不支援Symmetric NAT的穿越；

n         不能解決NAT對RTP、RTCP端口任意配置設定，造成RTCP丢失問題；

l        

http://sourceforge.net/projects/stun/

上有一個實作，可以用于檢查本地NAT類型；

b)     UPnp

Universal Plug and Play，www.upnp.org；

PnP概念的發展，自動配置、自動發現實作網絡裝置服務釋出與資訊交換，目标是家庭、企業網絡的0設定；

UPnP網關對外提供标準接口，可以動态配置端口映射、動态打開端口、擷取外部位址等功能，client可利用這些功能實作穿越；

——不過是将NAT的控制功能吐了出來；

不支援多層私網，存在安全問題；

c)      ALG

Application Layer Gateway

在NAT、firewall上增加一個gateway，由其完成封包修改、實作轉發等功能；如處理register消息，記錄、處理呼叫狀态；

可在NAT上部署一個sip proxy，完成消息轉發；

缺點：需要更改NAT，gateway與具體應用協定相關；

d)     MIDCOM

MiddleBox Communications

l         原理：NAT具備middlebox功能，受middlebox信任的agent是執行應用層網關功能，而邏輯上位于NAT之外的實體，政策決策點PDP負責middlebox授權及有關政策規則服務，agnet向其注冊獲得授權；agent可實體上依附于NGN實體之上；

l         看起來midcom與ALG差不多，不過是将網關功能從NAT中分離出來，放到NGN實體上，中間再采用比較通用的協定而已——這與UPnp類似；

e)      TURN

Traversal Using Relay NAT

l         原理：私網終端通過某種方式獲得其對應的公網位址——TURN伺服器上的位址；client找到server後，發送配置設定請求消息，server打開端口，并将端口告知client；client将其填入自己發出的消息中；client的所有信令、RTP都通過TURN server轉發；

l         與STUN不同的地方：client将TURN server配置設定的IP:Port，而非NAT配置設定的IP:Port填入自己産生的信令消息中；

l         TURN server功能上可分成NAT Proxy與RTP Relay；從文獻[1]看來，RTP Relay需要先收到一方的RTP包，然後才能向它轉發來自另一方的RTP；這似乎與實際不符；

l         特點：支援所有類型NAT、firewall、支援TCP；

f)       Proxy

l         對私網中發出的信令、媒體同時做relay，實作出NAT及防火牆穿越；

l         Proxy改寫信令中的IP:Port，而TURN中該功能由TURN client負責；

l         信令Proxy與媒體Proxy在同一個裝置上實作時稱為Full Proxy；

l         SBC，Session Border Controller：Full proxy的例子；

l         SBC的原理：SBC同時記錄SIP頭中的IP:Port資訊及SIP/IP包的真實IP:Port，它使用真實的IP:Port（而非SIP頭中的IP:Port資料）發送消息，這些消息就可以到達NAT後的client；同時SIP UA定期向SBC發送注冊消息，以保持它在NAT上與公網IP:Port的對應關系不被改變；對于RTP流穿越，SBC采用類似的技術，

g)     RSIP

l         私網主機與外界發生聯系時釋出特定IP位址所采用的一種協定；

l         Client向同時連接配接私網和公網的server（具備邊界路由功能，部署在私網邊界）請求公網位址，将其填入自己發出的信令消息中；并且client使用公網位址填寫自己的IP包，再加上Tunnel header，利用隧道技術傳給RSIP server，這樣避免了server更改其IP位址，減輕server的單點負擔；

l         特點：使用隧道技術，IP頭中位址更改也是由client自身完成；

h)     ICE

Interactive Connectivity Establishment

l         綜合使用各種技術，使其在最合适的情況下運作，具有很強的适用能力；

l         需要終端支援；

l         To Be Continued；

四、      一種SIP穿越方案

在公網上部署一個服務程式，私網裡的SIP終端可以通過該服務程式互相間建立呼叫；該方案的優勢是無需終端的特殊支援，并且适用于各種NAT；

i)        信令穿越

SIP終端通過向公網服務程式的注冊來讓外界感覺自身的存在；server在處理REGISTER消息時，不但記錄contact頭域中終端的IP:Port資訊，同時記錄REGISTER消息實際的源IP:Port——這可能是NAT的IP:Port，并使用後者作為自身後續發出的所有SIP消息的目的地，以保證它們能夠穿越NAT到達SIP終端；

SIP終端與伺服器之間定期發送keep-alive消息，以保證NAT上的消息通道不會被逾時清除；消息發送周期一般可定為85秒；對于SIP，可以使用REGISTER或OPTION作為keep-alive消息，建議使用OPTION，因為一般OPTION的處理可以簡單一些；對于MGCP等協定，服務程式可以主動下發AUEP消息作為keep-alive；

因為NAT上消息通道一直存在，是以私網裡的SIP終端可以作為被叫接收到外部呼叫；

局限：

1，終端發出REGISTER消息所使用的port必須與REGISTER contact中的port一緻，即終端必須在它發出REGISTER所用端口等待後續消息；

2，不适應終端Port在通話過程中改變的情況——某些SIP終端會在INVITE的contact中附帶别的port作為自己接收後續SIP消息的端口；

3，适用于TCP等SIP所用其他傳輸協定嗎？

j)        媒體穿越

在公網上部署一個media relay，作為兩個私網中SIP終端媒體通信的中轉站；SIP消息在經過上述服務程式中轉時，必須将SDP中的IP:Port更改為該media relay的IP:Port（這與TURN的處理方式不同，TURN中終端更改自己的SDP IP:Port），這樣，終端的媒體流就會發給media relay，并被其轉發；

看來這種方式，兩個終端都必須先将媒體流發給media relay，才能使media relay知道終端RTP的私網IP:Port對應的公網IP:Port，進而成功轉發；這樣就不能處理INVITE SDP中媒體帶recvonly屬性的情況；

Re-INVITE消息也必須發給公網服務程式，由其将SDP中的私網IP:Port轉化為media relay的IP:Port，也可能會存在recvonly問題；

文獻[4]中提及了兩種媒體流穿越方案，mediaproxy與rtpproxy，主要介紹了這兩種方式在SER中的配置；沒有看出其實作原理及兩者的差别；To Be Continued；

媒體流穿越也可以利用ICE實作，ICE允許終端在呼叫建立後進行動态媒體協商，并且可以使媒體流直接在兩個終端間建立而無需第三方中轉；文獻[2]中有一點描述。

五、      SBC

Session Border Controller；

SBC的優勢：無需更新NAT裝置，無需更改現網拓撲結構，SBC自身位置沒有特别要求，隻需要IP可達即可（一般部署在核心網邊緣），也無需終端的特别支援；

Firewall、NAT穿越隻是SBC的功能之一，它還可以提供QoS、security、帶寬管理等功能；

SBC産品：華為SE2000系列；市面上SBC産品已經很豐富；

六、      一個現網項目SBC私網穿越分析

位于私網裡的SIP終端，通過Internet注冊到SBC，SBC再将其注冊到Softswitch上；該終端能支援呼入和呼出，媒體流信令流都能正常建立；

信令流分析：

1，  終端發出的REGISTER消息，contact頭中使用私網IP:Port，注冊過期時間是240秒；SIP Phone實際注冊周期約120秒；

2，  SBC周期性向REGISTER發出端口發送UDP keep-alive包，周期約8秒；這不需要終端回發任何響應；

3，  SBC向終端發起的呼叫，INVITE消息中，Request-URI使用終端的私網IP:Port，但是To頭域中是終端的公網IP；

4，  在REGISTER contact中的Port不同于終端實際發出REGISTER消息所用的Port時，SBC仍然會向實際的Port發送消息，而不是contact中指定的Port；

媒體流分析：

在終端上抓包看到，既有終端首先向SBC發出的RTP包，也有先收到了SBC發來的RTP，并且早了3秒；不明白SBC是怎樣在接收到終端的RTP前就把RTP包發到終端的，To Be Continued；

七、      NAT穿越的一些權威資料

RFC1631: The IP Network Address Translator，1994

RFC1918: Address Allocation for Private Internets，1996

RFC2663: IP Network Address Translator Terminology and Considerations，1999

RFC3022: Traditional IP Network Address Translator，2001

RFC3489: STUN - Simple Traversal of User Datagram Protocol Through Network Address Translators，2003；

IETF，draft-ietf-behave-turn-09，2008.7；

http://en.wikipedia.org/wiki/TURN；

IETF Draft: NAT and Firewall Scenarios and Solutions for SIP，2003

IETF Draft: Considerations for Selection of Techniques for NAT Traversal，2005

ITU-T H.fwreq（H.323系統多媒體穿越總體需求），2005

ITU-T H.Proxy（基于代理的多媒體系統穿越技術），2005

可惡，在ITU網站上下載下傳資料時竟然要求登入！

參考文獻

[1]   徐鵬、楊放春，基于軟交換的下一代網絡解決方案，北京郵電大學出版社，2007.7；

[2]   Adrian Georgescu，Best practices for SIP NAT traversal；

[3]   Netport networks，NAT Traversal for Multimedia over IP；

[4]   Paul Hazlett, Simon Miles, and Greger V. Teigre，SER - Getting Started，ONsip.org；