欧美,精品,综合,亚洲,好吊妞视频免新费观看,免费观看三级吃奶,一级a片女人自慰免费看

您當前的位置是:  首頁 > 新聞 > 國內(nèi) >
 首頁 > 新聞 > 國內(nèi) >

SIP系列講座-SIP-防火墻-NAT-Hole Punching探討

2017-11-13 14:51:23   作者: james.zhu   來源:CTI論壇   評論:0  點擊:


  在前面的講座中,我們討論了基于SIP的安全機制和一些解決方式。在接下來的講座中,我們要針對性地討論關于SIP互聯(lián)互通中存在的一個核心問題-NAT問題。
  VOIP的運行需要對接很多公網(wǎng)資源,例如,對接運營商的SIP中繼,對接第三方的其他支持服務器,對接分公司業(yè)務等等數(shù)據(jù)。但是,無論怎么對接,用戶都需要一個標準的網(wǎng)絡架構來實現(xiàn)內(nèi)網(wǎng)分機和外網(wǎng)的互聯(lián)互通。因為,網(wǎng)絡地址資源的限制,所以,內(nèi)網(wǎng)和外網(wǎng)的互聯(lián)互通就需要一個內(nèi)網(wǎng)地址轉(zhuǎn)換的機制,通過一個外網(wǎng)轉(zhuǎn)換到多個內(nèi)網(wǎng)的地址。這里,就涉及到了路由器防火墻和應用業(yè)務的端口管理問題,其中有一些應用可能還不是問題,但是對SIP的語音通信來講,這是一個非常具有挑戰(zhàn)性的難題。為了幫助讀者盡快了解這些相關的技術細節(jié),我們盡可能在有限的篇幅中對NAT提供多角度,多維度的討論,幫助用戶盡快了解這些必要的技術。
  今天,我們將重點討論以下幾個方面的內(nèi)容,它們包括:防火墻,關于NAT的相關基礎概念,UDP 打洞介紹,NAT的類型。
  1、請讀者注意,這里我們討論所有的相關細節(jié)時不會介紹太多和本話題不相關的技術內(nèi)容,所以,筆者建議用戶首先了解一般的網(wǎng)絡環(huán)境和知識點,以免引起造成困擾。在討論NAT之前,我們首先解釋一下關于為什么防火墻的對NAT處理有影響。以下圖例解釋了一個簡單的防火墻的工作拓撲圖:
  這里,防火墻置于企業(yè)網(wǎng)絡邊界的地方,防火墻的工作就是保護公司內(nèi)網(wǎng)的安全。關于防火墻的具體功能和配置,我們這里不再介紹。但是,為了配合SIP的相關話題,我們這里再次強調(diào)一下關于防火墻的使用環(huán)境的問題,一般意義上,防火墻的應該是:
  • 防火墻對網(wǎng)絡數(shù)據(jù)進行策略管理,數(shù)據(jù)流量管理。
  • 防火墻對某些設備進行權限的設置管理。
  • 防火墻一般允許內(nèi)網(wǎng)用戶訪問外網(wǎng),同時允許內(nèi)網(wǎng)訪問外網(wǎng)時返回的數(shù)據(jù)進入到內(nèi)網(wǎng)。
  • 防火墻通常允許HTTP,SMTP這些一般的工作應用業(yè)務進行數(shù)據(jù)傳輸。
  • 防火墻通常對SIP不太友好,可能過濾SIP端口,RTP 端口。

  • 防火墻只能對外網(wǎng)進行保護,但是不能對內(nèi)網(wǎng)軟件病毒或者其他內(nèi)網(wǎng)設備發(fā)起的攻擊進行保護。所以,進來避免在內(nèi)部電腦安裝其他的未授權的第三方軟件。
  2、大家知道,如果我們給公司公網(wǎng)申請一個固定IP地址的話是需要付費的,IP地址是一個緊缺資源,IPv4的地址資源已經(jīng)非常緊缺。通常情況下,一個可以上網(wǎng)的網(wǎng)絡環(huán)境至少需要一個公網(wǎng)的地址,這個公網(wǎng)地址對應內(nèi)部網(wǎng)絡地址(Class A, Class B 和Class C)進行轉(zhuǎn)換。RFC 6314 和RFC 4787對NAT做了規(guī)范。
  為了實現(xiàn)一個公網(wǎng)地址對應多個內(nèi)網(wǎng)地址來實現(xiàn)正常的網(wǎng)絡訪問,我們必須使用一個NAT的機制,我們簡單稱之為網(wǎng)絡地址轉(zhuǎn)換(1:N),通過NAT可以實現(xiàn)公網(wǎng)地址轉(zhuǎn)換為內(nèi)網(wǎng)地址的作用。關于更多的NAT介紹,讀者可以參考網(wǎng)絡上的學習資料學習,這里不做過多討論。根據(jù)德國研究人員Florian Wohlfart對一般小型企業(yè)和家庭用戶對NAT的測試,根據(jù)網(wǎng)絡的不同,NAT過濾的比例也完全不同,所以NAT確實影響了數(shù)據(jù)的正;ネ。
  以下是一個內(nèi)網(wǎng)終端訪問外網(wǎng)的IP狀態(tài),讀者通過以下圖例可以看到,內(nèi)網(wǎng)地址在通過防火墻到公網(wǎng),然后到達另外一個公網(wǎng)地址時,自己的內(nèi)網(wǎng)IP地址已經(jīng)給替換成了公網(wǎng)的IP地址。在公網(wǎng)出局之前,內(nèi)網(wǎng)地址會被過濾。
  對端網(wǎng)絡響應的消息將會返回到防火墻,然后通過路由器策略返回到請求的終端IP地址。
  上面,我們看到的是終端和服務器端的互通,現(xiàn)在我們看看兩個帶NAT的終端直接互通的實現(xiàn)方式。在以下的示例中,兩個帶NAT的終端都需要注冊到公網(wǎng)以外的服務器,然后實現(xiàn)正常的通信流程。
  如果兩個終端需要直接互通的話,可以對服務器發(fā)出請求,然后服務器對其注冊策略進行調(diào)整,讓兩個終端可以自己直接協(xié)商,兩個終端設備打洞以后實現(xiàn)雙方的直接互通。下面,我們介紹幾個不同NAT的流程處理方式:
  同一NAT Hole Punching的一個具體流程:
  不同NAT環(huán)境下 Hole Punching的處理流程:
  多層NAT處理流程和一層NAT的處理機制基本上相同,但是多了一層協(xié)商的機制。網(wǎng)絡環(huán)境也變得更加復雜。
  我們一直討論再不停解釋協(xié)商的概念,大家知道,UDP是一種不可靠的傳輸方式,需要端口一直處于存活狀態(tài)。如果打開的洞好久時間沒有數(shù)據(jù)交換,可能這個洞就會關閉。所以在UDP的打洞時也使用了定時器的開關來保證一定時間內(nèi)這個洞是開放的狀態(tài)。但是,不幸的是,很多NAT設備的設置和定時器的設置可能都不完全相同,一些設備的NAT的定時器設置一般為20秒,如果為了保證會話一直存活的話,可能需要調(diào)整定時器的時間長度,在網(wǎng)絡中不停發(fā)送keep-live的數(shù)據(jù)包,可能在很短早期需要再次重新發(fā)送這些數(shù)據(jù)包,讓打開的這個洞一直參與存活狀態(tài)。但是,更為不幸的是,這樣的做法同樣生成很多的無效數(shù)據(jù),耗費了很多網(wǎng)絡資源。
  上面我們討論了關于UDP 打洞的幾個方式和UDP打洞的定時器設置問題。既然有關于UDP的打洞的方式就會有基于TCP的打洞方式。關于TCP的方式,因為篇幅的關系,而且在我們的SIP案例中的使用量不多,所以,我們這里不再繼續(xù)展開討論。讀者可以參考Bryan Ford 發(fā)表的文章做進一步的研究,他的文章也討論了關于基于UDP打洞和TCP打洞的測試方式和測試流程。
  根據(jù)Bryan發(fā)表的完整,在實際生產(chǎn)環(huán)境中,用戶對各種路由器的使用比例做了一個統(tǒng)計,以下是統(tǒng)計結果:
  在使用點對點處理打洞的方法上,業(yè)內(nèi)有很多公司也使用了UDP Hole Punching 來保證用戶的連接效果。Tribler的測試結果可以作為一個參考,根據(jù)它們官方數(shù)據(jù),成功率都在85%以上。Tribler使用的具體測試方法和工具,請讀者查閱參考資料鏈接。
  下面,我們結合一些我們經(jīng)常使用的場景來形象化地解釋一下打洞的實現(xiàn)方式。這些場景可能是:點對點的通信,或者服務器端的的Bypass功能。以下圖例是經(jīng)過雙方協(xié)商以后,實現(xiàn)雙方互通的流程。
  如果終端都在同一NAT的內(nèi)網(wǎng)環(huán)境中,系統(tǒng)也可以實現(xiàn)互通連接。這里,我們拿一個目前最為典型的云托管的FreePBX舉例。如果兩個終端都在同一內(nèi)網(wǎng),而且?guī)AT環(huán)境。首先,兩個終端都需要實現(xiàn)SIP信令的連接,確保連接成功。
  在這種情況下,IPPBX可以支持內(nèi)網(wǎng)之間的互通,兩個同一內(nèi)網(wǎng)的終端就可以實現(xiàn)語音或視頻的通話。這樣相對節(jié)省了很多網(wǎng)絡的資源。但是,也存在很多缺點,例如,影響計費功能,影響系統(tǒng)錄音功能。關于IPPBX終端直接互通的功能的設置和影響,我們在以前的Asterisk功能設置的講座中已經(jīng)提及,這里不再繼續(xù)討論。
  但是,在現(xiàn)實的網(wǎng)絡環(huán)境中,我們的網(wǎng)絡架構也遠遠不是我們介紹的那樣簡單。很多網(wǎng)絡已經(jīng)涉及了多個NAT的環(huán)境,多個網(wǎng)絡地址,而且不同的防火墻對SIP的過濾也有所不同。
  在實際運行環(huán)境中,比較典型的實例就是關聯(lián)了SIP內(nèi)網(wǎng)地址,如果內(nèi)網(wǎng)的終端SIP消息在出局時,防火墻經(jīng)過了NAT以后,相關的內(nèi)網(wǎng)SIP 頭消息都會被丟棄或者修改(Via,Contact,SDP中的c),發(fā)送出去的只有公網(wǎng)IP地址的消息。如果外網(wǎng)終端返回響應的消息時,路由器就可能丟棄這些無效的消息,或者無法做出路由策略的判斷,返回的消息也不知道如何路由到內(nèi)網(wǎng)相應的終端。
  3、剛才,我們介紹了NAT對SIP的影響,現(xiàn)在,我們介紹一下NAT的四種類型和各自的不同。完整的NAT類型的定義可以參考維基百科的定義。
  根據(jù)以下圖例我們可以看到,不同的NAT類型,對IP地址和端口的定義是完全不一樣的,通過不同的IP地址和端口的組合限制來確定NAT的類別。
  以上圖例來自思科網(wǎng)絡資料
  簡單來說,以上四種類型的定義為:
  • Full Cone來自網(wǎng)絡所有的請求都轉(zhuǎn)發(fā)到一個內(nèi)網(wǎng)地址,IP地址,端口都不受到限制。
  • Restricted Cone則限定某些外網(wǎng)的IP可以可以轉(zhuǎn)發(fā)到相應的一個內(nèi)網(wǎng)地址,端口可以變動。
  • Port Restricted Cone則要求具體的IP地址和端口都限定。
  • Symmetric Cone則可以同時支持多個IP地址/端口的版本,端口和IP地址必須是一組的限定。
  從幾個類型的定義看,NAT類型對網(wǎng)絡的要求是完全不同的,F(xiàn)ull Cone是最為寬松的,而Symmetric是最為嚴格的。我們這里根據(jù)不同的顏色和字體表示對NAT轉(zhuǎn)換的寬松程度。當然,越來越寬松勢必帶來很多的網(wǎng)絡安全隱患問題和其他的問題。
  運營商或者網(wǎng)絡本身也有對NAT的很多方面的限制。幾年前,德國研究人員在德國和美國針對中小型企業(yè)和家庭網(wǎng)絡調(diào)查得出的各種NAT的比例:
 Tribler 公司對用戶做的NAT環(huán)境的調(diào)查結果,幾種NAT對用戶網(wǎng)絡的影響:
  • 基于全球的NAT分布狀態(tài):
  • 因為NAT連接超時的頻率:

  • 盡管NAT問題非常復雜,很多商業(yè)公司提供了NAT測試的工具,用戶可以下載測試。Nattest 公司提供關于NAT檢測的一些解決方案,這家公司也提供檢測NAT的工具檢測超時,端口存活等狀態(tài)數(shù)據(jù)。
  • 客戶端對服務器端發(fā)送請求,服務器端返回響應消息。這樣的交互大約要互相發(fā)送100多次,才能獲取到真實的數(shù)據(jù)。
  以下是檢測關閉的測試流程。
  4、在上一個部分我們介紹了NAT的幾種類型,現(xiàn)在我們主要針對SIP終端結合NAT做一個簡單的介紹。以下圖例簡單解釋了SIP失敗的原因,用戶可以查閱RFC6314對NAT做更多了解。
  以下圖例表示了UA呼叫外網(wǎng)的NAT類型,full cone 對所有外網(wǎng)開發(fā)。
  以下圖例限定僅對IP地址開發(fā),即使用戶使用不同的端口。
  以下圖例限定了用戶使用的端口和IP地址。
  以下圖例說明用戶同時限定了在同一會話時IP地址和端口的匹配。
  總結,在本章節(jié)中我們介紹了關于防火墻的基本概念,另外,我們也討論了NAT的形成和一些關于NAT的打洞的技術討論,以及市場上各種NAT所在比例,我們還通過各種圖例結合SIP場景介紹了NAT的幾種類型。通過以上對NAT的完整介紹,筆者希望用戶對NAT有一個完整的概念。在接下來的章節(jié)中,我們將介紹如何通過各種解決方案來解決NAT的問題。
  參考資料:
  https://tools.ietf.org/html/rfc6314
  https://tools.ietf.org/html/rfc4787
  http://www.brynosaurus.com/pub/net/p2pnat.pdf
  http://conferences.sigcomm.org/co-next/2013/workshops/HotMiddlebox/program/p43.pdf
  https://www.tribler.org/NATMeasurements/
  http://www.ds.ewi.tudelft.nl/reports/2010/PDS-2010-007.pdf
  更多開源VOIP行業(yè)知識,請關注我們的微信號:asterisk-cn, 訪問技術論壇:www.issabel.cn/forum 獲得開源融合通信軟件。
【免責聲明】本文僅代表作者本人觀點,與CTI論壇無關。CTI論壇對文中陳述、觀點判斷保持中立,不對所包含內(nèi)容的準確性、可靠性或完整性提供任何明示或暗示的保證。請讀者僅作參考,并請自行承擔全部責任。

專題