藍色情懷

iptables下udp穿越基礎篇----iptables與stun

iptables與stun

Stun協議（Rfc3489、詳見 http://www.ietf.org/rfc/rfc3489.txt）將NAT粗略分為4種類型，即 Full Cone、Restricted Cone、Port Restricted Cone和Symmetric。舉個實際例子（例1）來說明這四種NAT的區別：
A機器在Private Network（192.168.0.4）
NAT伺服器（210.21.12.140）
B機器在Public Network（210.15.27.166）
C機器在Public Network（210.15.27.140）
現在，A機器連接過B機器，假設是 A（192.168.0.4:5000）-> NAT（轉換後210.21.12.140:8000）-> B（210.15.27.166:2000）。
同時A從來沒有和C通信過。
則對於不同類型的NAT，有下列不同的結果：
Full Cone NAT：C發數據到210.21.12.140:8000，NAT會將數據包送到A（192.168.0.4:5000）。因為NAT上已經有了192.168.0.4:5000到210.21.12.140:8000的映射。

Restricted Cone：C無法和A通信，因為A從來沒有和C通信過，NAT將拒絕C試圖與A連接的動作。但B可以通過210.21.12.140:8000與A的 192.168.0.4:5000通信，且這裏B可以使用任何埠與A通信。如：210.15.27.166:2001 -> 210.21.12.140:8000，NAT會送到A的5000埠上。

Port Restricted Cone：C無法與A通信，因為A從來沒有和C通信過。而B也只能用它的210.15.27.166:2000與A的192.168.0.4:5000通信，因為A也從來沒有和B的其他埠通信過。該類型NAT是埠受限的。

Symmetric NAT：上面3種類型，統稱為Cone NAT，有一個共同點：只要是從同一個內部位址和埠出來的包，NAT都將它轉換成同一個外部位址和埠。但是Symmetric有點不同，具體表現在： 只要是從同一個內部位址和埠出來，且到同一個外部目標位址和埠，則NAT也都將它轉換成同一個外部位址和埠。但如果從同一個內部位址和埠出來，是 到另一個外部目標位址和埠，則NAT將使用不同的映射，轉換成不同的埠（外部位址只有一個，故不變）。而且和Port Restricted Cone一樣，只有曾經收到過內部位址發來包的外部位址，才能通過NAT映射後的位址向該內部位址發包。

 現針對Symmetric NAT舉例說明（例2）:
A機器連接過B機器，假使是 A（192.168.0.4:5000）-> NAT（轉換後210.21.12.140:8000）-> B（210.15.27.166:2000）
如果此時A機器（192.168.0.4:5000）還想連接C機器（210.15.27.140:2000），則NAT上產生一個新的映射，對 應的轉換可能為A（192.168.0.4:5000）-> NAT（轉換後210.21.12.140:8001）-> C（210.15.27.140:2000）。此時，B只能用它的210.15.27.166:2000通過NAT的210.21.12.140: 8000與A的192.168.0.4:5000通信， C也只能用它的210.15.27.140:2000通過NAT的210.21.12.140:8001與A的192.168.0.4:5000通信，而 B或者C的其他埠則均不能和A的192.168.0.4:5000通信。

 通過上面的例子，我們清楚了Stun協議對NAT進行分類的依據。那麼，我們現在根據上述分類標準（或例子），來簡要分析一下iptables的工作原理（僅指MASQUERADE、下同），看看他又是屬於哪種NAT呢？
首先，我們去網上下載一個使用Stun協議檢測NAT的工具，網址在http://sourceforge.net/projects/stun/，使用該工具對iptables的檢測結果是Port restricted NAT detected。
我們先不要急著接受這個檢測結果，還是先來分析一下iptables的工作原理吧！
 
iptables在轉換位址時，遵循如下兩個原則：
1、儘量不去修改源埠，也就是說，ip偽裝後的源埠盡可能保持不變。（即所謂的Preserves port number）
2、更為重要的是，ip偽裝後只需保證偽裝後的源位址/埠與目標位址/埠（即所謂的socket）唯一即可。 

 仍以前例說明如下（例3）：
A機器連接過B機器，假使是 A（192.168.0.4:5000）-> NAT（轉換後210.21.12.140:5000）-> B（210.15.27.166:2000）。（注意，此處NAT遵循原則1、故轉換後埠沒有改變）
如果此時A機器（192.168.0.4:5000）還想連接C機器（210.15.27.140:2000），則NAT上產生一個新的映射，但 對應的轉換仍然有可能為A（192.168.0.4:5000）-> NAT（轉換後210.21.12.140:5000）-> C（210.15.27.140:2000）。這是因為NAT（轉換後210.21.12.140:5000）-> B（210.15.27.166:2000）和NAT（轉換後210.21.12.140:5000）-> C（210.15.27.140:2000）這兩個socket不重複。因此，對於iptables來說，這既是允許的（第2條原則）、也是必然的（第1 條原則）。
在該例中，表面上看起來iptables似乎不屬於Symmetric NAT，因為它看起來不符合Symmetric NAT的要求：如果從同一個內部位址和埠出來，是到另一個目標位址和埠，則NAT將使用不同的映射，轉換成不同的埠（外部位址只有一個，故不變）。 相反，倒是符合除Symmetric NAT外的三種Cone NAT的要求：從同一個內部位址和埠出來的包，NAT都將它轉換成同一個外部位址和埠。加上iptables具有埠受限的屬性（這一點不容置疑，後 面舉反例證明之），所以好多檢測工具就把iptables報告為Port restricted NAT類型了。

 下面仍以前例接著分析（例4）：
在前例中增加D機器在A同一Private Network（192.168.0.5）
A機器連接過B機器，假使是 A（192.168.0.4:5000）-> NAT（轉換後210.21.12.140:5000）-> B（210.15.27.166:2000）
D機器連接過C機器，假使是 D（192.168.0.5:5000）-> NAT（轉換後210.21.12.140:5000）-> C（210.15.27.140:2000）
由iptables轉換原則可知，上述兩個轉換是允許且必然的。
如果此時A機器（192.168.0.4:5000）還想連接C機器（210.15.27.140:2000），則NAT上產生一個新的映射，但 對應的轉換則變為A（192.168.0.4:5000）-> NAT（轉換後210.21.12.140:5001）-> C（210.15.27.140:2000）。這是因為，如果仍然將其轉換為210.21.12.140:5000的話，則其所構成的socket （210.21.12.140:5000->210.15.27.140:2000）將和D->C的socket一致，產生衝突，不符合 iptables的第2條原則（注意，此處以5001表示轉換後不同的埠，但事實上，iptables卻並不按照內部埠+1的原則來產生新的埠）。 在本例中我們注意到，從同一個內部位址和埠A（192.168.0.4:5000）出來，到不同的目標位址和埠，則NAT使用了不同的映射，轉換成不 同的埠。

 上面這個例子在實際環境中比較少見，我們再以QQ為例舉一個真實且常見的例子（例5）。
假設
A（192.168.0.4）和 D（192.168.0.5）是同一NAT伺服器（210.21.12.140）保護的兩台Private Network機器，都運行了QQ用戶端程式。
B機器在Public Network（210.15.27.166），運行QQ伺服器程式。
C機器在Public Network（210.15.27.140），運行QQ用戶端程式。
A上QQ先登陸到B，按照原則1，使用如下映射：
A（192.168.0.4:4000）-> NAT（轉換後210.21.12.140:4000）-> B（210.15.27.166:8000）（原則1，埠不變）
接著D上QQ也登陸到B，按照原則2，使用如下映射：
D（192.168.0.5:4000）-> NAT（轉換後210.21.12.140:4001）-> B（210.15.27.166:8000）（原則2，scoket不能有重複，此處4001僅表示轉換後不同的埠，實際環境中決不是4001）
然後D欲和Public NetworkC（210.15.27.140）上的QQ通信，按照iptables轉換原則，使用如下映射：
D（192.168.0.5:4000）-> NAT（轉換後210.21.12.140:4000）-> C（210.15.27.140:4000）
到此我們發現，和上例一樣，從同一個內部位址和埠D（192.168.0.5:4000）出來，到不同的目標位址和埠，則NAT使用了不同的映射，轉換成不同的埠。但和上例不一樣的是，本例顯然普遍存在於實際環境中。
上面所舉兩例表明，結論剛好和例3相反，即iptables應該屬於Symmetric NAT。
為什麼會出現彼此矛盾的情況呢？首先從NAT分類的定義上來看， Stun協議和iptables對映射的理解不同。Stun協議認為，一個映射的要素是：內部位址埠和NAT轉換後位址埠的組合。而在 iptables看來，一個映射的要素是：NAT轉換後位址埠和外部目標位址埠的組合。另一方面則是Stun協議裏Discovery Process給出的測試環境不夠全面之故，他只考慮了NAT後面僅有一台Private Network機器的特例（例3），沒有考慮NAT後面可以有多台Private Network機器的普遍例子（例 5）。正是由於這兩個原因，直接導致了上述矛盾的發生。所以，凡按照Stun協議標準設計的NAT分類檢測工具對iptables的檢測結果必然是 Port restricted NAT。（事實上，在例3那樣的特例下，iptables確實是一個標準的Port restricted NAT）
那麼，iptables究竟屬於哪種NAT呢？我們再來回顧一下Stun協議對Cone NAT的要求：所有（或只要是）從同一個內部位址和埠出來的包，NAT都將它轉換成同一個外部位址和埠。雖然iptables在部分情況下滿足“從同 一個內部位址和埠出來的包，都將把他轉換成同一個外部位址和埠”這一要求，但它不能在所有情況下滿足這一要求。所以理論上，我們就只能把 iptables歸為Symmetric NAT了。

 下面，我們再來分析一下iptables的埠受限的屬性，我們舉一個反例證明之（例6），仍以前例說明如下：
A機器連接過B機器，假使是 A（192.168.0.4:5000）-> NAT（轉換後210.21.12.140:5000）-> B（210.15.27.166:2000）
D機器連接過C機器，假使是 D（192.168.0.5:5000）-> NAT（轉換後210.21.12.140:5000）-> C（210.15.27.140:2000）
現假設iptables不具有埠受限的屬性，則另一E機器在Public Network（210.15.27.153:2000）或C（210.15.27.140: 2001）向210.21.12.140:5000發包的話，應該能夠發到內部機器上。但事實是，當這個包到達NAT（210.21.12.140: 5000）時，NAT將不知道把這個包發給A（192.168.0.4:5000）還是D（192.168.0.5:5000）。顯然，該包只能丟棄，至 此，足以證明iptables具有埠受限的屬性。
所以，iptables是貨真價實的Symmetric NAT。

附：
1、Stun全稱Simple Traversal of UDP Through NATs，所以本文所涉及的封包，皆為UDP封包。
2、本文雖然是針對linux下iptables的分析，但倘若把本文中關鍵字“iptables”換成“Win2000下的ics或nat”， 則本文的分析過程完全適用於Win2000下的ics或nat。即理論上Win2000下的ics或nat也是貨真價實的Symmetric NAT，但實際上，凡按照Stun協議標準設計的NAT分類檢測工具對其檢測結果也必然是Port restricted NAT。其實，不光是linux下iptables、或者Win2000下的ics或nat、再或者任何其他NAT產品，只要他們遵循和iptables 一樣的兩條轉換原則，那麼他們在Stun協議下的表現是完全一樣的。
3、雖然Win2000下的ics或nat在Stun協議下的表現和iptables完全一樣，但其NAT時所遵循的原則1和iptables 還是略有差別：iptables對內部Private Network機器來的所有源埠都將適用Preserves port number，除非確因原則2發生衝突而不得不更換源埠號，但在更換埠號時並不遵循內部埠+1原則（似乎沒有規律）。Win2000下的ics或 nat則僅對內部Private Network機器來的部分源埠（1025--3000）適用Preserves port number，對於那些超過3000的源埠號或者因原則2發生衝突的埠號，系統從1025開始重新按序分配埠，在此過程中，仍然遵循如前兩個原則， 只是原則1不再Preserves port number而已（在不與原則2發生衝突的前提下，儘量重複使用小的埠號，故使用1025的幾率遠遠大於1026、1027…）。