嘿嘿！
全部博文（140）
分类：
2012-06-04 11:12:15
VoIP 剛推出之初期，受到各種因素之干擾，以致非常難用，需要經過繁複的設定才能使用。 最常見到的是某一邊的使用者的電腦設定有問題導致單邊沒有聲音，因此收話發話兩端都必須是 電腦高手才能順利進行雙方通話。另外一個很大的限制是，收話發話兩端都必須填入所用電腦的 IP地址， 才能讓兩方相連。對於在家中利用撥接或ADSL設備上網或在防火牆後面的使用者而言， 這是一項難以達成的任務，無論使用者或電腦本身都難以輕易獲知其對外的IP位址。 這種現象一直等到Skype 推出之後才獲得大幅改善，大大提高了 VoIP的可用度，使得一般的電腦使用者也可以很輕易的使用VoIP。即使使用者是在防火牆 之後，VoIP 也可以順利運作，這是歸功於「VoIP穿越NAT 防火牆」技術。
9.1 NAT 及防火牆之來源NAT 是一種將內部IP 與外部IP互相轉換之技術。其起源是因為 IPv4 位址 稀少，而很多企業或網路公司在擁有少數IP 地址而公司內部確有太多電腦時 而採用共用IP 的解決方法，讓一個IP 地址給多個電腦使用。如今最常見的 IP 分享器或無線區域網路Access Point 都有NAT 的功能。使用者利用 ADSL上網 後，拿到一個 IP 地址，而IP 分享器或WLAN AP 則將一組專供內部使用的私有IP ， 通常是192.168.0.x，分配給所有內部電腦，內部每部電腦擁有一個192.168.0.x的IP 位址， 但WLAN AP 對外卻只有一個由網路公司賦予的IP 位址。 通常NAT 是將每一部電腦所用的 (IP, port number)， 本文稱為內部位址，對應到 (共用IP, port number)，本文稱為外部位址， 而 NAT 負責將進出封包的表頭進行轉換使得內部電腦可以 透通的與外部網路連線溝通。
企業使用防火牆對網路進行控管是很自然的事，通常有三項主要功能：
常用的私有IP 位址是
NAT 與防火牆對於VoIP的連線造成很大的困擾， 逼得VoIP研究人員發展出一套很複雜的技術讓VoIP能 穿越防火牆，讓在防火牆後面的使用者能自由的使用VoIP。
9.2 防火牆/NAT的種類 防火牆通常整合在NAT 裡面，根據所用的防火牆技術，NAT 可以分成 幾類。主要的四類如表9.1 所示：表 9.1 Cone NAT 種類
| NAT Type | Operation |
|---|---|
| Full Cone | Any external host can send a packet to the internal host, by sending a packet to the mapped external address. |
|
Restricted Cone (Address Restricted Cone) |
An external host (with IP address X) can send a packet to the internal host only if the
internal host had previously sent a packet to IP address X.
Once an internal address (iAddr:port1) is mapped to an external address (eAddr:port2), any packets from iAddr:port1 will be sent through eAddr:port2. Any external host can send packets to iAddr:port1 by sending packets to eAddr:port2 |
| Port Restricted Cone | A port restricted cone NAT is like a restricted cone NAT, but the restriction includes port numbers. |
| Symmetric NAT | Each request from the same internal IP address and port to a specific destination IP address and port is mapped to a unique external source IP address and port. If the same internal host sends a packet even with the same source address and port but to a different destination, a different mapping is used. Only an external host that receives a packet from an internal host can send a packet back. |
| NAT Type | Address binding | Port binding | Bindings per session | UDP NAT | TCP NAT | Session direction |
|---|---|---|---|---|---|---|
| Full Cone | no | -> | 1 | yes | no | <-> |
|
Restricted Cone (Address Restricted Cone) | no | -> | 1 | yes | no | -> |
| Port Restricted Cone | no | -> | 1 | yes | yes | -> |
| Symmetric NAT | no | no | 0 | yes | yes | -> |
Full Cone 只是單純的做位址轉換，並未對進出的封包設限。 其運作方式如圖9.1, 9.2 所示。
圖 9.1 Full Cone NAT
圖 9.2 Full Cone NAT 之運作
9.2.2 Restricted Cone NAT (Address Restricted Cone) Restricted Cone NAT 對於封包進出稍加限制。從內部送出之封包的目的地 IP 位址會被記住。只有這些曾經收過這些封包的位址可以送封包進入 NAT。由其他位址送進來的封包，都會被檔下。換言之， 只有收過NAT 內部送來的封包的地址才能將封包送入 Restrict Cone NAT 內， 其運作如圖9.3, 9.4 所示。
圖 9.3 Restricted Cone NAT
圖 9.4 Restricted Cone NAT之運作
9.2.3 Port Restricted Cone NAT Port Restricted Cone 對於封包進出比Restricted Cone 增加了一個限制， 從內部送出之封包的目的地的IP 位址及 Port Number 會被記住。 由外部送進來的封包，除了由那些接收過內部所送出 的封包的IP 位址及 Port Number 所送來的封包之外，都會被檔下。換言之， 只有收過NAT 內部送來的封包的地址及 Port Number 才能將封包送入 Restrict Cone NAT 內。 其運作如圖9.5, 9.6 所示。
圖 9.5 Port Restricted Cone NAT
圖 9.6 Port Restricted Cone NAT之運作
9.2.4 Symmetric NAT
圖 9.7 Symmetric NAT
Symmetric NAT 在四種Cone NAT中最為嚴謹。 前三種NAT在做位址轉換時，無論封包是送往何處， NAT內部同一內部位址 都對應到同一個外部位址，但在Symmetric NAT內則每一內部位址對不同的目的地， 都對應到不同的外部位址。
圖 9.8 Symmetric NAT
9.3 NAT 造成的問題 SIP是在當今的網際網路裡最常使用的VoIP通訊協議。 使用者端(CPE)所連接的Agent 稱為 User Agent (UA)， 使用者端所需的軟體功能都建置在UA 中， 網路上並建置有各種伺服器，提供各式各樣的服務， 共同建構出一個運作順暢的電話網路。我們以SIP 為例說明NAT 防火牆 對VoIP通訊協定造成的問題。為方便說明起見，本文將以SIP作為範例說明 各種VoIP技術。前文所使用的「使用者電腦」，在SIP架構下，其實就是扮演 UA 的角色。在SIP協議中，UA必須主動向registrars伺服器註冊，讓register伺服器掌握UA 動態。 要建立通話session時，發話端 UA 主動向 proxy servers 和受話的UA發出INVITE請求。 而這兩種自防火牆外所發出的請求會被防火牆所阻擋。 所以register 伺服器不能放在防火牆之內。但UA 就比較麻煩了，難免 會有相當數量的VoIP使用者是位於防火牆之內的，他們 可以不受干擾的主動發話向外連接。不過，他們卻很難接收他人的呼叫。 換言之，如果沒有適當的解決方案，位於防火牆之內的VoIP使用者，只能 對外發話，卻無法接受電話。
9.4 現有穿越防火牆/NAT技術介紹 現有幾個穿越防火牆/NAT技術如下：Universal Plug and Play(UPnP)是微軟公司提出的協定，其目的是要 簡化家庭或企業中智慧設備的連網過程． 使用TCP/IP協定透過網路自動彼此連接在一起， 而且連接過程中無需用戶的參與 和使用中央伺服器， UPnP設備可以自動探索網路並配置網路地址設定。 其穿越NAT的方式如下：
它的問題是：NAT及VoIP Client (UA) 必須支援UPnP， 但UPnP尚未得到所有的UA及NAT的支援 (要獲得全部UA及NAT廠商之支援，絕非易事)。 尤其是NAT的問題，基於安全性的考慮，幾無NAT 願意支援 UPnP。
圖 9.9 UPnP 穿越防火牆之運作
9.4.2 STUN STUN (Simple Traversal of UDP Through Network Address Translators - RFC 3489 )， 是最著名和最常被使用的VoIP穿越NAT防火牆的解決辦法。STUN 利用位於 Internet 上的伺服器幫助防火牆內的UA獲知他們被NAT 轉換過的外部位址， 並協助他人的VoIP呼叫穿透防火牆送達牆內的UA。很多應用層的 VoIP程式必須仰賴 UA 主動提供自身的IP 位址及port number， 讓VoIP兩端的UA 彼此知道對方的IP 位址及port number， 才能互送封包， 建立雙向的通話。但是如果UA 是在NAT 後面， 在沒有外部的協助下，一個UA 無法看到 它自己被NAT 轉換過的外部位址，就無法提供此項資訊，讓 VoIP順利運作。
圖 9.10 UA 與STUN 溝通獲知外部位址
STUN 伺服器可作為中介者協助UA 看到自己被轉換過的外部位址，如圖9.10所示。 UA 送一個message 給STUN 伺服器，而STUN 伺服器可從封包中挖出來該 UA 的外部位址，並將此資訊回傳給UA。 此外，STUN 伺服器也可透過一系列的測試封包獲知NAT 的型態，並提供 相對應的穿越方法，圖9.11及9.12顯示STUN 伺服器探測NAT型態之架構與流程。 可惜的是，STUN無法穿透Symmetric NAT， 而偏偏這種NAT已經成為NAT市場上的主流。以下是公眾STUN 伺服器的位址。
圖 9.11 STUN 伺服器探測NAT型態之架構
圖 9.12 STUN 伺服器探測NAT型態之流程
9.4.3 TURN TURN 提供比 STUN更為強大的中介功能，足以穿透Symmetric NAT 防火牆。 一個VoIP session 中的兩個端點所送出的封包全部先送給TURN server，再由 TURN server 轉送給對方。其運作如圖9.13所示。 使用TURN 服務的UA在啟動時，須以 一個TURN client的身份發出一個"TURN allocate"請求給TURN Server。 TURN Server會記住這個請求所來自的IP位址和Port，並回覆一個public IP 位址和Port。然後TURN Server就在它分配的public port上等資料傳入。啟動 完成的TURN Client 就可將封包送到所分配的Public port 上，此舉相當於 讓UA 與 TURN Server 建立通訊渠道。 當TURN Server 收到封包時時， TURN Server會儲存封包來源的IP位址和port，然後轉送它所提出要到的位址 的請求給對方。 TURN Server之後就作為在兩個位址之間的轉接者。 從第一個位址收到的任何資料會 被提供給第二位址， 並且從第二位址收到的任何資料也會被提供給第一個。這種方式雖然 可以穿越防火牆，但喪失了 P2P通訊的特色，變成Client-Server 模式，使得負載集中於 TURN Server上， Server 更須承擔所有頻寬，以致 沒有任何VoIP業者敢於採用。因此，這個解決辦法應該是在萬不得已下 才能考慮使用的。
圖 9.13 TURN
9.4.4 ALG (Application Layer gateway) Application Layer Gateways (ALGs)是一具有SIP能力(SIP-aware)的防火牆穿透技術。 這項技術必須汰換現有的NAT，因此在推廣上有嚴重的限制。 為了克服此項限制，Middlebox communication(MIDCOM) protocol被提出， MIDCOM允許應用程式，例如VoIP的UA和伺服器，控制NAT。 但基於安全理由，網管人員將不會接受用戶的應用程式控制他們的NAT。 因此在推廣上也是困難重重。
圖 9.14 ALG
9.4.5 ICE (Interactive Connectivity Establishment) IETF提出Interactive Connectivity Establishment (ICE)技術，結合STUN和TURN， 2005年 微軟及Cisco宣佈將採用ICE。其詳細的運作方式請見圖9.15。
圖 9.15 ICE
9.4.6 Proprietary solution 目前極受歡迎的P2P VoIP，Skype，有一個重要的專利，VoIP 穿越NAT/Fs解決辦法。 筆者把它視為分散式的TURN。 連結Skype的 Client 彼此之間會互相合作，某些資源較充足的Client 會被選作為超級節點(SN)，執行一些伺服器的功能，以分散伺服器的負載。 每個 Client 會保存一分隨時更新的SN目錄。在登入時， 它就努力與這些節點(SN)之 一打開一個TCP連接並且保持這個連接在開啟狀態，如此， SN 與Skype Client 間維持一個可穿透防火牆的通道。 每一個Client會藉由SN探測管制它們進出的NAT防火牆的存在和其類型。 Skype Client 使用TCP協定傳送控制信號。在最簡單的情況下， 當呼叫與被呼叫兩個 Client 都有公共的IP位址時， 呼叫者與被呼叫者之間會建立一個直接的TCP連接傳送控制信號。 然後多媒體的封包會直接使用UDP來傳送。 如果呼叫者或被呼叫者是在NAT防火牆後面，則無法直接傳送呼叫信號 和多媒體的封包，他們就以SN 作為中介者請SN 協助轉送封包。 如果因為防火牆作祟而無法利用UDP傳送語音封包時， Skype會改用TCP傳送。如果TCP也失敗，它會嘗試用TCP 傳送封包到常用的兩個port，HTTP(80)和HTTPS(443)。一般的防火牆不會 封殺這兩個 port，而Skype client在一開始就開啟著這兩個port以備使用。 如此，Skype 穿越防火牆的能力相當的高明，難怪如此風行。 參考文獻
