1. 程式人生 > >NAT的完全分析及其UDP穿透的完全解決方案

NAT的完全分析及其UDP穿透的完全解決方案

NAT的完全分析及其UDP穿透的完全解決方案 一:基本術語 防火牆 防火牆限制了私網與公網的通訊,它主要是將(防火牆)認為未經授權的的包丟棄,防火牆只是檢驗包的資料,並不修改資料包中的IP地址和TCP/UDP埠資訊。 網路地址轉換(NAT) 當有資料包通過時,網路地址轉換器不僅檢查包的資訊,還要將包頭中的IP地址和埠資訊進行修改。以使得處於NAT之後的機器共享幾個僅有的公網IP地址(通常是一個)。網路地址轉換器主要有兩種型別. P2P應用程式 P2P應用程式是指,在已有的一個公共伺服器的基礎上,並分別利用自己的私有地址或者公有地址(或者兩者兼備)來建立一個端到端的會話通訊。 P2P防火牆 P2P防火牆是一個提供了防火牆的功能的P2P代理,但是不進行地址轉換.
P2P-NAT P2P-NAT 是一個 P2P代理,提供了NAT的功能,也提供了防火牆的功能,一個最簡的P2P代理必須具有錐形NAT對Udp通訊支援的功能,並允許應用程式利用Udp打洞技術建立強健的P2P連線。 迴環轉換NAT的私網內部機器想通過公共地址來訪問同一臺區域網內的機器的時,NAT裝置等價於做了兩次NAT的事情,在包到達目標機器之前,先將私有地址轉換為公網地址,然後再將公網地址轉換回私有地址。我們把具有上敘轉換功能的NAT裝置叫做“迴環轉換”裝置。 二:NAT分類 可以分為基礎NAT網路地址和埠轉換(NAPT)兩大類 (一):基礎NAT 基礎NAT 將私網主機的私有IP地址轉換成公網IP地址,但並不將TCP/UDP埠資訊進行轉換。基礎NAT
一般用在當NAT擁有很多公網IP地址的時候,它將公網IP地址與內部主機進行繫結,使得外部可以用公網IP地址訪問內部主機。(實際上是隻將IP轉換,192.168.0.23 <-> 210.42.106.35,這與直接設定IP地址為公網IP還是有一定區別的,特別是對於企業來說,外部的資訊都要經過統一防火牆才能到達內部,但是內部主機又可以使用公網IP)
(二):網路地址和埠轉換 (NAPT) 這是最普遍的情況,網路地址/埠轉換器檢查、修改包的IP地址和TCP/UDP埠資訊,這樣,更多的內部主機就可以同時使用一個公網IP地址。 請參考[RFC1631]和[RFC2993]及[RFC2663]這三個文件瞭解更多的NAT分類和術語資訊。另外,關於NAPT的分類和術語,[RFC2663]
做了更多的定義。當一個內部網主機通過NAT開啟一個“外出”的TCP或UDP會話時,NAPT分配給這個會話一個公網IP和埠,用來接收外網的響應的資料包,並經過轉換通知內部網的主機。這樣做的效果是,NAPT[私有IP:私有埠][公網IP:公網埠]之間建立了一個埠繫結。
埠繫結指定了NAPT將在這個會話的生存期內進行地址轉換任務。這中間存在一個這樣的問題,如果P2P應用程式從內部網路的一個[私有IP地址:埠]對同時發出多條會話給不同的外網主機,那麼NAT會怎樣處理呢?這又可以分為錐形NAT (CONE NAT)對稱NAT (SYMMTRIC NAT)兩大類來考慮: A.錐形NAT (為什麼叫做錐形呢?請看以下圖形,終端和外部伺服器,都通過NAT分派的這個繫結地址對來傳送資訊,就象一個漏斗一樣,篩選並傳遞資訊)   當建立了一個 [私有IP:埠]-[公網IP:埠] 埠繫結之後,對於來自同一個[私有IP:埠]會話,錐形NAT伺服器允許發起會話的應用程式 重複使用這個埠繫結,一直到這個會話結束才解除(埠繫結)。   例如,假設 Client A(IP地址資訊如上圖所示)通過一個錐形NAT 同時發起兩個外出的連線,它使用同一個內部埠(10.0.0.1:1234)給公網的兩臺不同的伺服器,S1和S2。錐形NAT 只分配一個公網IP和埠(155.99.25.11:62000)給這個兩個會話,通過地址轉換可以確保 Client使用埠的“同一性”(即這個Client只使用這個埠)。而基礎NATs和防火牆卻不能修改經過的資料包埠號,它們可以看作是錐形NAT的精簡版本。 進一步分析可以將CONE NAT受限制錐形NAT (RESTRICT CONE)埠受限錐形NAT (PORT RESTRICT CONE) 三大類,以下是詳細論述: 分為全雙工錐形NAT (FULL CONE) , 1.全雙工錐形NAT 當內部主機發出一個“外出”的連線會話,就會建立了一個公網/私網 地址,一旦這個地址對被建立,全雙工錐形NAT會接收隨後任何外部埠傳入這個公共埠地址的通訊。因此,全雙工錐形NAT有時候又被稱為"混雜"NAT。 2.受限制錐形NAT 受限制的錐形NAT會對傳入的資料包進行篩選,當內部主機發出“外出”的會話時,NAT會記錄這個外部主機的IP地址資訊,所以,也只有這些有記錄的外部IP地址,能夠將資訊傳入到NAT內部,受限制的錐形NAT 有效的給防火牆提煉了篩選包的原則——即限定只給那些已知的外部地址“傳入”資訊到NAT內部。 3.埠受限錐形NAT 埠受限制的錐形NAT,與受限制的錐形NAT不同的是:它同時記錄了外部主機的IP地址和埠資訊,埠受限制的錐形NAT給內部節點提供了同一級別的保護,在維持埠“同一性”過程中,將會丟棄對稱NAT傳回的資訊。 B.對稱NAT 對稱NAT,與Cone NAT是大不相同的,並不對會話進行埠繫結,而是分配一個全新的公網埠 給每一個新的會話。 還是上面那個例子:如果 Client A (10.0.0.1:1234)同時發起兩個 "外出" 會話,分別發往S1和S2。對稱Nat會分配公共地址155.99.25.11:62000給Session1,然後分配另一個不同的公共地址155.99.25.11:62001給Session2。對稱Nat能夠區別兩個不同的會話並進行地址轉換,因為在 Session1 和 Session2中的外部地址是不同的,正是因為這樣,Client端的應用程式就迷失在這個地址轉換邊界線了,因為這個應用程式每發出一個會話都會使用一個新的埠,無法保障只使用同一個埠了。TCP和UDP通訊中,(到底是使用同一個埠,還是分配不同的埠給同一個應用程式),錐形NAT和對稱NAT各有各的理由。當然錐形NAT在根據如何公平地將NAT接受的連線直達一個已建立的地址對上有更多的分類。這個分類一般應用在Udp通訊(而不是Tcp通訊上),因為NATs和防火牆阻止了試圖無條件傳入的TCP連線,除非明確設定NAT不這樣做。 三:NAT對session的處理 以下分析NAPT是依據什麼策略來判斷是否要為一個請求發出的UDP資料包建立Session的.主要有一下幾個策略: A. 源地址(內網IP地址)不同,忽略其它因素, 在NAPT上肯定對應不同的Session B. 源地址(內網IP地址)相同,源埠不同,忽略其它的因素,則在NAPT上也肯定對應不同的Session C. 源地址(內網IP地址)相同,源埠相同,目的地址(公網IP地址)相同,目的埠不同,則在NAPT上肯定對應同一個Session D. 源地址(內網IP地址)相同,源埠相同,目的地址(公網IP地址)不同,忽略目的埠,則在NAPT上是如何處理Session的呢? A,B,C三種情況的都是比較簡單的,可以很容易的實現.而D的情況就比較複雜了.所以D情況才是我們要重點關心和討論的問題。 四:完全解決方案 以下針對四種SESSION與四種NAT的完全解決方案,為了方便將使用以下縮寫形式: C代表 CONE NAT S代表SYMMETRIC NAT, FC代表 FULL CONE NAT, RC代表 RESTRICT CONE NAT, PC 代表 PORT RESTRICT CONE NAT. 首先依據CLIENT (客戶)端在NAT後 的個數不同可以分為兩大類: TYPE ONE :一個在NAT後 + 一個在公網中. 這種情況下可以分為兩大類: A. S VS 公網:此種情況下,由於公網的地址在一個SESSION內是不變的,所以可以打洞是可以成功的. B. C VS 公網: 與上面類似,這種情口下打洞是可以成功的. TYPE TWO:兩個客戶都在NAT後面. 這種情況下也可以細分為兩大類: A. 其中一個NAT 是 S(SYMMETRIC NAT) 的,既:S VS C或者是S VS S . 下面論證這種情口下按照常規打洞是行不通的,在常規打洞中,所有的客戶首先登陸到一個伺服器上去.伺服器記錄下每個客戶的[公網IP:埠],然後在打洞過程中就使用這個記錄的值,然而對於S的NAT來說,它並不繫結[私網IP:埠][公網IP:埠]的對映.所以在不同的SESSION中,NAT將會重新分配一對[公網IP:埠].這樣一來對於S型的NAT來說打洞的[公網IP:埠]與登記在伺服器上的[公網IP:埠]是不同的.而且也沒有辦法將打洞的[公網IP:埠]通知到另一個位於NAT下的客戶端, 所以打洞是不會成功的.然而如果另一個客戶端是在公網時,打洞是可以的.前面已經論證了這種情況. 這種情況下的解決方案是隻能通過埠預測來進行打洞,具體解決方法如下:例如(以兩個都是S型的為例) NAT A 分配了它自己的UDP埠62000用來保持 客戶端A 伺服器S的通訊會話 NAT B 也分配了31000埠用來保持客戶端B伺服器S 的通訊會話通過與 伺服器S的對話客戶端A 和 客戶端B都相互知道了對方所對映的真實IP和埠 客戶端A傳送一條UDP訊息到138.76.29.7:31001(請注意到埠號的增加)同時客戶端B傳送一條UDP訊息到155.99.25.11:62001如果NAT A 和NAT B繼續分配埠給新的會話,並且從A-S和B-S的會話時間消耗得並不多的話,那麼一條處於客戶端A和客戶端B之間的雙向會話通道就建立了。 客戶端A發出的訊息送達B導致了NAT A打開了一個新的會話,並且我們希望NAT A將會指派62001給這個新的會話,因為62001是繼62000NAT會自動指派給 從伺服器S客戶端A之間的新會話的埠號;類似的,客戶端B發出的訊息送達A導致了 NAT B打開了一個新的會話,並且我們希望 NAT B將會指派31001這個埠給新的會話;如果兩個客戶端都正確的猜測到了對方新會話被指派的埠號,那麼這個 客戶端A-客戶端B的雙向連線就被打通了。其結果如下圖所示: 明顯的,有許多因素會導致這個方法失敗:如果這個預言的新埠(62001和31001) 恰好已經被一個不相關的會話所使用,那麼NAT就會跳過這個埠號,這個連線就會宣告失敗;如果兩個NAT有時或者總是不按照順序來生成新的埠號,那麼這個方法也是行不通的 如果隱藏在NATA後的一個不同的客戶端X(或者在NAT B後)打開了一個新的“外出”UDP 連線,並且無論這個連線的目的如何;只要這個動作發生在客戶端A 建立了與伺服器S的連線之後客戶端A 與 客戶端B 建立連線之前;那麼這個無關的客戶端X 就會趁人不備地“偷” 到這個我們渴望分配的埠。所以,這個方法變得如此脆弱而且不堪一擊,只要任何一個NAT方包含以上碰到的問題,這個方法都不會奏效。 在處於 cone NAT 系列的網路環境中這個方法還是實用的;如果有一方為 cone NAT 而另外一方為 symmetric NAT,那麼應用程式就應該預先發現另外一方的 NAT 是什麼型別,再做出正確的行為來處理通訊,這樣就增大了演算法的複雜度,並且降低了在真實網路環境中的普適性。     最後,如果P2P的一方處在兩級或者兩級以上的NAT下面,並且這些NATS 接近這個客戶端是SYMMETRIC NAT的話,埠號預言是無效的! 因此,並不推薦使用這個方法來寫新的P2P應用程式,這也是歷史的經驗和教訓! B. 兩個都是CONE NAT型. 這種情況下可以分為六大型別: A: FC + FC B: FC + RC C: FC + PC D: PC + RC E: PC + PC F: RC + RC 雖然有這麼多種情況,但是由於CONE NAT 的特性,所以還是很好辦的,因為對於CONE NAT 來說,在同一個SESSION中它會繫結一對[私網IP:埠][公網IP:埠]的對映,所以它們打洞用的[公網IP:埠]與登記在伺服器上的[公網IP:埠]是一致的,所以打洞是可以行的通的. 綜上所述,就已經完全的概括了所有型別的NAT之間的可能的通訊情況了.並且都提供了可行的解決方案. 五:對前一階段的總結 1.前一階段使用的打洞方法是有缺陷的,它只適應於兩個都是FULL CONE NAT的型別的CLIENT(客戶端).以下論證它不適應於兩個都是CONE NAT的型別中的 B: FC + RC C: FC + PC D: PC + RC E: PC + PC F: RC + RC 這五種情況. 因為對於受限的NAT它登記了外出包的[IP地址&埠],它僅僅接受這些已登記地址發過來的包,所以它們報告伺服器的埠只能接受來自伺服器的包.不能接受來自另一客戶端的包.所以前一階段的打洞方法是不可行的. 六: 存在的問題 按照理論.NAT將在一定時間後關閉UDP的一個對映,所以為了保持與伺服器能夠一直通訊,伺服器必須要傳送UDP心跳包,來保持對映不被關閉.這就需要一個合適的時間值.