默認
打賞 發表評論 23
P2P技術詳解(一):NAT詳解——詳細原理、P2P簡介
閱讀(241092) | 評論(23 收藏46 淘帖1 8

這是一篇介紹NAT技術要點的精華文章,來自華3通信官方資料庫,文中對NAT技術原理的介紹很全面也很權威,對網絡應用的應用層開發人員而言有很高的參考價值。


《P2P技術詳解》系列文章


本文是《P2P理論詳解》系列文章中的第2篇,總目錄如下:


P2P相關的其它資源:


另外,如果你覺得本文對網絡通信的基礎知識講的不夠系統話,可繼續看看下面這些精華文章大餐。

➊ 網絡編程基礎知識:


➋ 如果覺得上面的文章枯燥,則《網絡編程懶人入門》系列可能是你的菜:


➌ 如果感到自已已經很牛逼了,《不為人知的網絡編程》應該是你菜:


➍ 如果看完上面的文章還是躁動不安,那看看《高性能網絡編程系列》吧:

1. IPv4協議和NAT的由來


今天,無數快樂的互聯網用戶在盡情享受Internet帶來的樂趣。他們瀏覽新聞,搜索資料,下載軟件,廣交新朋,分享信息,甚至于足不出戶獲取一切日用所需。企業利用互聯網發布信息,傳遞資料和訂單,提供技術支持,完成日常辦公。然而,Internet在給億萬用戶帶來便利的同時,自身卻面臨一個致命的問題:構建這個無所不能的Internet的基礎IPv4協議已經不能再提供新的網絡地址了。

2011年2月3日中國農歷新年, IANA對外宣布:IPv4地址空間最后5個地址塊已經被分配給下屬的5個地區委員會。2011年4月15日,亞太區委員會APNIC對外宣布,除了個別保留地址外,本區域所有的IPv4地址基本耗盡。一時之間,IPv4地址作為一種瀕危資源身價陡增,各大網絡公司出巨資收購剩余的空閑地址。其實,IPv4地址不足問題已不是新問題,早在20年以前,IPv4地址即將耗盡的問題就已經擺在Internet先驅們面前。這不禁讓我們想去了解,是什么技術使這一危機延緩了盡20年。

要找到問題的答案,讓我們先來簡略回顧一下IPv4協議。

IPv4即網際網協議第4版——Internet Protocol Version 4的縮寫。IPv4定義一個跨越異種網絡互連的超級網,它為每個網際網的節點分配全球唯一IP地址。如果我們把Internet比作一個郵政系統,那么IP地址的作用就等同于包含城市、街區、門牌編號在內的完整地址。IPv4使用32bits整數表達一個地址,地址最大范圍就是232 約為43億。以IP創始時期可被聯網的設備來看,這樣的一個空間已經很大,很難被短時間用完。然而,事實遠遠超出人們的設想,計算機網絡在此后的幾十年里迅速壯大,網絡終端數量呈爆炸性增長。

更為糟糕的是,為了路由和管理方便,43億的地址空間被按照不同前綴長度劃分為A,B,C,D類地址網絡和保留地址。其中,A類網絡地址127段,每段包括主機地址約1678萬個。B類網絡地址16384段,每段包括65536個主機地址。

P2P技術詳解(一):NAT詳解——詳細原理、P2P簡介_圖1 IPv4網絡地址劃分
圖1 IPv4網絡地址劃分

IANA向超大型企業/組織分配A類網絡地址,一次一段。向中型企業或教育機構分配B類網絡地址,一次一段。這樣一種分配策略使得IP地址浪費很嚴重,很多被分配出去的地址沒有真實被利用,地址消耗很快。以至于二十世紀90年代初,網絡專家們意識到,這樣大手大腳下去,IPv4地址很快就要耗光了。于是,人們開始考慮IPv4的替代方案,同時采取一系列的措施來減緩IPv4地址的消耗。正是在這樣一個背景之下,本期的主角閃亮登場,它就是網絡地址轉換——NAT。

NAT是一項神奇的技術,說它神奇在于它的出現幾乎使IPv4起死回生。在IPv4已經被認為行將結束歷史使命之后近20年時間里,人們幾乎忘了IPv4的地址空間即將耗盡這樣一個事實——在新技術日新月異的時代,20年可算一段漫長的歷史。更不用說,在NAT產生以后,網絡終端的數量呈加速上升趨勢,對IP地址的需求劇烈增加。此足見NAT技術之成功,影響之深遠。

說它神奇,更因為NAT給IP網絡模型帶來了深遠影響,其身影遍布網絡每個角落。根據一份最近的研究報告,70%的P2P用戶位于NAT網關以內。因為P2P主要運行在終端用戶的個人電腦之上,這個數字意味著大多數PC通過NAT網關連接到Internet。如果加上2G和3G方式聯網的智能手機等移動終端,在NAT網關之后的用戶遠遠超過這個比例。

然而當我們求本溯源時卻發現一個很奇怪的事實:NAT這一意義重大的技術,竟然沒有公認的發明者。NAT第一個版本的RFC作者,只是整理歸納了已被廣泛采用的技術。

2. NAT的工作模型和特點


2.1 NAT的概念模型


NAT名字很準確,網絡地址轉換,就是替換IP報文頭部的地址信息。NAT通常部署在一個組織的網絡出口位置,通過將內部網絡IP地址替換為出口的IP地址提供公網可達性和上層協議的連接能力。那么,什么是內部網絡IP地址?

RFC1918規定了三個保留地址段落:10.0.0.0-10.255.255.255;172.16.0.0-172.31.255.255;192.168.0.0-192.168.255.255。這三個范圍分別處于A,B,C類的地址段,不向特定的用戶分配,被IANA作為私有地址保留。這些地址可以在任何組織或企業內部使用,和其他Internet地址的區別就是,僅能在內部使用,不能作為全球路由地址。這就是說,出了組織的管理范圍這些地址就不再有意義,無論是作為源地址,還是目的地址。對于一個封閉的組織,如果其網絡不連接到Internet,就可以使用這些地址而不用向IANA提出申請,而在內部的路由管理和報文傳遞方式與其他網絡沒有差異。

對于有Internet訪問需求而內部又使用私有地址的網絡,就要在組織的出口位置部署NAT網關,在報文離開私網進入Internet時,將源IP替換為公網地址,通常是出口設備的接口地址。一個對外的訪問請求在到達目標以后,表現為由本組織出口設備發起,因此被請求的服務端可將響應由Internet發回出口網關。出口網關再將目的地址替換為私網的源主機地址,發回內部。這樣一次由私網主機向公網服務端的請求和響應就在通信兩端均無感知的情況下完成了。依據這種模型,數量龐大的內網主機就不再需要公有IP地址了。

P2P技術詳解(一):NAT詳解——詳細原理、P2P簡介_圖2 NAT轉換過程示意圖
圖2 NAT轉換過程示意圖

雖然實際過程遠比這個復雜,但上面的描述概括了NAT處理報文的幾個關鍵特點:

1. 網絡被分為私網和公網兩個部分,NAT網關設置在私網到公網的路由出口位置,雙向流量必須都要經過NAT網關;
2. 網絡訪問只能先由私網側發起,公網無法主動訪問私網主機;
3. NAT網關在兩個訪問方向上完成兩次地址的轉換或翻譯,出方向做源信息替換,入方向做目的信息替換;
4. NAT網關的存在對通信雙方是保持透明的;
5. NAT網關為了實現雙向翻譯的功能,需要維護一張關聯表,把會話的信息保存下來。


隨著后面對NAT的深入描述,讀者會發現,這些特點是鮮明的,但又不是絕對的。其中第二個特點打破了IP協議架構中所有節點在通訊中的對等地位,這是NAT最大的弊端,為對等通訊帶來了諸多問題,當然相應的克服手段也應運而生。事實上,第四點是NAT致力于達到的目標,但在很多情況下,NAT并沒有做到,因為除了IP首部,上層通信協議經常在內部攜帶IP地址信息。這些我們稍后解釋。

2.2 一對一的NAT


如果一個內部主機唯一占用一個公網IP,這種方式被稱為一對一模型。此種方式下,轉換上層協議就是不必要的,因為一個公網IP就能唯一對應一個內部主機。顯然,這種方式對節約公網IP沒有太大意義,主要是為了實現一些特殊的組網需求。比如用戶希望隱藏內部主機的真實IP,或者實現兩個IP地址重疊網絡的通信。

2.3 一對多的NAT


NAT最典型的應用場景就如同圖2描述的,一個組織網絡,在出口位置部署NAT網關,所有對公網的訪問表現為一臺主機。這就是所謂的一對多模型。這種方式下,出口設備只占用一個由Internet服務提供商分配的公網IP地址。面對私網內部數量龐大的主機,如果NAT只進行IP地址的簡單替換,就會產生一個問題:當有多個內部主機去訪問同一個服務器時,從返回的信息不足以區分響應應該轉發到哪個內部主機。此時,需要NAT設備根據傳輸層信息或其他上層協議去區分不同的會話,并且可能要對上層協議的標識進行轉換,比如TCP或UDP端口號。這樣NAT網關就可以將不同的內部連接訪問映射到同一公網IP的不同傳輸層端口,通過這種方式實現公網IP的復用和解復用。這種方式也被稱為端口轉換PAT、NAPT或IP偽裝,但更多時候直接被稱為NAT,因為它是最典型的一種應用模式。

2.4 按照NAT端口映射方式分類


在一對多模型中,按照端口轉換的工作方式不同,又可以進行更進一步的劃分。為描述方便,以下將IP和端口標記為(nAddr:nPort),其中n代表主機或NAT網關的不同角色。

P2P技術詳解(一):NAT詳解——詳細原理、P2P簡介_ 圖3 按照端口轉換映射方式分類
圖3 按照端口轉換映射方式分類

    全錐形NAT
其特點為:一旦內部主機端口對(iAddr:iPort)被NAT網關映射到(eAddr:ePort),所有后續的(iAddr:iPort)報文都會被轉換為(eAddr:ePort);任何一個外部主機發送到(eAddr:ePort)的報文將會被轉換后發到(iAddr:iPort)。

    限制錐形NAT
其特點為:一旦內部主機端口對(iAddr:iPort)被映射到(eAddr:ePort),所有后續的(iAddr:iPort)報文都會被轉換為(eAddr:ePort);只有 (iAddr:iPort)向特定的外部主機hAddr發送過數據,主機hAddr從任意端口發送到(eAddr:ePort)的報文將會被轉發到(iAddr:iPort)。

    端口限制錐形NAT
其特點為:一旦內部主機端口對(iAddr:iPort)被映射到(eAddr:ePort),所有后續的(iAddr:iPort)報文都會被轉換為(eAddr:ePort);只有(iAddr:iPort)向特定的外部主機端口對(hAddr:hPort)發送過數據,由 (hAddr:hPort)發送到(eAddr:ePort)的報文將會被轉發到(iAddr:iPort)。

    對稱型NAT
其特點為:NAT網關會把內部主機“地址端口對”和外部主機“地址端口對”完全相同的報文看作一個連接,在網關上創建一個公網“地址端口對”映射進行轉換,只有收到報文的外部主機從對應的端口對發送回應的報文,才能被轉換。即使內部主機使用之前用過的地址端口對去連接不同外部主機(或端口)時,NAT網關也會建立新的映射關系。

事實上,這些術語的引入是很多混淆的起源。現實中的很多NAT設備是將這些轉換方式混合在一起工作的,而不單單使用一種,所以這些術語只適合描述一種工作方式,而不是一個設備。比如,很多NAT設備對內部發出的連接使用對稱型NAT方式,而同時支持靜態的端口映射,后者可以被看作是全錐型NAT方式。而有些情況下,NAT設備的一個公網地址和端口可以同時映射到內部幾個服務器上以實現負載分擔,比如一個對外提供WEB服務器的站點可能是有成百上千個服務器在提供HTTP服務,但是對外卻表現為一個或少數幾個IP地址。

3. NAT的限制與解決方案


3.1 IP端到端服務模型


IP協議的一個重要貢獻是把世界變得平等。在理論上,具有IP地址的每個站點在協議層面有相當的獲取服務和提供服務的能力,不同的IP地址之間沒有差異。人們熟知的服務器和客戶機實際是在應用協議層上的角色區分,而在網絡層和傳輸層沒有差異。一個具有IP地址的主機既可以是客戶機,也可以是服務器,大部分情況下,既是客戶機,也是服務器。端到端對等看起來是很平常的事情,而意義并不尋常。但在以往的技術中,很多協議體系下的網絡限定了終端的能力。正是IP的這個開放性,使得TCP/IP協議族可以提供豐富的功能,為應用實現提供了廣闊平臺。因為所有的IP主機都可以服務器的形式出現,所以通訊設計可以更加靈活。使用UNIX/LINUX的系統充分利用了這個特性,使得任何一個主機都可以建立自己的HTTP、SMTP、POP3、DNS、DHCP等服務。與此同時,很多應用也是把客戶端和服務器的角色組合起來完成功能。例如在VoIP應用中,用戶端向注冊服務器登錄自己的IP地址和端口信息過程中,主機是客戶端;而在呼叫到達時,呼叫處理服務器向用戶端發送呼叫請求時,用戶端實際工作在服務器模式下。在語音媒體流信道建立過程后,通訊雙向發送語音數據,發送端是客戶模式,接收端是服務器模式。而在P2P的應用中,一個用戶的主機既為下載的客戶,同時也向其他客戶提供數據,是一種C/S混合的模型。上層應用之所以能這樣設計,是因為IP協議棧定義了這樣的能力。試想一下,如果IP提供的能力不對等,那么每個通信會話都只能是單方向發起的,這會極大限制通信的能力。細心的讀者會發現,前面介紹NAT的一個特性正是這樣一種限制。沒錯,NAT最大的弊端正在于此——破壞了IP端到端通信的能力。

3.2 NAT的弊端


NAT在解決IPv4地址短缺問題上,并非沒有副作用,其實存在很多問題。

首先,NAT使IP會話的保持時效變短。因為一個會話建立后會在NAT設備上建立一個關聯表,在會話靜默的這段時間,NAT網關會進行老化操作。這是任何一個NAT網關必須做的事情,因為IP和端口資源有限,通信的需求無限,所以必須在會話結束后回收資源。通常TCP會話通過協商的方式主動關閉連接,NAT網關可以跟蹤這些報文,但總是存在例外的情況,要依賴自己的定時器去回收資源。而基于UDP的通信協議很難確定何時通信結束,所以NAT網關主要依賴超時機制回收外部端口。通過定時器老化回收會帶來一個問題,如果應用需要維持連接的時間大于NAT網關的設置,通信就會意外中斷。因為網關回收相關轉換表資源以后,新的數據到達時就找不到相關的轉換信息,必須建立新的連接。當這個新數據是由公網側向私網側發送時,就會發生無法觸發新連接建立,也不能通知到私網側的主機去重建連接的情況。這時候通信就會中斷,不能自動恢復。即使新數據是從私網側發向公網側,因為重建的會話表往往使用不同于之前的公網IP和端口地址,公網側主機也無法對應到之前的通信上,導致用戶可感知的連接中斷。NAT網關要把回收空閑連接的時間設置到不發生持續的資源流失,又維持大部分連接不被意外中斷,是一件比較有難度的事情。在NAT已經普及化的時代,很多應用協議的設計者已經考慮到了這種情況,所以一般會設置一個連接保活的機制,即在一段時間沒有數據需要發送時,主動發送一個NAT能感知到而又沒有實際數據的保活消息,這么做的主要目的就是重置NAT的會話定時器。

其次,NAT在實現上將多個內部主機發出的連接復用到一個IP上,這就使依賴IP進行主機跟蹤的機制都失效了。如網絡管理中需要的基于網絡流量分析的應用無法跟蹤到終端用戶與流量的具體行為的關系。基于用戶行為的日志分析也變得困難,因為一個IP被很多用戶共享,如果存在惡意的用戶行為,很難定位到發起連接的那個主機。即便有一些機制提供了在NAT網關上進行連接跟蹤的方法,但是把這種變換關系接續起來也困難重重。基于IP的用戶授權不再可靠,因為擁有一個IP的不等于一個用戶或主機。一個服務器也不能簡單把同一IP的訪問視作同一主機發起的,不能進行關聯。有些服務器設置有連接限制,同一時刻只接納來自一個IP的有限訪問(有時是僅一個訪問),這會造成不同用戶之間的服務搶占和排隊。有時服務器端這樣做是出于DOS攻擊防護的考慮,因為一個用戶正常情況下不應該建立大量的連接請求,過度使用服務資源被理解為攻擊行為。但是這在NAT存在時不能簡單按照連接數判斷。總之,因為NAT隱蔽了通信的一端,把簡單的事情復雜化了。

我們來深入理解NAT一下對IP端到端模型的破壞力。NAT通過修改IP首部的信息變換通信的地址。但是在這個轉換過程中只能基于一個會話單位。當一個應用需要保持多個雙向連接時,麻煩就很大。NAT不能理解多個會話之間的關聯性,無法保證轉換符合應用需要的規則。當NAT網關擁有多個公有IP地址時,一組關聯會話可能被分配到不同的公網地址,這通常是服務器端無法接受的。更為嚴重的是,當公網側的主機要主動向私網側發送數據時,NAT網關沒有轉換這個連接需要的關聯表,這個數據包無法到達私網側的主機。這些反方向發送數據的連接總有應用協議的約定或在初始建立的會話中進行過協商。但是因為NAT工作在網絡層和傳輸層,無法理解應用層協議的行為,對這些信息是無知的。NAT希望自己對通信雙方是透明的,但是在這些情況下這是一種奢望。

P2P技術詳解(一):NAT詳解——詳細原理、P2P簡介_圖4 NAT對端到端通信模型的破壞
圖4 NAT對端到端通信模型的破壞

此外,NAT工作機制依賴于修改IP包頭的信息,這會妨礙一些安全協議的工作。因為NAT篡改了IP地址、傳輸層端口號和校驗和,這會導致認證協議徹底不能工作,因為認證目的就是要保證這些信息在傳輸過程中沒有變化。對于一些隧道協議,NAT的存在也導致了額外的問題,因為隧道協議通常用外層地址標識隧道實體,穿過NAT的隧道會有IP復用關系,在另一端需要小心處理。ICMP是一種網絡控制協議,它的工作原理也是在兩個主機之間傳遞差錯和控制消息,因為IP的對應關系被重新映射,ICMP也要進行復用和解復用處理,很多情況下因為ICMP報文載荷無法提供足夠的信息,解復用會失敗。IP分片機制是在信息源端或網絡路徑上,需要發送的IP報文尺寸大于路徑實際能承載最大尺寸時,IP協議層會將一個報文分成多個片斷發送,然后在接收端重組這些片斷恢復原始報文。IP這樣的分片機制會導致傳輸層的信息只包括在第一個分片中,NAT難以識別后續分片與關聯表的對應關系,因此需要特殊處理。

3.3 NAT穿越技術


前面解釋了NAT的弊端,為了解決IP端到端應用在NAT環境下遇到的問題,網絡協議的設計者們創造了各種武器來進行應對。但遺憾的是,這里每一種方法都不完美,還需要在內部主機、應用程序或者NAT網關上增加額外的處理。

    應用層網關
應用層網關(ALG)是解決NAT對應用層協議無感知的一個最常用方法,已經被NAT設備廠商廣泛采用,成為NAT設備的一個必需功能。因為NAT不感知應用協議,所以有必要額外為每個應用協議定制協議分析功能,這樣NAT網關就能理解并支持特定的協議。ALG與NAT形成互動關系,在一個NAT網關檢測到新的連接請求時,需要判斷是否為已知的應用類型,這通常是基于連接的傳輸層端口信息來識別的。在識別為已知應用時,再調用相應功能對報文的深層內容進行檢查,當發現任何形式表達的IP地址和端口時,將會把這些信息同步轉換,并且為這個新連接創建一個附加的轉換表項。這樣,當報文到達公網側的目的主機時,應用層協議中攜帶的信息就是NAT網關提供的地址和端口。一旦公網側主機開始發送數據或建立連接到此端口,NAT網關就可以根據關聯表信息進行轉換,再把數據轉發到私網側的主機。很多應用層協議實現不限于一個初始連接(通常為信令或控制通道)加一個數據連接,可能是一個初始連接對應很多后續的新連接。比較特別的協議,在一次協商中會產生一組相關連接,比如RTP/RTCP協議規定,一個RTP通道建立后占用連續的兩個端口,一個服務于數據,另一個服務于控制消息。此時,就需要ALG分配連續的端口為應用服務。ALG能成功解決大部分協議的NAT穿越需求,但是這個方法也有很大的限制。因為應用協議的數量非常多而且在不斷發展變化之中,添加到設備中的ALG功能都是為特定協議的特定規范版本而開發的,協議的創新和演進要求NAT設備制造商必須跟蹤這些協議的最近標準,同時兼容舊標準。盡管有如Linux這種開放平臺允許動態加載新的ALG特性,但是管理成本仍然很高,網絡維護人員也不能隨時了解用戶都需要什么應用。因此為每個應用協議開發ALG代碼并跟蹤最新標準是不可行的,ALG只能解決用戶最常用的需求。此外,出于安全性需要,有些應用類型報文從源端發出就已經加密,這種報文在網絡中間無法進行分析,所以ALG無能為力。

    探針技術STUN和TURN
所謂探針技術,是通過在所有參與通信的實體上安裝探測插件,以檢測網絡中是否存在NAT網關,并對不同NAT模型實施不同穿越方法的一種技術。STUN服務器被部署在公網上,用于接收來自通信實體的探測請求,服務器會記錄收到請求的報文地址和端口,并填寫到回送的響應報文中。客戶端根據接收到的響應消息中記錄的地址和端口與本地選擇的地址和端口進行比較,就能識別出是否存在NAT網關。如果存在NAT網關,客戶端會使用之前的地址和端口向服務器的另外一個IP發起請求,重復前面的探測。然后再比較兩次響應返回的結果判斷出NAT工作的模式。由前述的一對多轉換模型得知,除對稱型NAT以外的模型,NAT網關對內部主機地址端口的映射都是相對固定的,所以比較容易實現NAT穿越。而對稱型NAT為每個連接提供一個映射,使得轉換后的公網地址和端口對不可預測。此時TURN可以與STUN綁定提供穿越NAT的服務,即在公網服務器上提供一個“地址端口對”,所有此“地址端口對”接收到的數據會經由探測建立的連接轉發到內網主機上。TURN分配的這個映射“地址端口對”會通過STUN響應發給內部主機,后者將此信息放入建立連接的信令中通知通信的對端。這種探針技術是一種通用方法,不用在NAT設備上為每種應用協議開發功能,相對于ALG方式有一定普遍性。但是TURN中繼服務會成為通信瓶頸。而且在客戶端中增加探針功能要求每個應用都要增加代碼才能支持。

    中間件技術
這也是一種通過開發通用方法解決NAT穿越問題的努力。與前者不同之處是,NAT網關是這一解決方案的參與者。與ALG的不同在于,客戶端會參與網關公網映射信息的維護,此時NAT網關只要理解客戶端的請求并按照要求去分配轉換表,不需要自己去分析客戶端的應用層數據。其中UPnP就是這樣一種方法。UPnP中文全稱為通用即插即用,是一個通用的網絡終端與網關的通信協議,具備信息發布和管理控制的能力。其中,網關映射請求可以為客戶動態添加映射表項。此時,NAT不再需要理解應用層攜帶的信息,只轉換IP地址和端口信息。而客戶端通過控制消息或信令發到公網側的信息中,直接攜帶公網映射的IP地址和端口,接收端可以按照此信息建立數據連接。NAT網關在收到數據或連接請求時,按照UPnP建立的表項只轉換地址和端口信息,不關心內容,再將數據轉發到內網。這種方案需要網關、內部主機和應用程序都支持UPnP技術,且組網允許內部主機和NAT網關之間可以直接交換UPnP信令才能實施。

    中繼代理技術
準確說它不是NAT穿越技術,而是NAT旁路技術。簡單說,就是在NAT網關所在的位置旁邊放置一個應用服務器,這個服務器在內部網絡和外部公網分別有自己的網絡連接。客戶端特定的應用產生網絡請求時,將定向發送到應用代理服務器。應用代理服務器根據代理協議解析客戶端的請求,再從服務器的公網側發起一個新的請求,把客戶端請求的內容中繼到外部網絡上,返回的相應反方向中繼。這項技術和ALG有很大的相似性,它要求為每個應用類型部署中繼代理業務,中間服務器要理解這些請求。

    特定協議的自穿越技術
在所有方法中最復雜也最可靠的就是自己解決自己的問題。比如IKE和IPsec技術,在設計時就考慮了到如何穿越NAT的問題。因為這個協議是一個自加密的協議并且具有報文防修改的鑒別能力,其他通用方法愛莫能助。因為實際應用的NAT網關基本都是NAPT方式,所有通過傳輸層協議承載的報文可以順利通過NAT。IKE和IPsec采用的方案就是用UDP在報文外面再加一層封裝,而內部的報文就不再受到影響。IKE中還專門增加了NAT網關是否存在的檢查能力以及繞開NAT網關檢測IKE協議的方法。

4. NAT的應用和實現


4.1 NAT的應用


NAT在當代Internet中被廣泛采用,小至家庭網關,大到企業廣域網出口甚至運營商業務網絡出口。其實NAT在用戶身邊隨處可見,一般家庭寬帶接入的ADSL Modem和SOHO路由器都內置了NAT功能,WindowsXP支持網絡連接共享,一個用戶連接到公網可能會經過多層NAT而對此一無所知。很多企業也為節約IP費用采用NAT接入Internet,但是相比家庭用戶有更復雜的需求。

    NAT多實例應用
在VPN網絡中,多實例路由意味著一個物理拓撲上承載多個邏輯拓撲,網絡終端被分配到相互隔離的邏輯拓撲中,彼此之間沒有路由的通路。但在訪問Internet或者一些關鍵服務器資源時,被隔離的網絡之間又存在共享資源的需求。NAT的多實例實現就是跨越這種邏輯拓撲的方法,把一個空間的網絡地址映射到另一個空間。

    NAT的高可靠性組網
提高網絡可靠性是一個廣泛的需求,NAT作為私網到公網的關鍵路徑自然也需要高可靠性。當一個設備提供多個公網接口時,在多接口上部署NAT可以提供更高帶寬和多ISP就近訪問的能力。但是,當部署多個出口時,訪問的流量可能會從不匹配的接口返回,這就要求NAT方案有良好的路由規劃和部署合適的策略保證這種流量能夠正確處理。在多個物理設備承擔NAT功能時,不同設備之間的信息備份和流量分擔也是一個組網難題。

    同時轉換源和目的地址的應用
前面我們介紹的所有NAT應用中,由內網向外網訪問過程中,都是將源地址進行轉換而目的地址保持不變,報文反方向進入時則處理目的地址。但有一些特殊應用需要在由內向外的IP通路上,替換目的IP地址。通常,這種應用會同時替換源地址和目的地址,在經過NAT網關以后完成兩次地址轉換。當兩個均規劃使用私屬IP地址范圍的網絡進行合并時,終端用戶都不想調整自己的IP地址方案,又希望開放一些網絡資源給彼此訪問。這時就可以通過NAT的兩次地址轉換來解決路由和地址規劃無法解決的問題。

P2P技術詳解(一):NAT詳解——詳細原理、P2P簡介_圖5 同時轉換源和目的地址的應用
圖5 同時轉換源和目的地址的應用

4.2 NAT的設備實現


NAT作為一個IP層業務特性,在產品實現中與防火墻、會話管理等特性有緊密聯系,這是因為NAT判斷一個進入設備的報文是否需要NAT處理,判斷報文是否為一個新的連接,都需要通過匹配訪問控制列表規則和查詢會話關聯表進行判斷。為了滿足不同應用場景的NAT需求, NAT的管理界面可提供用戶多種配置策略。按照NAT的具體工作方式,又可以做如下分類。

    靜態一對一地址映射
這種工作方式下,NAT把一個私網地址和一個公網地址做靜態關聯,在從內而外的方向,將源IP匹配的私網IP替換為公網IP,反方向則將目的IP匹配公網IP的報文替換為私網IP。網絡層以上的部分不進行替換處理,只修正校驗和。

    靜態多對多地址映射
這種方式與上一種類似,只是把一段私網地址映射到一段公網地址。工作機制與前述的方式沒有差別,只是簡化配置工作量。

    動態端口映射
這是最基本的工作方式,即前面多次介紹的將一段內網地址動態翻譯為一個或多個公網IP,同時對傳輸層端口或其他上層協議信息進行轉換,以實現IP復用。對由內而外的報文,替換源地址和端口,反向報文替換目的地址和端口。僅以連接公網的接口IP作為NAT轉換的公網地址時,這種配置最簡化,又被稱為EasyIP。當以一段公網IP地址作為NAT轉換地址時,需要配置一個地址池,NAT會自動在地址池中選擇使用公網IP。

    動態地址映射(no-pat)
這是介于靜態多對多地址映射和動態端口映射方式之間的一種工作機制。當有一個私網向公網側訪問到達NAT網關時,NAT網關會檢查這個私網IP是否已經有關聯的公網IP映射。如果已經存在,則按照轉換表直接替換IP,不修改上層協議。如果不存在關聯表項,則在空閑的公網IP池中占用一個IP,并寫入關聯表中,以后按照這個關聯關系進行地址轉換。當這個私網主機發起的所有對外訪問均關閉或超時后,回收公網IP。這種方式可以理解為一組內網主機搶占式地共享一個公網IP地址池。當公網IP地址池用完以后,新連接將無法建立。

    靜態端口映射
通過靜態配置,把一個固定的私網IP地址和端口關聯到一個公網地址和端口上。這種方式等同于前面介紹過的全錐模式,但是不需要內網主機首先發出報文。這種方式適用于在NAT網關上把一個知名服務(如HTTP)映射到一個內部主機上,也稱為port forwarding。

    應用層網關(ALG)
在所有NAT產品實現中,ALG是一個必需的功能組件。但在不同實現中,有些產品可以動態加載不同的ALG模塊,有些產品可以提供ALG開關控制,有些則不提供任何用戶接口。ALG解析上層應用協議的內容,并且根據需要修改IP和端口相關信息,創建和維護附加的關聯表項。

    NAT轉換關聯表
無論哪一種NAT工作方式,都要用到地址轉換關聯表,在不同產品的實現中,這個關聯表的存儲結構和在IP轉發中調用的方式有很大不同。關聯表中會記錄源IP、目的IP、連接協議類型、傳輸層源端口、目的端口,以及轉換后的源IP、源端口,目的IP、目的端口信息,這里的源和目的都是對應于從內網到外網的訪問方向。依據NAT具體工作方式,這些信息可能全部填充,也可能部分填充。例如只按照IP做靜態映射的方式,就不需要填入任何端口相關信息;對于靜態端口映射,則只填入源相關的內容,而目的端的信息為空。

5. 后IPv4時代的NAT


NAT是為延緩IPv4地址耗盡而推出的技術。毫無疑問,它已經出色完成了自己的歷史使命,IPv4比預期走得更遠。作為繼任者的IPv6吸取了IPv4的教訓,被賦予充足地址空間的同時在各個方面做了優化——安全、高效、簡潔。但是IPv6無法平滑地取代IPv4,導致IP升級步伐緩慢。盡管網絡協議的分層設計很清晰,大量應用層協議和互聯網軟件中仍內嵌了IPv4地址的處理,要Internet全網升級到IPv6,必須先完成應用的改造。因為NAT和它的穿越技術結合能夠滿足大部分用戶的需求,所以IPv6時代被不斷推遲。

隨著IPv4地址的瀕臨耗盡,再經濟的模式也無以為繼,IPv4必須退出歷史舞臺。人們自然會認為,NAT作為IPv4的超級補丁技術使命已經完結。實際情況是,IPv4向IPv6過渡的階段,NAT仍然是一項必不可少的技術手段。因為Internet無法在一日之內完成全網升級,必然是局部升級,逐漸替換。在兩套協議并存的時期,用戶和服務資源分布在不同網絡之間,跨網訪問的需求必須得到滿足。這正是NAT所擅長的領域,地址替換,因此NAT-PT應運而生。由于IPv4和IPv6之間的差異,NAT要做的事比以往更復雜,有更多的限制和細節。

此外,IETF也在制定純IPv6網絡使用的NAT規范。雖然人們還看不到這種應用的強烈需求,但是NAT仍有其獨特的作用,比如隱藏內部網絡的地址,實現重疊地址網絡的合并等。

毫不夸張地說,正是有了NAT,以IPv4為基礎的Internet才能容納數十億的用戶終端,成就今日之輝煌。IPv4已至日暮西山,IPv6的黎明尚未來臨,Internet比任何時刻都更依賴NAT這項過渡技術。NAT的歷史再次證明,翻天覆地的劃時代進步不一定有市場,抱殘守缺的修修補補未必不會成功。在世代更替之時讓我們走近NAT,領略IP領域更多細微但不高深的知識,理解NAT就是理解變換萬千的應用世界。

全站即時通訊技術資料分類


[1] 網絡編程基礎資料:
TCP/IP詳解 - 第11章·UDP:用戶數據報協議
TCP/IP詳解 - 第17章·TCP:傳輸控制協議
TCP/IP詳解 - 第18章·TCP連接的建立與終止
TCP/IP詳解 - 第21章·TCP的超時與重傳
理論經典:TCP協議的3次握手與4次揮手過程詳解
理論聯系實際:Wireshark抓包分析TCP 3次握手、4次揮手過程
計算機網絡通訊協議關系圖(中文珍藏版)
NAT詳解:基本原理、穿越技術(P2P打洞)、端口老化等
UDP中一個包的大小最大能多大?
Java新一代網絡編程模型AIO原理及Linux系統AIO介紹
NIO框架入門(三):iOS與MINA2、Netty4的跨平臺UDP雙向通信實戰
NIO框架入門(四):Android與MINA2、Netty4的跨平臺UDP雙向通信實戰
>> 更多同類文章 ……

[2] 有關IM/推送的通信格式、協議的選擇:
為什么QQ用的是UDP協議而不是TCP協議?
移動端即時通訊協議選擇:UDP還是TCP?
如何選擇即時通訊應用的數據傳輸格式
強列建議將Protobuf作為你的即時通訊應用數據傳輸格式
移動端IM開發需要面對的技術問題(含通信協議選擇)
簡述移動端IM開發的那些坑:架構設計、通信協議和客戶端
理論聯系實際:一套典型的IM通信協議設計詳解
58到家實時消息系統的協議設計等技術實踐分享
>> 更多同類文章 ……

[3] 有關IM/推送的心跳保活處理:
Android進程保活詳解:一篇文章解決你的所有疑問
Android端消息推送總結:實現原理、心跳保活、遇到的問題等
為何基于TCP協議的移動端IM仍然需要心跳保活機制?
微信團隊原創分享:Android版微信后臺保活實戰分享(進程保活篇)
微信團隊原創分享:Android版微信后臺保活實戰分享(網絡保活篇)
移動端IM實踐:實現Android版微信的智能心跳機制
移動端IM實踐:WhatsApp、Line、微信的心跳策略分析
>> 更多同類文章 ……

[4] 有關WEB端即時通訊開發:
新手入門貼:史上最全Web端即時通訊技術原理詳解
Web端即時通訊技術盤點:短輪詢、Comet、Websocket、SSE
SSE技術詳解:一種全新的HTML5服務器推送事件技術
Comet技術詳解:基于HTTP長連接的Web端實時通信技術
WebSocket詳解(一):初步認識WebSocket技術
socket.io實現消息推送的一點實踐及思路
>> 更多同類文章 ……

[5] 有關IM架構設計:
淺談IM系統的架構設計
簡述移動端IM開發的那些坑:架構設計、通信協議和客戶端
一套原創分布式即時通訊(IM)系統理論架構方案
從零到卓越:京東客服即時通訊系統的技術架構演進歷程
蘑菇街即時通訊/IM服務器開發之架構選擇
騰訊QQ1.4億在線用戶的技術挑戰和架構演進之路PPT
微信技術總監談架構:微信之道——大道至簡(演講全文)
如何解讀《微信技術總監談架構:微信之道——大道至簡》
快速裂變:見證微信強大后臺架構從0到1的演進歷程(一)
17年的實踐:騰訊海量產品的技術方法論
>> 更多同類文章 ……

[6] 有關IM安全的文章:
即時通訊安全篇(一):正確地理解和使用Android端加密算法
即時通訊安全篇(二):探討組合加密算法在IM中的應用
即時通訊安全篇(三):常用加解密算法與通訊安全講解
即時通訊安全篇(四):實例分析Android中密鑰硬編碼的風險
傳輸層安全協議SSL/TLS的Java平臺實現簡介和Demo演示
理論聯系實際:一套典型的IM通信協議設計詳解(含安全層設計)
微信新一代通信安全解決方案:基于TLS1.3的MMTLS詳解
來自阿里OpenIM:打造安全可靠即時通訊服務的技術實踐分享
>> 更多同類文章 ……

[7] 有關實時音視頻開發:
即時通訊音視頻開發(一):視頻編解碼之理論概述
即時通訊音視頻開發(二):視頻編解碼之數字視頻介紹
即時通訊音視頻開發(三):視頻編解碼之編碼基礎
即時通訊音視頻開發(四):視頻編解碼之預測技術介紹
即時通訊音視頻開發(五):認識主流視頻編碼技術H.264
即時通訊音視頻開發(六):如何開始音頻編解碼技術的學習
即時通訊音視頻開發(七):音頻基礎及編碼原理入門
即時通訊音視頻開發(八):常見的實時語音通訊編碼標準
即時通訊音視頻開發(九):實時語音通訊的回音及回音消除概述
即時通訊音視頻開發(十):實時語音通訊的回音消除技術詳解
即時通訊音視頻開發(十一):實時語音通訊丟包補償技術詳解
即時通訊音視頻開發(十二):多人實時音視頻聊天架構探討
即時通訊音視頻開發(十三):實時視頻編碼H.264的特點與優勢
即時通訊音視頻開發(十四):實時音視頻數據傳輸協議介紹
即時通訊音視頻開發(十五):聊聊P2P與實時音視頻的應用情況
即時通訊音視頻開發(十六):移動端實時音視頻開發的幾個建議
即時通訊音視頻開發(十七):視頻編碼H.264、V8的前世今生
簡述開源實時音視頻技術WebRTC的優缺點
良心分享:WebRTC 零基礎開發者教程(中文)
>> 更多同類文章 ……

[8] IM開發綜合文章:
移動端IM開發需要面對的技術問題
開發IM是自己設計協議用字節流好還是字符流好?
請問有人知道語音留言聊天的主流實現方式嗎?
IM系統中如何保證消息的可靠投遞(即QoS機制)
談談移動端 IM 開發中登錄請求的優化
完全自已開發的IM該如何設計“失敗重試”機制?
微信對網絡影響的技術試驗及分析(論文全文)
即時通訊系統的原理、技術和應用(技術論文)
開源IM工程“蘑菇街TeamTalk”的現狀:一場有始無終的開源秀
>> 更多同類文章 ……

[9] 開源移動端IM技術框架資料:
開源移動端IM技術框架MobileIMSDK:快速入門
開源移動端IM技術框架MobileIMSDK:常見問題解答
開源移動端IM技術框架MobileIMSDK:壓力測試報告
開源移動端IM技術框架MobileIMSDK:Android版Demo使用幫助
開源移動端IM技術框架MobileIMSDK:Java版Demo使用幫助
開源移動端IM技術框架MobileIMSDK:iOS版Demo使用幫助
開源移動端IM技術框架MobileIMSDK:Android客戶端開發指南
開源移動端IM技術框架MobileIMSDK:Java客戶端開發指南
開源移動端IM技術框架MobileIMSDK:iOS客戶端開發指南
開源移動端IM技術框架MobileIMSDK:Server端開發指南
>> 更多同類文章 ……

[10] 有關推送技術的文章:
iOS的推送服務APNs詳解:設計思路、技術原理及缺陷等
Android端消息推送總結:實現原理、心跳保活、遇到的問題等
掃盲貼:認識MQTT通信協議
一個基于MQTT通信協議的完整Android推送Demo
求教android消息推送:GCM、XMPP、MQTT三種方案的優劣
移動端實時消息推送技術淺析
掃盲貼:淺談iOS和Android后臺實時消息推送的原理和區別
絕對干貨:基于Netty實現海量接入的推送服務技術要點
移動端IM實踐:谷歌消息推送服務(GCM)研究(來自微信)
為何微信、QQ這樣的IM工具不使用GCM服務推送消息?
>> 更多同類文章 ……

[11] 更多即時通訊技術好文分類:
http://www.uktmgv.tw/forum.php?mod=collection&op=all

即時通訊網 - 即時通訊開發者社區! 來源: - 即時通訊開發者社區!

上一篇:什么是MAC地址的老化時間下一篇:有關 MINA 2.0 性能優化的兩個簡單方法

本帖已收錄至以下技術專輯

推薦方案
評論 23
簡單易懂。
分析得很清晰
謝謝樓主分享~~
nat端口老化超時進行了回收,可進行連接保活
引用:zjjishitongxun 發表于 2017-08-02 13:44
nat端口老化超時進行了回收,可進行連接保活

正解
簽名: 養孩子真累。。
能否轉載啊!
引用:Andy_PVJHo 發表于 2017-11-03 15:20
能否轉載啊!

可以。
簽名: 養孩子真累。。
作者加油
簽名: 新人出來乍到、求罩
雖然還沒有成功,但是受益匪淺。無意進入該論壇,感覺收獲很大。
引用:Tcp 發表于 2018-01-23 15:35
雖然還沒有成功,但是受益匪淺。無意進入該論壇,感覺收獲很大。

簽名: 養孩子真累。。
TCP穿透有什么好的辦法
引用:yc1234 發表于 2018-03-31 12:14
TCP穿透有什么好的辦法

你要搞TCP的P2P?
簽名: 養孩子真累。。
引用:JackJiang 發表于 2018-03-31 12:23
你要搞TCP的P2P?

在研究TCP穿透,跟UDP穿透方式差不多一樣,那為什么好多都不用TCP穿透。TCP使用的場景還是較多
很不錯。剛開始接觸webrtc。很需要這樣的資料。
簽名: 跨運營商崩潰了
這篇文章里面提到的幾種NAT穿越技術跟下一篇文章里面提到的UDP打洞技術之間有什么關聯嗎?打洞是不是NAT穿越的一種?如果是的話那么對應這里的幾種方式的哪一種,跪求大佬解答
引用:閆仕偉_xIBI2 發表于 2018-10-31 17:48
這篇文章里面提到的幾種NAT穿越技術跟下一篇文章里面提到的UDP打洞技術之間有什么關聯嗎?打洞是不是NAT穿 ...

打洞真要自已寫的話,要搞死,你百度了解一下STUN、TURN這樣的技術:《P2P技術詳解(三):P2P技術之STUN、TURN、ICE詳解
簽名: 養孩子真累。。
支持
謝謝分享,很有幫助
引用:fffewww 發表于 2018-12-12 16:24
謝謝分享,很有幫助

簽名: 養孩子真累。。
打賞樓主 ×
使用微信打賞! 使用支付寶打賞!

返回頂部
曾氏料二肖中特