網路電話穿越防火牆和NAT的四種方法

一、NAT/ALG 方式

普通NAT是通過修改UDP或TCP報文頭部地址資訊實現地址的轉換，但對於VoIP應用，在TCP/UDP淨載中也需帶地址資訊，ALG方式是指在私網中的VoIP終端在淨載中填寫的是其私網地址，此地址資訊在通過NAT時被修改為NAT上對外的地址。

此時當然要求ALG功能駐留在 NAT/Firewall裝置中，要求這些裝置本身具備應用識別的智能。支援VoIP和視頻協議(H323、SIP、 MGCP/H248)的識別和對NAT/Firewall的控制，同時每增加一種新的應用都將需要對 NAT/Firewall進行升級。

在安全要求上還需要作一些折衷，因為ALG 不能識別加密後的報文內容，所以必須保證報文採用明文傳送，這使得報文在公網中傳送時有很大的安全隱患。

NAT/ALG是支援VoIP NAT穿透的一種最簡單的方式，但由於網路實際情況是已部署了大量的不支援此種特性的NAT/FW裝置，因此，實際應用中，很難採用這種方式。

二、MIDCOM 方式

與NAT/ALG不同的是，MIDCOM的基本架構是採用可信的第三方(MIDCOM Agent)對Middlebox (NAT/FW)進行控制，VoIP協議的識別不由Middlebox完成，而是由外部的MIDCOM Agent完成，因此VoIP使用的協議對Middlebox是透明的 .

由於識別應用協議的功能從 Middlebox移到外部的MIDCOM Agent上，根據MIDCOM 的構，在不需要更改Middlebox基本特性的基礎上，通過對MIDCOM Agent的升級就可以支援更多的新業務，這是相對NAT/ALG方式的一個很大的優勢。

在VoIP實際應用中，Middlebox功能可駐留在NAT/Firewall，通過軟交換裝置(即MIDCOM Agent)對IP語音和視頻協議(H323、SIP、MGCP/H248)的識別和對NAT/Firewall的控制，來完成VoIP應用穿越 NAT/Firewall .在安全性上，MIDCOM方式可支援控制報文的加密，可支援媒體流的加密，因此安全性比較高。

如果在軟交換裝置上實現對 SIP/H323/MGCP/H248協議的識別，就只需在軟交換和NAT/FW裝置上增加MIDCOM協議即可，而且以後新的應用業務識別隨著軟交換的支援而支援，此方案是一種比較有前途的解決方案，但要求現有的NAT/FW裝置需升級支援MIDCOM協議，從這一點上來說，對已大量布署的NAT/FW 裝置來說，也是很困難的，同NAT/ALG方式有相同的問題。

三、STUN 方式

解決穿透NAT問題的另一思路是，私網中的VoIP終端通過某種機制預先得到出口NAT上的對外地址，然後在淨載中所填寫的地址資訊直接填寫出口 NAT上的對外地址，而不是私網內終端的私人IP地址，這樣淨載中的內容在經過NAT時就無需被修改了，只需按普通NAT流程轉換報文頭的IP地址即可，淨載中的 IP地址資訊和報文頭地址資訊是一致的。STUN協議就是基於此思路來解決應用程式層地址的轉換問題。

STUN的全稱是Simple Traversal of UDP Through Network Address Translators，即 UDP對NAT的簡單穿越方式。應用程式(即STUN CLIENT)向NAT外的STUN SERVER通過UDP發送請求STUN 訊息， STUN SERVER收到請求訊息，產生響應訊息，響應訊息中攜帶請求訊息的源連接埠，即STUN CLIENT在NAT上對應的外部連接埠。然後響應訊息通過NAT發送給STUN CLIENT，STUN CLIENT通過響應訊息體中的內容得知其NAT上的外部地址，並將其填入以後呼叫協議的UDP負載中，告知對端，本端的RTP接收地址和連接埠號碼為NAT 外部的地址和連接埠號碼。由於通過STUN協議已在NAT上預先建立媒體流的NAT映射表項，故媒體流可順利穿越NAT.

STUN協議最大的優點是無需現有 NAT/FW裝置做任何改動。由於實際應用中，已有大量的NAT/FW，並且這些NAT/FW並不支援VoIP的應用，如果用MIDCOM或NAT /ALG方式來解決此問題，需要替換現有的NAT/FW，這是不太容易的。而採用STUN方式無需改動NAT/FW，這是其最大優勢，同時STUN方式可在多個NAT串聯的網路環境中使用，但MIDCOM方式則無法實現對多級NAT的有效控制。

STUN的局限性在於需要VoIP終端支援STUN CLIENT的功能，同時STUN並不適合支援TCP串連的穿越，因此不支援H323.另外 STUN方式不支援對防火牆的穿越，不支援對稱NAT (Symmetric NAT)類型(在安全性要求較高的企業網中，出口NAT通常是這種類型)穿越。

四、TURN方式

TURN方式解決NAT問題的思路與 STUN相似，也是私網中的VoIP終端通過某種機制預先得公網上的服務地址(STUN方式得到的地址為出口 NAT上外部地址，TURN方式得到地址為TURN Server上的公網地址)，然後在報文淨載中所要求的地址資訊就直接填寫該公網地址。

TURN的全稱為Traversal Using Relay NAT，即通過Relay方式穿越NAT.TURN應用程式模型通過分配 TURN Server的地址和連接埠作為私網中VoIP終端對外的接受地址和連接埠，即私網終端發出的報文都要經過TURN Server進行Relay轉寄，這種方式除了具有STUN方式的優點外，還解決了STUN應用無法穿透對稱NAT(Symmetric NAT)以及類似的Firewall裝置的缺陷，同時TURN支援基於TCP的應用，如H323協議。此外TURN Server控制分配地址和連接埠，能分配RTP/RTCP地址對(RTCP連接埠號碼為RTP連接埠號碼加1)作為私網終端使用者的接受地址，避免了STUN方式中出口NAT對RTP/RTCP地址連接埠號碼的任意分配，使得用戶端無法收到對端發來的RTCP報文(對端發RTCP報文時，目的連接埠號碼預設按RTP連接埠號碼加 1發送)。

TURN的局限性在於需要VoIP終端支援TURN Client，這一點同STUN一樣對網路終端有要求。此外，所有報文都必須經過TURN Server轉寄，增大了包的延遲和丟包的可能性。

http://www.ucomnetworks.com/jishu/a24.html