UDP Hole Puching技術：穿透防火牆建立UDP連線(轉)

UDP Hole Puching技術：穿透防火牆建立UDP連線(轉)[@more@]

　　在防火牆上鑽孔【UDP Hole Puching】：穿透防火牆建立UDP連線

　　知道現在流行的P2P軟體和IM軟體是如何讓兩臺分處在不同防火牆後面的電腦直接對話的嗎？SIP當然是一種，還有一種被廣泛應用的就是本文介紹的UDP Hole Puching技術。

　　為了便於講述，我們假設有這樣一個網路拓撲結構：

　　IP=A.A.A.A　　 IP=1.1.1.1

　　HostA----------FirewallA---------|

　　|

　　Server IP=S.S.S.S

　　|

　　HostB----------FirewallB---------|

　　IP=B.B.B.B　　 IP=2.2.2.2

　　運用這個技術，必須滿足下面的條件:

　　1) HostA和HostB分別透過FirewallA和FirewallB經過NAT用UDP連線到了Server

　　2) FirewallA和FirewallB都滿足這樣的特性，即來自相同IP相同Port的資料包，不管目的地IP是多少， 都會NAT成相同的IP+Port，舉個例子吧:

　　HostA透過UDP Port 1234訪問主機S1時，防火牆會把資料包NAT成1.1.1.1:5668(舉例),那麼HostA透過UDP Port 1234訪問主機S2時，防火牆仍然會把資料包NAT成1.1.1.1:5668。好在現在的NAT基本上都具備這個特性。

　　現在，HostA用UDP埠1111連線到Server的5555埠，HostB用埠2222連線到Server的5555埠,在Server看來，HostA來自1.1.1.1:9676(FirewallA NAT過了嘛)，HostB則來自2.2.2.2:6573。當HostA想直接連線HostB時，它這樣做：

　　1)用UDP埠1111發一個資料包給2.2.2.2:6573，注意一定要用埠1111哦，這個資料包一定會被FirewallA NAT成 1.1.1.1:9676 -> 2.2.2.2:5668(不要問為什麼，看看前面對防火牆的要求先); 千萬別期望HostB會收到這個資料包，因為當包到達FirewallB時，FirewallB被弄糊塗了，它根本不知道 1.1.1.1:9676 -> 2.2.2.2:6573的資料包應該轉給誰，當然這個包就會被丟棄並回一個ICMP包說Port不存在。但是，我們還是得到了我們想要的一些東西，那就是我們成功地告訴了FirewallA "如果有2.2.2.2:6573 -> 1.1.1.1:9676的資料包，請轉發到A.A.A.A:1111"，這就是一個洞洞!!

　　2)接下來，和你想象的一樣，HostA透過Server中轉，告訴HostB，用埠2222發一個資料包到1.1.1.1:9676，HostB照辦了，而且這個包一定會被FirewallB NAT成 2.2.2.2:6573 -> 1.1.1.1:9676。這個回覆的資料包同樣在FirewallB上鑽了個孔，凡是1.1.1.1:9676 -> 2.2.2.2:6573的包都會被轉發到B.B.B.B:2222，當資料包到達FirewallA時，FirewallA很高興地把2.2.2.2:6573 -> 1.1.1.1:9676的資料包轉發給A.A.A.A:1111。

　　3)大功告成了，HostA和HostB開始愉快的交談起來。

　　很簡單吧?不過實施起來還要注意幾點，否則你都不知道為什麼總連不上：

　　1) 步驟1中那個Port不存在的ICMP是個殺手，至少對Linux上用iptables做的NAT來講是這樣，因為FirewallA收到這個ICMP會關閉剛鑽上的洞洞，想辦法不讓FirewallB發這個ICMP或者讓FirewallA丟掉這個ICMP吧;

　　2) 時間問題，步驟1在FirewallA上開的洞洞是有時間限制的，通常為30－60秒吧，如果超時了都沒收到2.2.2.2:6573 -> 1.1.1.1:9676的包，洞洞會自動關閉，同樣步驟2以後，HostA也應該及時在發個資料包給B，以保證FirewallB上的洞洞不會因為超時而關閉。值得提一下的是多數NAT防火牆會在看見進出雙向的資料包後延長關閉洞洞的時間，Linux預設設定時會延長到3分鐘。

　　3) HostA不能連到HostB，並不表示HostB一定連不到HostA，反一下方向試試也許會有意外驚喜。