NAT原理與NAT穿越
最近在看東西的時候發現很多網絡程序中都需要NAT穿越，特意在此總結一下。
先做一個約定：
內網A中有：A1（192.168.0.8）、A2（192.168.0.9）兩用戶
網關X1（一個NAT設備）有公網IP 1.2.3.4
內網B中有：B1（192.168.1.8）、B2（192.168.1.9）兩用戶，
網關Y1（一個NAT設備）有公網IP 1.2.3.5
公網服務器：C (6.7.8.9) D (6.7.8.10)
NAT原理
網絡地址轉換(NAT,Network Address Translation)屬接入廣域網(WAN)技術，是一種將私有（保留）地址轉化為合法IP地址的轉換技術。下面介紹兩類不同方式實現的NAT：
- NAT(Network Address Translators)：稱為基本的NAT
在客戶機時 192.168.0.8:4000——6.7.8.9:8000
在網關時 1.2.3.4:4000——6.7.8.9:8000
服務器C 6.7.8.9:8000
其核心是替換IP地址而不是端口，這會導致192.168.0.8使用4000端口后，192.168.0.9如何處理？具體參考RFC 1631
基本上這種類型的NAT設備已經很少了。或許根本我們就沒機會見到。
2. NAPT(Network Address/Port Translators)：其實這種才是我們常說的 NAT
NAPT的特點是在網關時，會使用網關的 IP，但端口會選擇一個和臨時會話對應的臨時端口。如下圖：
在客戶機時 192.168.0.8:4000——6.7.8.9:8000
在網關時 1.2.3.4:62000——6.7.8.9:8000
服務器C 6.7.8.9:8000
網關上建立保持了一個1.2.3.4:62000的會話，用於192.168.0.8:4000與6.7.8.9:8000之間的通訊。
對於NAPT，又分了兩個大的類型，差別在於，當兩個內網用戶同時與8000端口通信的處理方式不同：
2.1、Symmetric NAT型 (對稱型)
在客戶機時 192.168.0.8:4000——6.7.8.9:8000 192.168.0.8:4000——6.7.8.10:8000
在網關時，兩個不同session但端口號不同 1.2.3.4:62000——6.7.8.9:8000 1.2.3.4:62001——6.7.8.10:8000
服務器C 6.7.8.9:8000
服務器 D 6.7.8.10:8000
這種形式會讓很多p2p軟件失靈。
2.2、Cone NAT型（圓錐型）
在客戶機時 192.168.0.8:4000——6.7.8.9:8000 192.168.0.8:4000——6.7.8.10:8000
在網關時，兩個不同session但端口號相同 1.2.3.4:62000——6.7.8.9:8000 1.2.3.4:62000——6.7.8.10:8000
服務器C 6.7.8.9:8000
服務器D 6.7.8.10:8000
目前絕大多數屬於這種。Cone NAT又分了3種類型：
- a)Full Cone NAT（完全圓錐型）：從同一私網地址端口192.168.0.8:4000發至公網的所有請求都映射成同一個公網地址端口1.2.3.4:62000 ，192.168.0.8可以收到任意外部主機發到1.2.3.4:62000的數據報。
- b)Address Restricted Cone NAT （地址限制圓錐型）：從同一私網地址端口192.168.0.8:4000發至公網的所有請求都映射成同一個公網地址端口1.2.3.4:62000，只有當內部主機192.168.0.8先給服務器C 6.7.8.9發送一個數據報后，192.168.0.8才能收到6.7.8.9發送到1.2.3.4:62000的數據報。
- c)Port Restricted Cone NAT（端口限制圓錐型）：從同一私網地址端口192.168.0.8:4000發至公網的所有請求都映射成同一個公網地址端口1.2.3.4:62000，只有當內部主機192.168.0.8先向外部主機地址端口6.7.8.9：8000發送一個數據報后，192.168.0.8才能收到6.7.8.9：8000發送到1.2.3.4:62000的數據報。
穿越NAT的實現
A1在客戶機時 192.168.0.8:4000——6.7.8.9:8000
X1在網關時 1.2.3.4:62000——6.7.8.9:8000
服務器C 6.7.8.9:8000
B1在客戶機時 192.168.1.8:4000——6.7.8.9:8000
Y1在網關時 1.2.3.5:31000——6.7.8.9:8000
兩內網用戶要實現通過各自網關的直接呼叫，需要以下過程：
1、 客戶機A1、B1順利通過格子網關訪問服務器C ，均沒有問題（類似於登錄）
2、 服務器C保存了 A1、B1各自在其網關的信息（1.2.3.4:62000、1.2.3.5:31000）沒有問題。並可將該信息告知A1、B2。
3、 此時A1發送給B1網關的1.2.3.5:31000是否會被B1收到？答案是基本上不行（除非Y1設置為完全圓錐型，但這種設置非常少），因為Y1上檢測到其存活的會話中沒有一個的目的IP或端口於1.2.3.4:62000有關而將數據包全部丟棄！
4、 此時要實現A1、B1通過X1、Y1來互訪，需要服務器C告訴它們各自在自己的網關上建立“UDP隧道”，即命令A1發送一個 192.168.0.8:4000——1.2.3.5:31000的數據報，B1發送一個192.168.1.8:4000——1.2.3.4:62000的數據報，UDP形式，這樣X1、Y1上均存在了IP端口相同的兩個不同會話（很顯然，這要求網關為Cone NAT型，否則，對稱型Symmetric NAT設置網關將導致對不同會話開啟了不同端口，而該端口無法為服務器和對方所知，也就沒有意義）。
5、 此時A1發給Y1，或者B1發給X1的數據報將不會被丟棄且正確的被對方收到.
綜合P2P可實現的條件需要：
1、 中間服務器保存信息、並能發出建立UDP隧道的命令
2、 網關均要求為Cone NAT類型。Symmetric NAT不適合。
3、 完全圓錐型網關可以無需建立udp隧道，但這種情況非常少，要求雙方均為這種類型網關的更少。
4、 假如X1網關為Symmetric NAT， Y1為Address Restricted Cone NAT 或Full Cone NAT型網關，各自建立隧道后，A1可通過X1發送數據報給Y1到B1(因為Y1最多只進行IP級別的甄別)，但B2發送給X1的將會被丟棄（因為發送來的數據報中端口與X1上存在會話的端口不一致，雖然IP地址一致），所以同樣沒有什么意義。
5、 假如雙方均為Symmetric NAT的情形，新開了端口，對方可以在不知道的情況下嘗試猜解，也可以達到目的，但這種情形成功率很低，且帶來額外的系統開支，不是個好的解決辦法。
6、 不同網關型設置的差異在於，對內會采用替換IP的方式、使用不同端口不同會話的方式，使用相同端口不同會話的方式；對外會采用什么都不限制、限制IP地址、限制IP地址及端口。
7、 這里還沒有考慮同一內網不同用戶同時訪問同一服務器的情形，如果此時網關采用AddressRestricted Cone NAT 或Full Cone NAT型，有可能導致不同用戶客戶端可收到別人的數據包，這顯然是不合適的。
一些現在常用的技術：
ALG（應用層網關）：它可以是一個設備或插件，用於支持SIP協議，主要類似與在網關上專門開辟一個通道，用於建立內網與外網的連接，也就是說，這是一種定制的網關。更多只適用於使用他們的應用群體內部之間。
UpnP：它是讓網關設備在進行工作時尋找一個全球共享的可路由IP來作為通道，這樣避免端口造成的影響。要求設備支持且開啟upnp功能，但大部分時候，這些功能處於安全考慮，是被關閉的。即時開啟，實際應用效果還沒經過測試。
STUN（Simple Traversalof UDP Through Network）：這種方式即是類似於我們上面舉例中服務器C的處理方式。也是目前普遍采用的方式。但具體實現要比我們描述的復雜許多，光是做網關Nat類型判斷就由許多工作，RFC3489中詳細描述了。
TURN(Traveral Using Relay NAT)：該方式是將所有的數據交換都經由服務器來完成，這樣NAT將沒有障礙，但服務器的負載、丟包、延遲性就是很大的問題。目前很多游戲均采用該方式避開NAT的問題。這種方式不叫p2p。
ICE(Interactive Connectivity Establishment)：是對上述各種技術的綜合，但明顯帶來了復雜性。