NAT/NAPT及udp打洞技術的詳解

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的端口是順序分配的，那麼咱們或許能夠猜想這個端口號，但是因爲可能致使失敗的因素太多，咱們不推薦這種猜想端口的方法）。

 

下面是一個模擬P2P聊天的過程的源代碼，過程很簡單，P2PServer運行在一個擁有公網IP的計算機上，P2PClient運行在兩個不一樣的NAT後（注意，若是兩個客戶端運行在一個NAT後，本程序極可能不能運行正常，這取決於你的NAT是否支持loopback translation，詳見http://midcom-p2p.sourceforge.net/draft-ford-midcom-p2p-01.txt，固然，此問題能夠經過雙方先嚐試鏈接對方的內網IP來解決，可是這個代碼只是爲了驗證原理，並無處理這些問題），後登陸的計算機能夠得到先登陸計算機的用戶名，後登陸的計算機經過send username message的格式來發送消息。若是發送成功，說明你已取得了直接與對方鏈接的成功。