Ads 468x60px

##EasyReadMore##

11 10月, 2016

P2P 之 UDP穿透NAT的原理

原創:P2P 之 UDP穿透NAT的原理與實現(附源代碼) @ blog :: 隨意窩 Xuite日誌 - https://goo.gl/S2x5Oy

論壇上經常有對P2P原理的討論,但是討論歸討論,很少有實質的東西產生(源代碼)。呵呵,在這裏我就用自己實現的一個源代碼來說明UDP穿越NAT的原理。

首先先介紹一些基本概念:
    NAT(Network Address Translators),網路位址轉換:網路位址轉換是在IP位址日益缺乏的情況下產生的,它的主要目的就是為了能夠位址重用。NAT分為兩大類,基本的NAT和NAPT(Network Address/Port Translator)。
最開始NAT是運行在路由器上的一個功能模組。
最先提出的是基本的NAT,它的產生基於如下事實:一個私有網路(域)中的節點中只有很少的節點需要與外網連接(呵呵,這是在上世紀90年代中期提出的)。那麼這個子網中其實只有少數的節點需要全球唯一的IP位址,其他的節點的IP位址應該是可以重用的。
因此,基本的NAT實現的功能很簡單,在子網內使用一個保留的IP子網段,這些IP對外是不可見的。子網內只有少數一些IP位址可以對應到真正全球唯一的IP位址。如果這些節點需要訪問外部網路,那麼基本NAT就負責將這個節點的子網內IP轉化為一個全球唯一的IP然後發送出去。(基本的NAT會改變IP包中的原IP位址,但是不會改變IP包中的埠)
關於基本的NAT可以參看RFC 1631
另外一種NAT叫做NAPT,從名稱上我們也可以看得出,NAPT不但會改變經過這個NAT設備的IP資料報的IP位址,還會改變IP資料報的TCP/UDP埠。基本NAT的設備可能我們見的不多(呵呵,我沒有見到過),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
有一個私有網路10.*.*.*,Client A是其中的一台電腦,這個網路的閘道(一個NAT設備)的外網IP是155.99.25.11(應該還有一個內網的IP位址,比如10.0.0.10)。如果Client A中的某個進程(這個進程創建了一個UDP Socket,這個Socket綁定1234埠)想訪問外網主機18.181.0.31的1235埠,那麼當資料包通過NAT時會發生什麼事情呢?
首先NAT會改變這個資料包的原IP位址,改為155.99.25.11。接著NAT會為這個傳輸創建一個Session(Session是一個抽象的概念,如果是TCP,也許Session是由一個SYN包開始,以一個FIN包結束。而UDP呢,以這個IP的這個埠的第一個UDP開始,結束呢,呵呵,也許是幾分鐘,也許是幾小時,這要看具體的實現了)並且給這個Session分配一個埠,比如62000,然後改變這個資料包的源埠為62000。所以本來是(10.0.0.1:1234->18.181.0.31:1235)的資料包到了互聯網上變為了(155.99.25.11:62000->18.181.0.31:1235)。
一旦NAT創建了一個Session後,NAT會記住62000埠對應的是10.0.0.1的1234埠,以後從18.181.0.31發送到62000埠的資料會被NAT自動的轉發到10.0.0.1上。(注意:這裏是說18.181.0.31發送到62000埠的資料會被轉發,其他的IP發送到這個埠的資料將被NAT拋棄)這樣Client A就與Server S1建立以了一個連接。

呵呵,上面的基礎知識可能很多人都知道了,那麼下面是關鍵的部分了。
看看下面的情況:
    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的原來那個Socket(綁定了1234埠的那個UDP Socket)又接著向另外一個Server S2發送了一個UDP包,那麼這個UDP包在通過NAT時會怎麼樣呢?
這時可能會有兩種情況發生,一種是NAT再次創建一個Session,並且再次為這個Session分配一個埠號(比如:62001)。另外一種是NAT再次創建一個Session,但是不會新分配一個埠號,而是用原來分配的埠號62000。前一種NAT叫做Symmetric NAT,後一種叫做Cone NAT。我們期望我們的NAT是第二種,呵呵,如果你的NAT剛好是第一種,那麼很可能會有很多P2P軟體失靈。(可以慶倖的是,現在絕大多數的NAT屬於後者,即Cone NAT)
好了,我們看到,通過NAT,子網內的電腦向外連結是很容易的(NAT相當於透明的,子網內的和外網的電腦不用知道NAT的情況)。
但是如果外部的電腦想訪問子網內的電腦就比較困難了(而這正是P2P所需要的)。
那麼我們如果想從外部發送一個資料報給內網的電腦有什麼辦法呢?首先,我們必須在內網的NAT上打上一個“洞”(也就是前面我們說的在NAT上建立一個Session),這個洞不能由外部來打,只能由內網內的主機來打。而且這個洞是有方向的,比如從內部某台主機(比如:192.168.0.10)向外部的某個IP(比如:219.237.60.1)發送一個UDP包,那麼就在這個內網的NAT設備上打了一個方向為219.237.60.1的“洞”,(這就是稱為UDP Hole Punching的技術)以後219.237.60.1就可以通過這個洞與內網的192.168.0.10聯繫了。(但是其他的IP不能利用這個洞)。

呵呵,現在該輪到我們的正題P2P了。有了上面的理論,實現兩個內網的主機通訊就差最後一步了:那就是雞生蛋還是蛋生雞的問題了,兩邊都無法主動發出連接請求,誰也不知道誰的公網位址,那我們如何來打這個洞呢?我們需要一個中間人來聯繫這兩個內網主機。
現在我們來看看一個P2P軟體的流程,以下圖為例:

                       Server S (219.237.60.1)
                          |
                          |
   +----------------------+----------------------+
   |                                             |
NAT A (外網IP:202.187.45.3)                 NAT B (外網IP:187.34.1.56)
   |   (內網IP:192.168.0.1)                      | (內網IP:192.168.0.1)
   |                                             |
Client A  (192.168.0.20:4000)             Client B (192.168.0.10:40000)

首先,Client A登錄伺服器,NAT A為這次的Session分配了一個埠60000,那麼Server S收到的Client A的位址是202.187.45.3:60000,這就是Client A的外網地址了。同樣,Client B登錄Server S,NAT B給此次Session分配的埠是40000,那麼Server S收到的B的位址是187.34.1.56:40000。
此時,Client A與Client B都可以與Server S通信了。如果Client A此時想直接發送資訊給Client B,那麼他可以從Server S那兒獲得B的公網位址187.34.1.56:40000,是不是Client A向這個位址發送資訊Client B就能收到了呢?答案是不行,因為如果這樣發送資訊,NAT B會將這個資訊丟棄(因為這樣的資訊是不請自來的,為了安全,大多數NAT都會執行丟棄動作)。現在我們需要的是在NAT B上打一個方向為202.187.45.3(即Client A的外網位址)的洞,那麼Client A發送到187.34.1.56:40000的資訊,Client B就能收到了。這個打洞命令由誰來發呢,呵呵,當然是Server S。
總結一下這個過程:如果Client A想向Client B發送資訊,那麼Client A發送命令給Server S,請求Server S命令Client B向Client A方向打洞。呵呵,是不是很繞口,不過沒關係,想一想就很清楚了,何況還有源代碼呢(侯老師說過:在源代碼面前沒有秘密 8)),然後Client A就可以通過Client B的外網位址與Client B通信了。
注意:以上過程只適合於Cone NAT的情況,如果是Symmetric NAT,那麼當Client B向Client A打洞的埠已經重新分配了,Client B將無法知道這個埠(如果Symmetric NAT的埠是順序分配的,那麼我們或許可以猜測這個埠號,可是由於可能導致失敗的因素太多,我們不推薦這種猜測埠的方法)。

0 意見:

張貼留言

 
Blogger Templates