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機器在私網（192.168.0.4）
NAT服務器（210.21.12.140）
B機器在公網（210.15.27.166）
C機器在公網（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同一私網（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）保護的兩臺私網機器，都運行了QQ客戶端程序。
B機器在公網（210.15.27.166），運行QQ服務器程序。
C機器在公網（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欲和公網C（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後面僅有一臺私網機器的特例（例3），沒有考慮NAT後面可以有多臺私網機器的普遍例子（例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機器在公網（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對內部私網機器來的所有源端口都將適用Preserves port number，除非確因原則2發生衝突而不得不更換源端口號，但在更換端口號時並不遵循內部端口+1原則（似乎沒有規律）。Win2000下的ics或nat則僅對內部私網機器來的部分源端口（1025--3000）適用Preserves port number，對於那些超過3000的源端口號或者因原則2發生衝突的端口號，系統從1025開始重新按序分配端口，在此過程中，仍然遵循如前兩個原則，只是原則1不再Preserves port number而已（在不與原則2發生衝突的前提下，儘量重複使用小的端口號，故使用1025的機率遠遠大於1026、1027…）。