目錄

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

1.1全錐形NAT

1.2限制錐形NAT

1.3端口限制錐形NAT

1.4對(duì)稱型NAT

2 NAT穿越技術(shù)

2.1應(yīng)用層網(wǎng)關(guān)

2.2探針技術(shù)STUN和TURN

2.3中間件技術(shù)

2.4中繼代理技術(shù)

2.5特定協(xié)議的自穿越技術(shù)

參考文章

---

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

在一對(duì)多模型中，按照端口轉(zhuǎn)換的工作方式不同，又可以進(jìn)行更進(jìn)一步的劃分。為描述方便，以下將IP和端口標(biāo)記為(nAddr:nPort)，其中n代表主機(jī)或NAT網(wǎng)關(guān)的不同角色。
?

▲ 圖3 按照端口轉(zhuǎn)換映射方式分類
?

1.1全錐形NAT

其特點(diǎn)為：一旦內(nèi)部主機(jī)端口對(duì)(iAddr:iPort)被NAT網(wǎng)關(guān)映射到(eAddr:ePort)，所有后續(xù)的(iAddr:iPort)報(bào)文都會(huì)被轉(zhuǎn)換為(eAddr:ePort)；任何一個(gè)外部主機(jī)發(fā)送到(eAddr:ePort)的報(bào)文將會(huì)被轉(zhuǎn)換后發(fā)到(iAddr:iPort)。
?

1.2限制錐形NAT

其特點(diǎn)為：一旦內(nèi)部主機(jī)端口對(duì)(iAddr:iPort)被映射到(eAddr:ePort)，所有后續(xù)的(iAddr:iPort)報(bào)文都會(huì)被轉(zhuǎn)換為(eAddr:ePort)；只有 (iAddr:iPort)向特定的外部主機(jī)hAddr發(fā)送過數(shù)據(jù)，主機(jī)hAddr從任意端口發(fā)送到(eAddr:ePort)的報(bào)文將會(huì)被轉(zhuǎn)發(fā)到(iAddr:iPort)。
?

1.3端口限制錐形NAT

其特點(diǎn)為：一旦內(nèi)部主機(jī)端口對(duì)(iAddr:iPort)被映射到(eAddr:ePort)，所有后續(xù)的(iAddr:iPort)報(bào)文都會(huì)被轉(zhuǎn)換為(eAddr:ePort)；只有(iAddr:iPort)向特定的外部主機(jī)端口對(duì)(hAddr:hPort)發(fā)送過數(shù)據(jù)，由 (hAddr:hPort)發(fā)送到(eAddr:ePort)的報(bào)文將會(huì)被轉(zhuǎn)發(fā)到(iAddr:iPort)。
?

1.4對(duì)稱型NAT

其特點(diǎn)為：NAT網(wǎng)關(guān)會(huì)把內(nèi)部主機(jī)“地址端口對(duì)”和外部主機(jī)“地址端口對(duì)”完全相同的報(bào)文看作一個(gè)連接，在網(wǎng)關(guān)上創(chuàng)建一個(gè)公網(wǎng)“地址端口對(duì)”映射進(jìn)行轉(zhuǎn)換，只有收到報(bào)文的外部主機(jī)從對(duì)應(yīng)的端口對(duì)發(fā)送回應(yīng)的報(bào)文，才能被轉(zhuǎn)換。即使內(nèi)部主機(jī)使用之前用過的地址端口對(duì)去連接不同外部主機(jī)(或端口)時(shí)，NAT網(wǎng)關(guān)也會(huì)建立新的映射關(guān)系。

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

2 NAT穿越技術(shù)

前面解釋了NAT的弊端，為了解決IP端到端應(yīng)用在NAT環(huán)境下遇到的問題，網(wǎng)絡(luò)協(xié)議的設(shè)計(jì)者們創(chuàng)造了各種武器來(lái)進(jìn)行應(yīng)對(duì)。但遺憾的是，這里每一種方法都不完美，還需要在內(nèi)部主機(jī)、應(yīng)用程序或者NAT網(wǎng)關(guān)上增加額外的處理。
?

2.1應(yīng)用層網(wǎng)關(guān)

應(yīng)用層網(wǎng)關(guān)(ALG)是解決NAT對(duì)應(yīng)用層協(xié)議無(wú)感知的一個(gè)最常用方法，已經(jīng)被NAT設(shè)備廠商廣泛采用，成為NAT設(shè)備的一個(gè)必需功能。因?yàn)镹AT不感知應(yīng)用協(xié)議，所以有必要額外為每個(gè)應(yīng)用協(xié)議定制協(xié)議分析功能，這樣NAT網(wǎng)關(guān)就能理解并支持特定的協(xié)議。

ALG與NAT形成互動(dòng)關(guān)系，在一個(gè)NAT網(wǎng)關(guān)檢測(cè)到新的連接請(qǐng)求時(shí)，需要判斷是否為已知的應(yīng)用類型，這通常是基于連接的傳輸層端口信息來(lái)識(shí)別的。

在識(shí)別為已知應(yīng)用時(shí)，再調(diào)用相應(yīng)功能對(duì)報(bào)文的深層內(nèi)容進(jìn)行檢查，當(dāng)發(fā)現(xiàn)任何形式表達(dá)的IP地址和端口時(shí)，將會(huì)把這些信息同步轉(zhuǎn)換，并且為這個(gè)新連接創(chuàng)建一個(gè)附加的轉(zhuǎn)換表項(xiàng)。這樣，當(dāng)報(bào)文到達(dá)公網(wǎng)側(cè)的目的主機(jī)時(shí)，應(yīng)用層協(xié)議中攜帶的信息就是NAT網(wǎng)關(guān)提供的地址和端口。一旦公網(wǎng)側(cè)主機(jī)開始發(fā)送數(shù)據(jù)或建立連接到此端口，NAT網(wǎng)關(guān)就可以根據(jù)關(guān)聯(lián)表信息進(jìn)行轉(zhuǎn)換，再把數(shù)據(jù)轉(zhuǎn)發(fā)到私網(wǎng)側(cè)的主機(jī)。

很多應(yīng)用層協(xié)議實(shí)現(xiàn)不限于一個(gè)初始連接(通常為信令或控制通道)加一個(gè)數(shù)據(jù)連接，可能是一個(gè)初始連接對(duì)應(yīng)很多后續(xù)的新連接。比較特別的協(xié)議，在一次協(xié)商中會(huì)產(chǎn)生一組相關(guān)連接，比如RTP/RTCP協(xié)議規(guī)定，一個(gè)RTP通道建立后占用連續(xù)的兩個(gè)端口，一個(gè)服務(wù)于數(shù)據(jù)，另一個(gè)服務(wù)于控制消息。此時(shí)，就需要ALG分配連續(xù)的端口為應(yīng)用服務(wù)。

ALG能成功解決大部分協(xié)議的NAT穿越需求，但是這個(gè)方法也有很大的限制。因?yàn)閼?yīng)用協(xié)議的數(shù)量非常多而且在不斷發(fā)展變化之中，添加到設(shè)備中的ALG功能都是為特定協(xié)議的特定規(guī)范版本而開發(fā)的，協(xié)議的創(chuàng)新和演進(jìn)要求NAT設(shè)備制造商必須跟蹤這些協(xié)議的最近標(biāo)準(zhǔn)，同時(shí)兼容舊標(biāo)準(zhǔn)。

盡管有如Linux這種開放平臺(tái)允許動(dòng)態(tài)加載新的ALG特性，但是管理成本仍然很高，網(wǎng)絡(luò)維護(hù)人員也不能隨時(shí)了解用戶都需要什么應(yīng)用。因此為每個(gè)應(yīng)用協(xié)議開發(fā)ALG代碼并跟蹤最新標(biāo)準(zhǔn)是不可行的，ALG只能解決用戶最常用的需求。

此外，出于安全性需要，有些應(yīng)用類型報(bào)文從源端發(fā)出就已經(jīng)加密，這種報(bào)文在網(wǎng)絡(luò)中間無(wú)法進(jìn)行分析，所以ALG無(wú)能為力。
?

2.2探針技術(shù)STUN和TURN

所謂探針技術(shù)，是通過在所有參與通信的實(shí)體上安裝探測(cè)插件，以檢測(cè)網(wǎng)絡(luò)中是否存在NAT網(wǎng)關(guān)，并對(duì)不同NAT模型實(shí)施不同穿越方法的一種技術(shù)。

STUN服務(wù)器被部署在公網(wǎng)上，用于接收來(lái)自通信實(shí)體的探測(cè)請(qǐng)求，服務(wù)器會(huì)記錄收到請(qǐng)求的報(bào)文地址和端口，并填寫到回送的響應(yīng)報(bào)文中。客戶端根據(jù)接收到的響應(yīng)消息中記錄的地址和端口與本地選擇的地址和端口進(jìn)行比較，就能識(shí)別出是否存在NAT網(wǎng)關(guān)。如果存在NAT網(wǎng)關(guān)，客戶端會(huì)使用之前的地址和端口向服務(wù)器的另外一個(gè)IP發(fā)起請(qǐng)求，重復(fù)前面的探測(cè)。然后再比較兩次響應(yīng)返回的結(jié)果判斷出NAT工作的模式。

由前述的一對(duì)多轉(zhuǎn)換模型得知，除對(duì)稱型NAT以外的模型，NAT網(wǎng)關(guān)對(duì)內(nèi)部主機(jī)地址端口的映射都是相對(duì)固定的，所以比較容易實(shí)現(xiàn)NAT穿越。

而對(duì)稱型NAT為每個(gè)連接提供一個(gè)映射，使得轉(zhuǎn)換后的公網(wǎng)地址和端口對(duì)不可預(yù)測(cè)。此時(shí)TURN可以與STUN綁定提供穿越NAT的服務(wù)，即在公網(wǎng)服務(wù)器上提供一個(gè)“地址端口對(duì)”，所有此“地址端口對(duì)”接收到的數(shù)據(jù)會(huì)經(jīng)由探測(cè)建立的連接轉(zhuǎn)發(fā)到內(nèi)網(wǎng)主機(jī)上。TURN分配的這個(gè)映射“地址端口對(duì)”會(huì)通過STUN響應(yīng)發(fā)給內(nèi)部主機(jī)，后者將此信息放入建立連接的信令中通知通信的對(duì)端。

這種探針技術(shù)是一種通用方法，不用在NAT設(shè)備上為每種應(yīng)用協(xié)議開發(fā)功能，相對(duì)于ALG方式有一定普遍性。但是TURN中繼服務(wù)會(huì)成為通信瓶頸。而且在客戶端中增加探針功能要求每個(gè)應(yīng)用都要增加代碼才能支持。
?

2.3中間件技術(shù)

這也是一種通過開發(fā)通用方法解決NAT穿越問題的努力。

與前者不同之處是，NAT網(wǎng)關(guān)是這一解決方案的參與者。

與ALG的不同在于，客戶端會(huì)參與網(wǎng)關(guān)公網(wǎng)映射信息的維護(hù)，此時(shí)NAT網(wǎng)關(guān)只要理解客戶端的請(qǐng)求并按照要求去分配轉(zhuǎn)換表，不需要自己去分析客戶端的應(yīng)用層數(shù)據(jù)。其中UPnP就是這樣一種方法。

UPnP中文全稱為通用即插即用，是一個(gè)通用的網(wǎng)絡(luò)終端與網(wǎng)關(guān)的通信協(xié)議，具備信息發(fā)布和管理控制的能力。

其中，網(wǎng)關(guān)映射請(qǐng)求可以為客戶動(dòng)態(tài)添加映射表項(xiàng)。此時(shí)，NAT不再需要理解應(yīng)用層攜帶的信息，只轉(zhuǎn)換IP地址和端口信息。而客戶端通過控制消息或信令發(fā)到公網(wǎng)側(cè)的信息中，直接攜帶公網(wǎng)映射的IP地址和端口，接收端可以按照此信息建立數(shù)據(jù)連接。NAT網(wǎng)關(guān)在收到數(shù)據(jù)或連接請(qǐng)求時(shí)，按照UPnP建立的表項(xiàng)只轉(zhuǎn)換地址和端口信息，不關(guān)心內(nèi)容，再將數(shù)據(jù)轉(zhuǎn)發(fā)到內(nèi)網(wǎng)。這種方案需要網(wǎng)關(guān)、內(nèi)部主機(jī)和應(yīng)用程序都支持UPnP技術(shù)，且組網(wǎng)允許內(nèi)部主機(jī)和NAT網(wǎng)關(guān)之間可以直接交換UPnP信令才能實(shí)施。
?

2.4中繼代理技術(shù)

準(zhǔn)確說(shuō)它不是NAT穿越技術(shù)，而是NAT旁路技術(shù)。簡(jiǎn)單說(shuō)，就是在NAT網(wǎng)關(guān)所在的位置旁邊放置一個(gè)應(yīng)用服務(wù)器，這個(gè)服務(wù)器在內(nèi)部網(wǎng)絡(luò)和外部公網(wǎng)分別有自己的網(wǎng)絡(luò)連接。客戶端特定的應(yīng)用產(chǎn)生網(wǎng)絡(luò)請(qǐng)求時(shí)，將定向發(fā)送到應(yīng)用代理服務(wù)器。應(yīng)用代理服務(wù)器根據(jù)代理協(xié)議解析客戶端的請(qǐng)求，再?gòu)姆?wù)器的公網(wǎng)側(cè)發(fā)起一個(gè)新的請(qǐng)求，把客戶端請(qǐng)求的內(nèi)容中繼到外部網(wǎng)絡(luò)上，返回的相應(yīng)反方向中繼。這項(xiàng)技術(shù)和ALG有很大的相似性，它要求為每個(gè)應(yīng)用類型部署中繼代理業(yè)務(wù)，中間服務(wù)器要理解這些請(qǐng)求。
?

2.5特定協(xié)議的自穿越技術(shù)

在所有方法中最復(fù)雜也最可靠的就是自己解決自己的問題。比如IKE和IPsec技術(shù)，在設(shè)計(jì)時(shí)就考慮了到如何穿越NAT的問題。因?yàn)檫@個(gè)協(xié)議是一個(gè)自加密的協(xié)議并且具有報(bào)文防修改的鑒別能力，其他通用方法愛莫能助。因?yàn)閷?shí)際應(yīng)用的NAT網(wǎng)關(guān)基本都是NAPT方式，所有通過傳輸層協(xié)議承載的報(bào)文可以順利通過NAT。IKE和IPsec采用的方案就是用UDP在報(bào)文外面再加一層封裝，而內(nèi)部的報(bào)文就不再受到影響。IKE中還專門增加了NAT網(wǎng)關(guān)是否存在的檢查能力以及繞開NAT網(wǎng)關(guān)檢測(cè)IKE協(xié)議的方法。

candidate?字段類型與解釋

?在學(xué)習(xí) webrtc 的過程中，我們?cè)趯W(xué)習(xí) ?SDP 的過程中，發(fā)現(xiàn)有個(gè)字段 candidate，網(wǎng)上很多資料都一筆帶過，或者解釋含糊，或者解釋錯(cuò)誤。主要是 udp 下的 host, srflx, prflx, relay 四種 candidate 類型的解釋不清，會(huì)導(dǎo)致很多疑惑。下面我就分享一下我的研究結(jié)果。最為權(quán)威的解釋參見官方 RFC ，這個(gè)里面解釋的最有權(quán)威。
?

Host Candidate: A candidate obtained by binding to a specific portfrom an IP address on the host. This includes IP addresses onphysical interfaces and logical ones, such as ones obtainedthrough Virtual Private Networks (VPNs) and Realm Specific IP(RSIP) [RFC3102] (which lives at the operating system level).這個(gè)地址來(lái)源于本地的物理網(wǎng)卡或邏輯網(wǎng)卡上的地址，對(duì)于具有公網(wǎng)地址或者同一內(nèi)網(wǎng)的端可以用Server Reflexive Candidate: A candidate whose IP address and portare a binding allocated by a NAT for an agent when it sent apacket through the NAT to a server. Server reflexive candidatescan be learned by STUN servers using the Binding request, or TURNservers, which provides both a relayed and server reflexivecandidate.這個(gè)地址是端發(fā)送 Binding 請(qǐng)求到 STUN/TURN server 經(jīng)過 NAT 時(shí)，NAT 上分配的地址和端口Peer Reflexive Candidate: A candidate whose IP address and port area binding allocated by a NAT for an agent when it sent a STUNBinding request through the NAT to its peer.這個(gè)地址是端發(fā)送 Binding 請(qǐng)求到對(duì)等端經(jīng)過 NAT 時(shí)，NAT 上分配的地址和端口 PeerA PeerB( Full Cone <---> [Restricted Cone, Port Restricted Cone, Symmetric] )如果對(duì)方是 Full Cone 類型，對(duì)方就可以提供 prflx 類型的 candidate 了，個(gè)人理解，僅供參考。Relayed Candidate: A candidate obtained by sending a TURN Allocaterequest from a host candidate to a TURN server. The relayedcandidate is resident on the TURN server, and the TURN serverrelays packets back towards the agent.這個(gè)地址是端發(fā)送 Allocate 請(qǐng)求到 TURN server ，由 TURN server 用于中繼的地址和端口（這個(gè)可能是本機(jī)或 NAT 地址）

參考文章

P2P技術(shù)詳解(一)：NAT詳解——詳細(xì)原理、P2P簡(jiǎn)介-網(wǎng)絡(luò)編程/專項(xiàng)技術(shù)區(qū) - 即時(shí)通訊開發(fā)者社區(qū)!?有關(guān) SDP 中 UDP candidate 類型說(shuō)明 ( host, srflx, prflx, relay )_freeabc的博客-CSDN博客_srflx

總結(jié)

以上是生活随笔為你收集整理的NAT技术研究的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。