STUN檢測NAT類型原理

STUN是RFC3489規定的一種NAT穿透方式，它採用輔助的方法探測NAT的IP和端口。毫無疑問的，它對穿越早期的NAT起了巨大的作用，並且還將繼續在ANT穿透中佔有一席之地。
STUN的探測過程需要有一個公網IP的STUN Server，在NAT後面的UAC（User Agent Client）必須和此Server配合，互相之間發送若干個UDP數據包。UDP包中包含有UAC需要了解的信息，比如NAT外網 IP，PORT等等。UAC通過是否得到這個UDP包和包中的數據判斷自己的NAT類型。
假設有如下UAC（B），NAT（A），STUN SERVER（C），UAC的IP爲IPB，NAT的IP爲IPA，SERVER的IP爲IPC1、IPC2。請注意，STUN 服務器C有兩個IP，後面你會理解爲什麼需要兩個IP。

STEP1：
B向C的IP1的port1端口發送一個UDP包。C收到這個包後，會把它收到包的源IP和port寫到UDP包中，然後把此包通過IP1和port1發還給B。這個IP和port也就是NAT的外網IP和port，也就是說UAC在STEP1中就得到了NAT的外網IP。
如果在UAC向一個STUN服務器發送數據包後，沒有收到STUN的任何迴應包，那只有兩種可能：1、STUN服務器不存在，或者port弄錯了；2、你的NAT拒絕一切UDP包從外部向內部通過（我們公司的NAT就是）。
當B收到此UDP後，把此UDP中的IP和自己的IP做比較，如果是一樣的，就說明自己是在公網。如果不一樣，說明有NAT的存在，系統進行STEP2的操作。

STEP2：
B向C的IP1發送一個UDP包，請求C通過另外一個IP2和PORT（不同與SETP1的IP1）向B返回一個UDP數據包（現在知道爲什麼C要有兩個IP了吧，呵呵）。
我們來分析一下，如果B收到了這個數據包，那說明什麼？說明NAT來者不拒，不對數據包進行任何過濾，這也就是STUN標準中的full cone NAT。遺憾的是，full cone NAT太少了，這也意味着你能收到這個數據包的可能性不大。如果沒收到，那麼系統進行STEP3的操作。

STEP3：
B向C的IP2的port2發送一個數據包，C收到數據包後，把它收到包的源IP和port寫到UDP包中，然後通過自己的IP2和port2把此包發還給B。和step1一樣，B肯定能收到這個迴應UDP包。此包中的port是我們最關心的數據，下面我們來分析：
如果這個port和step1中的port一樣，那麼可以肯定這個NAT是個CONE NAT，否則是對稱NAT。道理很簡單：根據對稱NAT的規則，當目的地址的IP和port有任何一個改變，那麼NAT都會重新分配一個port使用，而在step3中，和step1對應，我們改變了IP和port。因此，如果是對稱NAT,那這兩個port肯定是不同的。
如果在你的應用中，到此步的時候PORT是不同的，恭喜你，你的STUN已經死了。如果不同，那麼只剩下了restrict cone和port restrict cone。系統用step4探測是是哪一種。

STEP4：
B向C的IP2的一個端口PD發送一個數據請求包，要求C用IP2和不同於PD的port返回一個數據包給B。
我們來分析結果：如果B收到了，那也就意味着只要IP相同，即使port不同，NAT也允許UDP包通過。顯然這是restrict cone NAT。如果沒收到，沒別的好說，port restrict NAT.