UDP用打洞技術(shù)穿透NAT的原理與實(shí)現(xiàn) 收藏

            首先先介紹一些基本概念：
            NAT(Network Address
            Translators)，網(wǎng)絡(luò)地址轉(zhuǎn)換：網(wǎng)絡(luò)地址轉(zhuǎn)換是在IP地址日益缺乏的情況下產(chǎn)生的，它的主要目的就是為了能夠地址重用。NAT分為兩大類，基本的NAT和NAPT(Network
            Address/Port Translator)。
            最開始NAT是運(yùn)行在路由器上的一個(gè)功能模塊。

            最先提出的是基本的NAT，它的產(chǎn)生基于如下事實(shí)：一個(gè)私有網(wǎng)絡(luò)（域）中的節(jié)點(diǎn)中只有很少的節(jié)點(diǎn)需要與外網(wǎng)連接（呵呵，這是在上世紀(jì)90年代中期提出 的）。那么這個(gè)子網(wǎng)中其實(shí)只有少數(shù)的節(jié)點(diǎn)需要全球唯一的IP地址，其他的節(jié)點(diǎn)的IP地址應(yīng)該是可以重用的。
            因此，基本的NAT實(shí)現(xiàn)的功能很簡(jiǎn)單，在子網(wǎng)內(nèi)使用一個(gè)保留的IP子網(wǎng)段，這些IP對(duì)外是不可見的。子網(wǎng)內(nèi)只有少數(shù)一些IP地址可以對(duì)應(yīng)到真正全球唯一的 IP地址。如果這些節(jié)點(diǎn)需要訪問外部網(wǎng)絡(luò)，那么基本NAT就負(fù)責(zé)將這個(gè)節(jié)點(diǎn)的子網(wǎng)內(nèi)IP轉(zhuǎn)化為一個(gè)全球唯一的IP然后發(fā)送出去。(基本的NAT會(huì)改變IP 包中的原IP地址，但是不會(huì)改變IP包中的端口)
            關(guān)于基本的NAT可以參看RFC 1631

            另外一種NAT叫做NAPT，從名稱上我們也可以看得出，NAPT不但會(huì)改變經(jīng)過這個(gè)NAT設(shè)備的IP數(shù)據(jù)報(bào)的IP地址，還會(huì)改變IP數(shù)據(jù)報(bào)的 TCP/UDP端口。基本NAT的設(shè)備可能我們見的不多（呵呵，我沒有見到過），NAPT才是我們真正討論的主角。看下圖：
            Server S1
            18.181.0.31:1235
            |
            ^ Session 1 (A-S1) ^ |
            | 18.181.0.31:1235 | |
            v 155.99.25.11:62000 v |
            |
            NAT
            155.99.25.11
            |
            ^ Session 1 (A-S1) ^ |
            | 18.181.0.31:1235 | |
            v 10.0.0.1:1234 v |
            |
            Client A
            10.0.0.1:1234
            有一個(gè)私有網(wǎng)絡(luò)10.*.*.*，Client
            A是其中的一臺(tái)計(jì)算機(jī)，這個(gè)網(wǎng)絡(luò)的網(wǎng)關(guān)（一個(gè)NAT設(shè)備）的外網(wǎng)IP是155.99.25.11(應(yīng)該還有一個(gè)內(nèi)網(wǎng)的IP地址，比如10.0.0.10)。如果Client
            A中的某個(gè)進(jìn)程（這個(gè)進(jìn)程創(chuàng)建了一個(gè)UDP
            Socket,這個(gè)Socket綁定1234端口）想訪問外網(wǎng)主機(jī)18.181.0.31的1235端口，那么當(dāng)數(shù)據(jù)包通過NAT時(shí)會(huì)發(fā)生什么事情呢？
            首先NAT會(huì)改變這個(gè)數(shù)據(jù)包的原IP地址，改為155.99.25.11。接著NAT會(huì)為這個(gè)傳輸創(chuàng)建一個(gè)Session（Session是一個(gè)抽象的概 念，如果是TCP，也許Session是由一個(gè)SYN包開始，以一個(gè)FIN包結(jié)束。而UDP呢，以這個(gè)IP的這個(gè)端口的第一個(gè)UDP開始，結(jié)束呢，呵呵， 也許是幾分鐘，也許是幾小時(shí)，這要看具體的實(shí)現(xiàn)了）并且給這個(gè)Session分配一個(gè)端口，比如62000，然后改變這個(gè)數(shù)據(jù)包的源端口為62000。所 以本來是（10.0.0.1:1234->18.181.0.31:1235）的數(shù)據(jù)包到了互聯(lián)網(wǎng)上變?yōu)榱? （155.99.25.11:62000->18.181.0.31:1235）。
            一旦NAT創(chuàng)建了一個(gè)Session后，NAT會(huì)記住62000端口對(duì)應(yīng)的是10.0.0.1的1234端口，以后從18.181.0.31發(fā)送到 62000端口的數(shù)據(jù)會(huì)被NAT自動(dòng)的轉(zhuǎn)發(fā)到10.0.0.1上。（注意：這里是說18.181.0.31發(fā)送到62000端口的數(shù)據(jù)會(huì)被轉(zhuǎn)發(fā)，其他的 IP發(fā)送到這個(gè)端口的數(shù)據(jù)將被NAT拋棄）這樣Client
            A就與Server S1建立以了一個(gè)連接。

            呵呵，上面的基礎(chǔ)知識(shí)可能很多人都知道了，那么下面是關(guān)鍵的部分了。
            看看下面的情況：
            Server S1 Server S2
            18.181.0.31:1235 138.76.29.7:1235
            | |
            | |
            +----------------------+----------------------+
            |
            ^ Session 1 (A-S1) ^ | ^ Session 2 (A-S2) ^
            | 18.181.0.31:1235 | | | 138.76.29.7:1235 |
            v 155.99.25.11:62000 v | v 155.99.25.11:62000 v
            |
            Cone NAT
            155.99.25.11
            |
            ^ Session 1 (A-S1) ^ | ^ Session 2 (A-S2) ^
            | 18.181.0.31:1235 | | | 138.76.29.7:1235 |
            v 10.0.0.1:1234 v | v 10.0.0.1:1234 v
            |
            Client A
            10.0.0.1:1234
            接上面的例子，如果Client A的原來那個(gè)Socket(綁定了1234端口的那個(gè)UDP Socket)又接著向另外一個(gè)Server
            S2發(fā)送了一個(gè)UDP包，那么這個(gè)UDP包在通過NAT時(shí)會(huì)怎么樣呢？
            這時(shí)可能會(huì)有兩種情況發(fā)生，一種是NAT再次創(chuàng)建一個(gè)Session，并且再次為這個(gè)Session分配一個(gè)端口號(hào)（比如：62001）。另外一種是 NAT再次創(chuàng)建一個(gè)Session，但是不會(huì)新分配一個(gè)端口號(hào)，而是用原來分配的端口號(hào)62000。前一種NAT叫做Symmetric
            NAT，后一種叫做Cone
            NAT。我們期望我們的NAT是第二種，呵呵，如果你的NAT剛好是第一種，那么很可能會(huì)有很多P2P軟件失靈。（可以慶幸的是，現(xiàn)在絕大多數(shù)的NAT屬于后者，即Cone
            NAT）

            好了，我們看到，通過NAT,子網(wǎng)內(nèi)的計(jì)算機(jī)向外連結(jié)是很容易的（NAT相當(dāng)于透明的，子網(wǎng)內(nèi)的和外網(wǎng)的計(jì)算機(jī)不用知道NAT的情況）。
            但是如果外部的計(jì)算機(jī)想訪問子網(wǎng)內(nèi)的計(jì)算機(jī)就比較困難了（而這正是P2P所需要的）。
            那么我們?nèi)绻霃耐獠堪l(fā)送一個(gè)數(shù)據(jù)報(bào)給內(nèi)網(wǎng)的計(jì)算機(jī)有什么辦法呢？首先，我們必須在內(nèi)網(wǎng)的NAT上打上一個(gè)“洞”（也就是前面我們說的在NAT上建立一個(gè) Session），這個(gè)洞不能由外部來打，只能由內(nèi)網(wǎng)內(nèi)的主機(jī)來打。而且這個(gè)洞是有方向的，比如從內(nèi)部某臺(tái)主機(jī)（比如：192.168.0.10）向外部 的某個(gè)IP(比如：219.237.60.1)發(fā)送一個(gè)UDP包，那么就在這個(gè)內(nèi)網(wǎng)的NAT設(shè)備上打了一個(gè)方向?yàn)?19.237.60.1的“洞”，（這 就是稱為UDP
            Hole
            Punching的技術(shù)）以后219.237.60.1就可以通過這個(gè)洞與內(nèi)網(wǎng)的192.168.0.10聯(lián)系了。（但是其他的IP不能利用這個(gè)洞）。

            呵呵，現(xiàn)在該輪到我們的正題P2P了。有了上面的理論，實(shí)現(xiàn)兩個(gè)內(nèi)網(wǎng)的主機(jī)通訊就差最后一步了：那就是雞生蛋還是蛋生雞的問題了，兩邊都無法主動(dòng)發(fā)出連接 請(qǐng)求，誰也不知道誰的公網(wǎng)地址，那我們?nèi)绾蝸泶蜻@個(gè)洞呢？我們需要一個(gè)中間人來聯(lián)系這兩個(gè)內(nèi)網(wǎng)主機(jī)。
            現(xiàn)在我們來看看一個(gè)P2P軟件的流程，以下圖為例：

            Server S （219.237.60.1）
            |
            |
            +----------------------+----------------------+
            | |
            NAT A (外網(wǎng)IP:202.187.45.3) NAT B (外網(wǎng)IP:187.34.1.56)
            | (內(nèi)網(wǎng)IP:192.168.0.1) | (內(nèi)網(wǎng)IP:192.168.0.1)
            | |
            Client A (192.168.0.20:4000) Client B (192.168.0.10:40000)

            首先，Client A登錄服務(wù)器，NAT A為這次的Session分配了一個(gè)端口60000，那么Server S收到的Client
            A的地址是202.187.45.3:60000，這就是Client A的外網(wǎng)地址了。同樣，Client B登錄Server S，NAT
            B給此次Session分配的端口是40000，那么Server S收到的B的地址是187.34.1.56:40000。
            此時(shí)，Client A與Client B都可以與Server S通信了。如果Client A此時(shí)想直接發(fā)送信息給Client
            B，那么他可以從Server S那兒獲得B的公網(wǎng)地址187.34.1.56:40000，是不是Client
            A向這個(gè)地址發(fā)送信息Client B就能收到了呢？答案是不行，因?yàn)槿绻@樣發(fā)送信息，NAT
            B會(huì)將這個(gè)信息丟棄（因?yàn)檫@樣的信息是不請(qǐng)自來的，為了安全，大多數(shù)NAT都會(huì)執(zhí)行丟棄動(dòng)作）。現(xiàn)在我們需要的是在NAT
            B上打一個(gè)方向?yàn)?02.187.45.3（即Client A的外網(wǎng)地址）的洞，那么Client
            A發(fā)送到187.34.1.56:40000的信息,Client B就能收到了。這個(gè)打洞命令由誰來發(fā)呢，呵呵，當(dāng)然是Server S。
            總結(jié)一下這個(gè)過程：如果Client A想向Client B發(fā)送信息，那么Client A發(fā)送命令給Server S，請(qǐng)求Server
            S命令Client B向Client
            A方向打洞。呵呵，是不是很繞口，不過沒關(guān)系，想一想就很清楚了，何況還有源代碼呢（侯老師說過：在源代碼面前沒有秘密
            8）），然后Client A就可以通過Client B的外網(wǎng)地址與Client B通信了。

            注意：以上過程只適合于Cone NAT的情況，如果是Symmetric NAT，那么當(dāng)Client B向Client
            A打洞的端口已經(jīng)重新分配了，Client B將無法知道這個(gè)端口（如果Symmetric
            NAT的端口是順序分配的，那么我們或許可以猜測(cè)這個(gè)端口號(hào)，可是由于可能導(dǎo)致失敗的因素太多，我們不推薦這種猜測(cè)端口的方法）。

             另一篇文章接上：

            下面解釋一下上面的文章中沒有提及或者說我覺得比較欠缺的地方.
             私有地址/端口和公有地址/端口:我們知道,現(xiàn)在大部分網(wǎng)絡(luò)采用的都是NAPT(Network Address/Port Translator)了, 這個(gè)東東的作用是一個(gè)對(duì)外的對(duì)話在經(jīng)過NAT之后IP地址和端口號(hào)都會(huì)被改寫,在這里把一次會(huì)話中客戶自己認(rèn)為在使用的IP地址和端口號(hào)成為私有地址/端 口,而把經(jīng)過NAPT之后被改寫的IP地址和端口號(hào)稱為公有地址/端口.或者可以這么理解,私有地址/端口是你家里人對(duì)你的昵稱而公有地址/端口則是你真 正對(duì)外公開的名字.如何獲得用戶的私用地址/端口號(hào),這個(gè)很簡(jiǎn)單了,而要得到公有地址/端口號(hào)就要在連接上另一臺(tái)機(jī)器之后由那臺(tái)機(jī)器看到的IP地址和端口 號(hào)來表示.

             如果明白了上面的東西,下面進(jìn)入我們的代碼,在這里解釋一下關(guān)鍵部分的實(shí)現(xiàn):

             客戶端首先得到自己的私有地址/終端,然后向server端發(fā)送登陸請(qǐng)求,server端在得到這個(gè)請(qǐng)求之后就可以知道這個(gè)client端的公有地址/終 端,server會(huì)為每一個(gè)登陸的client保存它們的私有地址/端口和公有地址/端口.

              OK,下面開始關(guān)鍵的打洞流程.假設(shè)client A要向client B對(duì)話,但是A不知道B的地址,即使知道根據(jù)NAT的原理這個(gè)對(duì)話在第一次會(huì)被拒 絕,因?yàn)閏lient B的NAT認(rèn)為這是一個(gè)從沒有過的外部發(fā)來的請(qǐng)求.這個(gè)時(shí)候,A如果發(fā)現(xiàn)自己沒有保存B的地址,或者說發(fā)送給B的會(huì)話請(qǐng)求失敗了, 它會(huì)要求server端讓B向A打一個(gè)洞,這個(gè)B->A的會(huì)話意義在于它使NAT B認(rèn)為A的地址/端口是可以通過的地址/端口,這樣A再向B發(fā)送 對(duì)話的時(shí)候就不會(huì)再被NAT B拒絕了.打一個(gè)比方來說明打洞的過程,A想來B家做客,但是遭到了B的管家NAT B的拒絕,理由是:我從來沒有聽我家B 提過你的名字,這時(shí)A找到了A,B都認(rèn)識(shí)的朋友server,要求server給B報(bào)一個(gè)信,讓B去跟管家說A是我的朋友,于是,B跟管家NAT B 說,A是我認(rèn)識(shí)的朋友,這樣A的訪問請(qǐng)求就不會(huì)再被管家NAT B所拒絕了.簡(jiǎn)而言之,UDP打洞就是一個(gè)通過server保存下來的地址使得彼此之間能 夠直接通信的過程,server只管幫助建立連接,在建立間接之后就不再介入了.

            下面是一個(gè)模擬P2P聊天的過程的源代碼，過程很簡(jiǎn)單，P2PServer運(yùn)行在一個(gè)擁有公網(wǎng)IP的計(jì)算機(jī)上，P2PClient運(yùn)行在兩個(gè)不同的NAT 后（注意，如果兩個(gè)客戶端運(yùn)行在一個(gè)NAT后，本程序很可能不能運(yùn)行正常，這取決于你的NAT是否支持loopback
            translation，詳見http://midcom-p2p.sourceforge.net/draft-ford-midcom-p2p-01.txt，當(dāng)然，此問題可以通過雙方先嘗試連接對(duì)方的內(nèi)網(wǎng)IP來解決，但是這個(gè)代碼只是為了驗(yàn)證原理，并沒有處理這些問題），后登錄的計(jì)算機(jī)可以獲得先登錄計(jì)算機(jī)的用戶名，后登錄的計(jì)算機(jī)通過send
            username message的格式來發(fā)送消息。如果發(fā)送成功，說明你已取得了直接與對(duì)方連接的成功。
            程序現(xiàn)在支持三個(gè)命令：send , getu , exit

            send格式：send username message
            功能：發(fā)送信息給username

            getu格式：getu
            功能：獲得當(dāng)前服務(wù)器用戶列表

            exit格式：exit
            功能：注銷與服務(wù)器的連接（服務(wù)器不會(huì)自動(dòng)監(jiān)測(cè)客戶是否吊線）

            代碼很短，相信很容易懂，如果有什么問題，可以給我發(fā)郵件zhouhuis22@sina.com
            或者在CSDN上發(fā)送短消息。同時(shí)，歡迎轉(zhuǎn)發(fā)此文，但希望保留作者版權(quán)8-）。
            _05/04052509317298.rar"
            http://www.ppcn.net/upload/2004_05/04052509317298.rar 　

另一篇介紹打洞技術(shù)的（補(bǔ)充）

UDP打洞技術(shù)依賴于由公共防火墻和cone NAT，允許適當(dāng)?shù)挠杏?jì)劃的端對(duì)端應(yīng)用程序通過NAT"打洞"，即使當(dāng)雙方的主機(jī)都處于NAT之后。這種技術(shù)在 RFC3027的5.1節(jié)[NAT PROT] 中進(jìn)行了重點(diǎn)介紹，并且在Internet[KEGEL]中進(jìn)行了非正式的描敘，還應(yīng)用到了最新的一些協(xié)議，例如[TEREDO,ICE]協(xié)議中。不過， 我們要注意的是，"術(shù)"如其名，UDP打洞技術(shù)的可靠性全都要依賴于UDP。
這里將考慮兩種典型場(chǎng)景，來介紹連接的雙方應(yīng)用程序如何按照計(jì)劃的進(jìn)行通信的，第一種場(chǎng)景，我們假設(shè)兩個(gè)客戶端都處于不同的NAT之后；第二種場(chǎng)景，我們假設(shè)兩個(gè)客戶端都處于同一個(gè)NAT之后，但是它們彼此都不知道(他們?cè)谕粋€(gè)NAT中)。


 
處于不同NAT之后的客戶端通信

    我們假設(shè) Client A 和 Client B 都擁有自己的私有IP地址，并且都處在不同的NAT之后，端對(duì)端的程序運(yùn)行于 CLIENT A,CLIENT B,S之間，并且它們都開放了UDP端口1234。 CLIENT A和CLIENT B首先分別與S建立通信會(huì)話，這時(shí)NAT A把它自己的UDP端口62000分配給CLIENT A與S的會(huì)話，NAT B也把自己的UDP端口31000分配給CLIENT B與S的會(huì)話。

假 如這個(gè)時(shí)候 CLIENT A 想與 CLIENT B建立一條UDP通信直連，如果 CLIENT A只是簡(jiǎn)單的發(fā)送一個(gè)UDP信息到CLIENT B的公網(wǎng)地址138.76.29.7:31000的話，NAT B會(huì)不加考慮的將這個(gè)信息丟棄（除非NAT B是一個(gè) full cone NAT），因?yàn)?這個(gè)UDP信息中所包含的地址信息，與CLIENT B和服務(wù)器S建立連接時(shí)存儲(chǔ)在NAT B中的服務(wù)器S的地址信息不符。同樣的，CLIENT B如果做同樣的事情，發(fā)送的UDP信息也會(huì)被 NAT A 丟棄。

 假如 CLIENT A 開始發(fā)送一個(gè) UDP 信息到 CLIENT B 的公網(wǎng)地址上，與此同時(shí)，他又通過S中轉(zhuǎn)發(fā)送了一個(gè)邀請(qǐng)信息給CLIENT B，請(qǐng)求CLIENT B也給CLIENT A發(fā)送一個(gè)UDP信息到 CLIENT A的公網(wǎng)地址上。這時(shí)CLIENT A向CLIENT B的公網(wǎng)IP(138.76.29.7:31000)發(fā)送的信息導(dǎo)致 NAT A 打開一個(gè)處于 CLIENT A的私有地址和CLIENT B的公網(wǎng)地址之間的新的通信會(huì)話，與此同時(shí)，NAT B 也打開了一個(gè)處于CLIENT B的私有地址和CLIENT A的公網(wǎng)地址(155.99.25.11:62000)之間的新的通信會(huì)話。一旦這個(gè)新的UDP會(huì)話各自向?qū)Ψ酱蜷_了，CLIENT A和CLIENT B之間就可以直接通信，而無需S來牽線搭橋了。(這就是所謂的打洞技術(shù))！