2012年02月09日
點擊數: 22314 字體: 大 中 小 
一鍵關注匯訊
[摘要]近些年，標準化社區已經開發出一些UDP穿透NAT/防火墻的技術（也就是，在NAT之后的主機之間建立UDP流）。然而，由于TCP連接建立的不對稱特點，TCP的NAT穿透要困難的多。最近，研究者們提出了多種TCP穿透NAT的途徑，然而，這些方法中，成功的都依賴于NAT對各種TCP（和TCMP）包的序列如何響應的。本文對TCP穿透主流商用NAT產品的主要技術進行了首次深入、廣泛的研究。我們開發了一套公開、有效的軟件測試套件用來測定NAT對各種獨立探測以及完整的TCP連接建立的響應。我們在實驗室測試了16個NAT產品，在公網上測試了93個家用NAT產品。根據這些測試結果，如同NAT產品的市場宣傳那樣，我們評估了家用網絡中NAT穿透成功的可能性。本文的另外一個出發點，就是可以給TCP穿透NAT協議的設計和NAT/防火墻行為的標準化工作給與指導，包括IPv6過渡期間IPv4與IPv6之間穿透NAT的鑒定。
1 緒論
NAT和防火墻通過阻止外部主機主動連接一個受保護的內網1主機的方式破壞了IP連通性模型。如果兩個終端都被他們各自的NAT或防火墻保護著，由于發起連接的終端在另一終端的NAT2之外，通常的TCP連接是不能建立的，除非各自的防火墻安全策略允許這樣的連接。例如，防火墻策略是這樣的：內部主機可以發起TCP連接，而且兩個主機都希望發起連接。近來的研究工作已經集中在不使用代理或隧道來建立TCP連接。通過在NAT上設置必要的連接狀態，并仔細、巧妙地交換TCP包的方式來建立TCP連接，確實很輕巧。然而，并不是公網上的所有NAT都用同樣的方式響應，所以，造成這些方式在很多情況下失敗。理解NAT的這種行為，測定他們對Internet中普遍連通性的原始目標的偏移有多少，對于把他們干凈利索地集成到這種架構中是至關重要的。
今天的Internet架構于TCP/IP設計之初的環境已經大不相同。防火墻和NAT經常是的建立一個連接成為不可能，即使連接沒有違反任何安全策略。例如，通過隱藏在一個NAT后面或配置他們的防火墻阻止外入的SYN包，Alice和Bob可能都不允許未授權的連接。然而，當Alice和Bob都同意建立連接的時候，如果不重新配置他們的NAT，他們也沒有辦法建立了，因為Alice的SYN包會被Bob的NAT阻止，Bob的SYN包也會被Alice的NAT阻止。雖然如此，但NAT和防火墻已經成為網絡架構中的永久一部分了，而且，很長一段時間內，仍將會是。即使IPv6已經在全球展開，但在過渡期間，IPv4與IPv6之間的NAT仍將是必須的，而且，為了安全，IPv6防火墻仍將是必須的。因此，使得NAT后面的同意連接的主機之間能夠彼此通訊的機制，是必須的。
通過STUN，已經解決了UDP方式的穿透問題。使用STUN，Alice發送一個UDP包給Bob，盡管這個包被Bob的NAT阻止，但卻使Alice的NAT創建了一個本地狀態，該狀態允許Bob的回應包到達Alice而不被Alice的NAT阻止。然后，Bob發送一個UDP包給Alice，Alice的NAT認為這個包是第一個包的網絡流的一部份，所以路由它通過；同樣，Bob的NAT把第二個包（Bob發給Alice的包）當作一個連接發起，因此創建本地狀態并路由Alice的回應包。流行的VoIP應用程序Skype就是使用的這種方式。不幸的是，建立TCP連接要比這復雜的多。一旦Alice發送了她的SYN包，她的操作系統就如同她的NAT一樣，期望從Bob接收到一個SYNACK包作為回應。然而，由于Alice的SYN包被Bob的NAT阻止，Bob的協議棧根本不會產生SYNACK。解決這個問題的建議工作很復雜，因為廣域網中與NAT的交互很難理解，而且他們解決該問題建議的可行性也是未知的。因此，像Skype中文件傳輸模塊這樣的應用程序，就是用了與UDP類似的受限協議。雖然這種途徑也許可以工作，但我們相信，無論如何，只要可能，應用程序使用本地操作系統的TCP協議棧是很重要的。這是避免增加協議棧復雜性的一部份，而且更重要的是，這么多年以來，為了高性能和擁賽控制，TCP協議棧已經被仔細優化。
全部工作可以歸結為四點：第一，我們鑒別并描述了對TCP穿透NAT重要的全部NAT特點；第二，我們測定了多種建議解決途徑中P2P的TCP連接的成功率和各自的特點；第三，基于這些測定，我對這些建議途徑提出了改進；第四，我們提供了通用的軟件工具，可以用來測定NAT的發展以及P2P應用程序中TCP穿透NAT的基礎。總而言之，我們對穿透NAT的成功率與實現的復雜性之間的內在均衡為應用開發者們提出了建議。最后，我們的結果可以為NAT和防火墻的標準化進程提供指導，使NAT和防火墻具有更好的穿透性，但又不失原有的安全策略。
本文后面的內容安排如下：第二部分討論了建議的TCP穿透NAT的方法；第三部分和第四部分說明了我們測試NAT的組織和觀察到的NAT行為；第五部分分析了端口預測；第六部分分析了P2P中TCP連接的建立；第七部分討論了相關的工作；第八部分對全文進行了總結。
2 TCP NAT-Traversal
這部分我們討論TCP穿透NAT的方法，這些方法在最近的文章中被提出。所有這些方法中，兩個終端都發起一個TCP連接。從每個主機向外發出的SYN包在自己的NAT上創建必要的NAT狀態。然后，每種方法都通過本節描述的不同機制，把兩個TCP的嘗試連接轉換為一個單一的連接。這些原始SYN包被發送的目的地址和端口，通過端口預測決定。端口預測允許主機在發送外出的SYN之前猜測NAT為一個連接的映射，詳細方法稍后討論。這些方法也需要兩臺主機之間相互協調。比如通過第三方或UDP/STUN會話等這樣的連接代理作為輔助通道，就是一種技巧。一旦建立了直接的TCP連接，輔助通道就可以關閉了。協調機制在不同的NAT中觸發不同的行為，這也導致了在很多情況下，所建議的方法會失敗。而且，終端也可能處在連續的多個3NAT后面。這種情況下，所觀察到的行為是整個通路上所有NAT和防火墻行為的復合。簡單的講，我們應該明白，這里的NAT是指復合的NAT/防火墻。
2.1 STUNT
在參考文獻[9]中，作者提出了兩種穿透NAT的方法。第一種方法，如圖-1所示，終端雙方都主動發送SYN，且SYN的TTL4要足夠大，大到SYN包能穿過他們各自的NAT，但TTL又要足夠小，小到穿過各自的NAT后就過期而被網絡丟棄。通過偵聽經過RAW-socket或PCAP向外發送的SYN，終端可以得知初始TCP的序號。終端雙方把各自的序號告訴都能抵達（連接）的STUN Server，緊接著，STUN Server通過設置匹配的序號構造一個SYNACK來欺騙雙方（雙方都認為該SYNACK是對方回應的）。完成TCP握手任務的ACK按照正常方式穿過網絡。這種方法有四個潛在的問題：第一，它需要終端確定一個TTL，該TTL足夠大，大到可以穿透自己的NAT，但又要足夠小，小到不能到達對方的NAT；第二，作為SYN包的回應，比TTL優先的ICMP錯誤是可能產生的，而且，也可能被NAT認為是致命的錯誤；第三，NAT可能改變初始SYN的TCP序號，這樣就可能導致基于原始序號的欺騙SYNACK到達NAT時，被當作窗口之外的包；第四，它需要一個第三方為一個任意地址產生一個欺騙包，而該欺騙包很可能被網絡中各種各樣的進出過濾器丟棄。這些網絡和NAT實例在表-1中總結。
參考文獻[9]中提出的第二種方法，與參考文獻[5]中提出的方法類似，只有一個終端發出一個低TTL的SYN包，接著該發送者取消該連接企圖，并在相同的地址和端口創建一個被動的TCP套接字。然后，另一個終端初始化一個正常的TCP連接，如圖-1（b）所示。與第一種方法一樣，終端需要挑選一個恰當的TTL，而且NAT也不能把ICMP錯誤當作致命錯誤。它也需要NAT在一個向外發的SYN后，接收一個向內發的SYN，但包的序號也不是普通的那種。
2.2 NATBlaster
參考文獻[3]中，作者提出了一種與第一種STUN方法類似但取消了IP欺騙需要的方法（如圖-1c所示）。每個終端發出一個低TTL的SYN，并記住協議棧所使用的TCP序號。與前面的類似，SYN包在網絡中被丟棄。兩臺主機之間交換各自的序號，并且每臺主機手工產生一個對方期望收到的SYNACK包。手工產生的包通過RAW socket注入網絡。然而，這并不等同于欺騙，因為該包中的源地址與注入該包的終端地址匹配。一旦收到SYNACK，ACK就被交換了，從而完成了連接建立。與第一種STUNT方法一樣，該方法也需要終端準確地選擇TTL值，也需要NAT忽略ICMP錯誤和NAT改變SYN包序號的失敗。而且，（該方法）也需要NAT允許一個外發的SYN之后緊跟一個外發的SYNACK——非正常的另一個序號的包。
2.3 Peer-to-Peer NAT
參考文獻[6]中，作者利用了TCP規范[13]中定義的同時打開方案。如圖-1d所示，兩個終端都通過發送SYN包來創建一個連接。如果SYN包在網絡中交叉（穿過），這兩個終端協議棧都用SYNACK包應答從而建立連接。如果在對方的SYN包離開它的NAT之前，一個終端的SYN包到達該終端的NAT而被丟棄，那么，第一個終端的協議棧會在TCP同時打開之后而結束（關閉），而另一個終端則會按照正常流程打開。接下來的情況，鏈路中的包看起來像第二種STUNT方法，沒有底TTL，也沒有相關的ICMP。然而，該方法并沒有用端口預測，如果使用的話，該方法可以從中獲益。與第二種STUNT方法一樣，該方法需要NAT允許在一個外發的SYN之后緊跟一個內發的SYN，而且，該方法需要終端在一個循環中不停的嘗試重連，直到超時。如果不是SYN包被丟棄，而是NAT返回一個TCP RST，那這種方法將陷入包泛濫的境地，直到超時。
2.4 實現
我們在Linux和Windows上實現了上面所述的所有方法。我們還開發了一個Windows設備驅動，它實現了這些方法所需要的但Windows本身不支持的功能（函數）。第一種STUNT方法，無論是在Windows下還是在Linux下，都需要超級用戶特權來監聽鏈路中的TCP SYN包并獲取其序號。為了設置第一個SYN包的TTL，我們在Linux下使用了IP_TTL套接字選項，在Windows下使用了我們的驅動。我們還實現了STUNT Server，并把它部署在ISP后面，為了欺騙任意地址，該ISP不進行外出過濾。雖然該Server可以欺騙大部分SYNACK，但是，如果源和目標在同一個管理域或者該域使用了準入過濾，它的欺騙SYNACK就不成功了。等可能的時候，我們在這種域中安裝一個另外的STUNT Server。第二種STUNT方法需要該驅動來設置Windows下的TTL。NATBlaster方法需要超級用戶特權來獲取SYN的序號并通過RAW socket注入手工創建的SYNACK。由于Windows XP SP2中引入的限制，該方法需要我們的驅動來注入（SYNACK）包。P2PNAT方法需要操作系統支持TCP同時打開，Linux和Windows XP SP2支持TCP同時打開，但SP2之前的Window XP都不支持。在Windows XP SP1以及之前的版本中，我們的驅動增加了TCP同時打開的支持。表-1總結了這些實現結果。
我們發現，在Windows下設置TTL是有問題的，因此，我們考慮了不使用它的后果。如果TTL不消減，一個主機發送的第一個SYN，在對方的SYN離開其NAT之前到達對方的NAT，那對方的NAT可以悄無聲息地丟棄該入站的包，也可以返回一個ICMP不可達錯誤或一個TCP RST/ACK。無論怎樣，回應可能觸發該方法中未說明的發送者NAT以及操作系統棧中的轉變。如果發送到對方的SYN的TTL不被消減，該SYN可能到達預期的目標并觸發無法預料的轉換。這種行為對于最終目標可能是有利的，例如，如果它觸發一個TCP同時打開；如果它擾亂了協議棧或NAT，則它是有害的。我們實現了上述方法的修正版，它不使用低TTL。表-1列出了與修正方法對應的網絡和實現結果。
3 實驗安裝
我們定義了STUNT client-server協議，該協議既可以測試NAT/防火墻的行為，也可以幫助NAT后面peer之間建立TCP連接。完整的協議描述請參考文獻[7]。我們的測試程序實現了該協議，測試程序包括一個client組件和一個server組件。如圖-2所示，client運行在一臺一個或多個NAT后面的主機上，而server則在他們之外。該STUNT測試client偵測client和server之間的所有NAT和防火墻的合成行為。雖然測試client和server都需要超級特權來分析鏈路層的raw socket，但為了降低功能損失并保證client之間的交互，可以降低（取消）該需求（超級特權）。而且，該server至少需要兩個網絡接口來正確區分各種NAT所用的端口分配算法。該client的測試性能以及由此推演的NAT特點在后面的第四部分描述。
我們用該client測試了實驗（表-2）中16個NAT中多種集合。這些NAT包括了我們在美國的網上商店所能找到的各種品牌NAT。這些測試NAT也包括了當前流行操作系統所實現的軟件NAT。在每個實驗測試中，client主機是該NAT內的唯一主機，server與該NAT的外部接口在同一以太網段內。Client主機被設置為只由測試程序產生網絡通信，而不產生任何其他的網絡通信。
而且，為了這些實驗測試，我們也測試了其他NAT設備。這樣做的主要原因是把我們的測試軟件暴露給更廣的情況范圍，而不僅僅是我們在實驗室能夠重現的情況，從而提高它的魯棒性，也增強我們對它操作性的信心。而且，還提供了一個示例，雖然小，但可以用它測試出實際看到的NAT是什么類型。為此，我們請求家庭用戶運行該測試client，共測試了計算機系、Cornell的學生以及其他大學所用的93個家用NAT，而且，測試通信是該client主機與NAT之后的其他主機之間的典型網絡活動，包括web瀏覽、即時消息、p2p文件共享以及email等。測試數據告訴我們，NAT品牌與新舊模塊和固件是混合在一起的。當然，必須承認，在NAT和相關小用戶的選擇上是存在偏見的，他們大部分在美國的東北部。這種差異在表-3中很明顯，我們示例中觀察到的品牌普及率在“Sample”列中，Synergy Research Group調查的2005年第一季度的世界SOHO/家用廣域網市場品牌份額在“Market Survey”列中。特別要說明的是，Buffalo科技和Netgear（的NAT）在我們的示例中表現一般，其他品牌的（NAT的市場份額）明顯更高。家用NAT測試的完整列表請參考文獻[8]。
4 NAT TCP特點
這一節，我們確定不同NAT怎樣影響TCP的NAT穿透方法。根據NAT的行為，我們劃分了五個類別，即NAT映射、終端包過濾、過濾應答、TCP序號預留和TCP定時器。每個類別的分類和NAT能夠接收到的值之間的關系如表-4所示。我們使用STUNT的測試client和前面第三節中描述的server對實驗室中的16個NAT和世界各地的93個NAT進行了分類。完整的測試結果以及更廣范圍的分類集合在參考文獻[8]中有描述。
4.1NAT映射
NAT為每個基于源和目的IP和端口的TCP連接選擇一個對外映射。在某些條件下，有些NAT會重用已經存在的映射，而有些則每次都分配新的映射。NAT映射類別就捕捉這些映射行為的不同。這對于那些企圖穿透NAT的終端來說非常有用，因為這可以讓他們基于之前的連接來預測一個（新）連接的映射地址和端口。根據參考文獻[15]，對于UDP來說，我們知道，有些NAT為那些從同一個源地址和端口產生的所有連接，總是分配一個固定的地址和端口。用STUNT的client，我們測試了TCP的類似行為。如圖-3和表-5所示，該（STUNT）client快速連續從固定的本地地址和端口a:p向不同server地址和端口建立了12個連接。每個連接在下一個連接產生之前關閉。Server把其感知到的映射地址和端口返回給該client。測試選擇了多個不同的本地端口重復了多次。
從表-5中的NAT1——NAT6的端口映射中，我們注意到幾個截然不同的模式。假設每個NAT為第一個連接分配的映射叫做A:P，只要該client新連接的源地址和端口與第一次連接的相同，NAT1就一直重用該映射。我們把這種行為歸類為NB:Independent，因為映射只由源地址和端口決定，而獨立于目的地址和端口。這與參考文獻[15]中擴展到包括TCP的“cone behavior”相同。只要新連接的源和目標的地址和端口與第一次連接的匹配，NAT2就重用該映射。這種NAT杯歸類為NB:Address and Port1，因為目標地址和端口都影響映射。下標“1” 表示兩個新映射之間的差，用δ表示，就是1。參考文獻[17]中表明，對UDP來說，許多NAT的δ是固定的，通常是1或2。我們發現NAT對TCP也有同樣的特點，而且，我們所遇到的NAT，δ都為1。NAT3為每個新連接分配一個新的映射，盡管每個新映射的端口只比前一個（映射的）端口大1，即δ=1。我們把NAT3歸類為NB:Connection1。與NAT3類似，NAT4為每個TCP連接分配一個新的映射，但兩個并發映射之間卻沒有區分模式。我們把這類NAT歸類為NB:ConnectionR，下標R表示δ是隨機的。NAT5是NAT2的一個變種，在NAT5中，只要目標端口匹配就重用該映射，去除了源地址和端口（也匹配的條件）。NAT6也與此類似，只是用目標地址代替了目標端口的匹配。NAT5和NAT6各自被歸類為NB:Port1和NB:Address1。NAT2~6呈現的對稱行為參見[15]。
表-6給出了每種NAT的相關比例。第二列是我們測試了的16個NAT中按照特定類型歸類的NAT個數。其中大部分是NB:Independent。唯一的一個NB:ConnectionR是OpenBSD中pf工具中實現的NAT。我們也發現我們的固件版本為5.13的Netgear RP614是NB:Connection1，而最近的NetgearNAT，如固件為5.3_05的MR814V2，則是NB:Independent。第三列則是估計的實驗室之外的NAT行為。估計值是根據87個家用NAT樣本按照各自的類型和品牌的比例進行計算的，并按照一個修正因子進行了縮放，以此來避免我們所選樣本的偏見。每個品牌的修正因子都是表-3中的調查與觀察的市場份額的比率。該修正因子用來增加評估結果中表現不好的貢獻，降低表現太好的貢獻。雖然我們的評估很好的反映了我們所期望的趨勢，但我們也明白，在如今每年47%的工業變化率下，任何結果的正確性都不會持續太久。不過，我們評估出多數（70.1%）的NAT是NB:Independent類型的，幾乎沒有NB:ConnectionR類型的NAT。很大比例（29.9%）的NAT有對稱行為，因此，更多的情況下，從同一個端口發出的多個連接將不被分配到相同的映射，所以，應用不得不使用后面描述的更成熟的端口預測技術。
4.2 終點過濾
NAT和防火墻都可能過濾尋址到某個端口的進入包，除非（這些包）滿足一定的條件。如果那個端口上不存在NAT映射，NAT就會強制過濾掉包，所以，它就不能再前進。然而，如果映射已經存在，或者設備是防火墻的話，那就可能需要進入包的源地址和（或）端口與之前的外出包的目的地匹配。這些觸發過濾條件的不同，是通過終點過濾分類捕捉的。STUNT的測試client通過連接（STUNT）server而首先設置NAT狀態來決定（是否過濾進入包）的，然后再請求server從不同的地址和端口向已經映射好的地址和端口發起連接（請求），如圖-4所示。
根據該測試所觀察到的不同過濾行為如表-7所示。Nat1’接受所有三個SYN包。這種NAT允許進入的TCP連接與源地址和端口無關，只要路由該請求的必要狀態存在即可。我們把這種NAT分類為有終點過濾行為，即EF:Independent。Nat2過濾所有進入包，因此需要進入的TCP報的源與創建映射的（TCP）連接的目的地址和端口都匹配。這種NAT的終點過濾被分類為EF:Address and Port。Nat3’和Nat4’允許與該連接目的地有相同地址或端口的包進入，但各自會過濾從不同地址或不同端口來的包。我們把這種終點過濾分別分類為EF:Address和EF:Port。我們發現，通常情況下，一個NAT的終點過濾行為與NAT的映射行為無關。參考文獻[15]中定義的cone NAT的子類轉換為如下：full cone就等于NB:Independent和EF:Independent；restricted cone對應于NB:Independent和EF:Address；port restricted cone與NB:Independent和EF:Port對應。
Table 7:NAT endpoint filtering behavior observed. Nat10–Nat40 show 4 different filtering behaviors that are observed or inbound SYN packets after an internal host establishes a connection from a:p to B:Q with allocated mapping A:P
表-8列出了實驗室中16個NAT的終點過濾分類和估計的實驗室之外NAT的百分比。估計是基于前面所述的市場調查來計算的。81.9%的NAT估計是EF:Address和EF:Port，而只有5.8%的是EF:Independent。這表明，大多數情況下，若要兩臺NAT之后的主機要建立連接的話，外發的SYN必須在進入包被接收前從每個終端發出。
4.2.1 TCP狀態追蹤
NAT實現一個狀態機來追蹤終端的TCP進展，并決定連接狀態何時可以回收。雖然所有的NAT都能正確地處理TCP的三次握手，但并不是所有的NAT都正確地實現了TCP狀態機的特殊情況，因而導致提前終止連接狀態。通過為這些方法重復（發送）觀察到的包順序，STUNT的client和server測試了NAT/防火墻的實現如何影響TCP穿透NAT的方法。
表-9列出了部分測試的包順序。我們估計，13.6%的NAT不支持TCP同時打開，即通過一個進入的SYN緊跟在一個外出的SYN之后。這就影響P2PNAT方法，因為該方法需要至少一個終端要像第二種STUNT方法那樣支持同時打開（TCP）。6.9%的（NAT）會在ICMP TTL短暫的超時錯誤后就過濾掉進入的SYNACK包。與此差不多數量的NAT會在ICMP之后丟棄進入的SYN，但如果沒有錯誤，則會接受該SYN。這種行為影響所有要設置SYN包低TTL的方法。大部分NAT（28.1%）接受進入的SYN包，即使創建連接狀態的SYN包遇到了嚴重的TCP RST（錯誤），這就減輕了欺騙RST的問題，盡管有些方法可對付欺騙RST問題。表中沒有提到的是NATBlaster方法中需要的SYN-out和SYNACK-out的順序。由于Windows XP SP2引入的限制，我們沒有全面的測試這種情況，然而，在實驗室，我們發現D-Link NAT（DI-604）就不支持它（SYN-out和SYNACK-out順序）。
4.2.2 過濾應答
當一個進入包被NAT過濾后，NAT可以選擇只是安靜的丟棄該包，或者通知發送者。據估計，約91.8%的NAT只是簡單地丟棄這些包，而沒有任何通知。其余的NAT會為冒犯的包發送回一個TCP RST確認的錯誤信號。
4.3 包破壞
NAT改變外發包的源地址和端口以及進入包的目標地址和端口，而且，他們需要轉換出ICMP有效負載中封裝報的地址和端口，從而終端能夠使ICMP與他們各自的傳輸套接字匹配。我們的樣本集合中的所有NAT，要么正確地轉換ICMP，要么過濾ICMP包，這些被過濾的ICMP包并不總是首先產生。一些NAT通過給外發包的序號加一個恒定的偏移值、給進入包的確認序號減去相同的偏移值來改變TCP序號。我們估計，約8.4%的NAT改變TCP序號。因此，有些情況下，那些需要離開NAT的包有初始序號的TCP穿透NAT的方法不能使用該終端SYN的序號來替代。
4.4 TCP定時器
NAT和防火墻不能隨便控制狀態，因為這樣使他們很容易受到DoS攻擊。相反，他們終止空閑連接，并刪除崩潰或行為不軌終點的連接狀態。而且，他們監控TCP標記，從由于FIN/FINACK交換或RST包而明確關閉的連接中恢復狀態。他們可能允許一些過渡時間來使那些已經在傳輸中的包以及重傳被傳送。一旦連接狀態不能被分配，任何基于該連接的后續達到的包都會被過濾掉。通常，NATs為這些情況使用不同的定時器，如圖-5所示。在圖中位置1和位置3處，使用一個短的定時器，分別用來終止還沒有建立的連接或已經被關閉的連接。RFC1122規定，為了傳遞那些已經在傳輸中的包，終端機要等待4分鐘（即2倍的MSL5），然而，大部分操作系統都只等待約1分鐘。在圖-5的位置2處，為已經建立的空閑連接，NAT使用一個常定時器，RFC1122中對應的規定是，在空閑連接上（兩次）發送TCP-Keeplive包之間，TCP協議棧最少應該等待2小時。
STUNT測試client檢測了NAT定時器的實際情況與RFC規范的符合性。通過三個定時測試來分別檢測每種情況。在第一個測試中，由client發起連接，但從server發出的SYNACK被延遲幾分鐘；第二個測試中，連接被建立后，空閑2小時，這時再從對面的server發送幾個字節；在第三個測試中，連接建立，然后被關閉，但最后從server發出的ACK被延遲約一分鐘。在各種情況下，如果引入延遲后，從server發出的包仍被傳遞到client，那對應的定時器就被稱為保守派；相反就被稱為激進派。我們估計，所有三種情況中，只有27.3%的NAT有保守定時器，而第二種情況則有35.8%的NAT有保守定時器。第二種情況，21.8%的NAT有非常激進的定時器，不活動時間不到15分鐘，他們就終止已經建立的連接。這說明，應用不應該依靠空閑連接到維持（連接）打開太久（超過幾分鐘）。
5 端口預測
端口預測允許一臺主機在連接被創建之前預測該連接被映射的地址和端口。因此，它（端口預測）允許兩臺主機與彼此的映射地址和端口發起連接，即使映射是在連接發起之后分配的。圖-6顯示了使用端口預測信息實現的一個典型的TCP穿透NAT的嘗試。圖中，我們假設A已經決定了它正使用的NAT類型。當clientA希望與clientB建立一個連接的話，A首先與STUNT server建立一個TCP連接，并獲得映射（信息）。根據NAT M的NB類型，A預測出下一個連接的映射。B也作同樣的事（連接STUNT server并預測出下一連接的映射），且A和B通過這種非直接的通道交換他們的預測信息。每個終端通過發送一個SYN包發起一個與對方映射地址和端口的連接。其余被交換的包設計為使兩個TCP嘗試協調為一個連接，如第二節描述的那樣，不同的穿透方法，交換包的設計也各有不同。第一個SYN與目標連接的SYN之間的空隙可能是一個攻擊點，這依賴于NAT M的類型。對于有些類型的NAT來說，如果NAT M后面的另一個內部主機A’在該空隙間發起另一個連接的話，M將會把A預測的映射分配給A’發起的連接。
端口預測依賴于前面4.1節所探討NAT映射類型。如果NAT是NB:Independent類型，那之后從相同源地址和端口發起的任何連接將會重用連接STUNT server的映射。因此，映射重用完全在client的控制之下，這種情況下，攻擊點也就不存在了。然而，這種方法引入了一個潛在的問題，那就是在映射能夠被預測之前，可能需要兩倍的到STUNT server的RTT6。可能的優化是，我們注意到，大多數NAT通常分配一個與client所用的源端口相同的映射端口。我們稱這些NAT為端口保留（型NAT）。處在這種NAT之后的client，即使沒有首先與STUNT server建立連接，也能預測出被映射的端口，且有很高的概率。如果NAT不是NB:Independent類型，但有固定的δ，那么，與（STUNT）server連接之后立即發起的連接，將會有一個映射端口，該映射端口比server觀察到的映射端口大δ。由于從連接到連接映射的變化，攻擊點中的“流氓”連接的嘗試能夠竊取到該映射。而且，如果被預測的映射已經被使用，這種方法會失敗，從而導致NAT的分配規則跳過它而直接到下一個有效的映射。
在STUNT測試client中，我們實現了端口預測，且在一小時內預測了83個家庭用戶的映射。每分鐘，測試client從一個源地址和端口發起一個到STUNT server的連接；然后，再用相同的源地址和端口向為該實驗目的而安裝的一臺遠程主機發起一個連接。測試client檢查基于第一個連接映射所預測的映射與相對應的第二個連接實際觀察到的映射（是否匹配）和NAT類型。如果，且只要他們匹配，端口預測就成功。當用戶正常使用他們的主機和網絡過程中，端口預測才被執行（才會激活（用的上）端口預測），這（正常使用主機和網絡）包括web瀏覽器、email閱讀器、即時消息以及在client主機和處在相同NAT后面的其他主機上運行的文件共享應用。88.9%的NB:Independent類型的NAT是端口保留的。這就說明對實現上述優化的交互應用來說是很有好處的。我們發現，81.9%的情況下，端口每次都被準確的預測，這包括所有的NB:Independent類型的NAT和37.5%的非NB:Independent類型的NAT，只有一種NB:Independent類型的NAT除外。對于剩下的其余62.5%的各種NAT來說，60個其他主機或應用中最少就有一個“竊取”了測試client自身預測的映射。其中一個特例中，處在NB:Connection1類型NAT后面的client主機被感染了病毒，病毒每秒鐘產生多個隨機地址的SYN包，從而導致所有的預測失敗。另一個情況是，中途用戶通過該測試發起一個VPN連接，導致所有后續的請求都被經過VPN發送，因而也就通過一個不同類型的NAT。這說明，長時間運行的應用可能會緩存一段時間的NAT映射類型，但必須及時更新使其有效。考慮所有情況的話，94.0%，也就是超過四分之三的端口預測是正確的。因此，一次嘗試失敗之后，如果應用簡單地再嘗試連接的話，很可能就成功了。
5.1 問題
端口預測有幾個特殊例外的情況，在這些特殊情況下，端口預測可能失敗。圖-7中，當A嘗試與C建立一個連接的時候，如果用STUNT server T來預測地址和端口的話，那A將會因獲得NAT M的外部地址而不是NAT O的外部地址而告終。端口預測要求，client與STUNT server之間的（連接）線路與client和他所希望連接主機的大部分外部NAT之間的（連接）線路相同。因此，由于某些原因，為了連接C，A需要找到S。然而，如果A希望與B通信的話，且A和B都使用STUNT server S，那他們的端口預測嘗試可能相互干擾，從而妨礙任何一方正確地預測端口。而且，即使端口預測正確，A和B也將由于使用O的外部地址而終止（連接）。這種情況被稱為hairpin translation，因為從A發向B的預測地址和端口（這里是O的地址）的SYN將被傳遞到O，而O則需要把它（A發出的SYN）通過一個內部接口發送回去。不是所有的NAT都能正確處理hairpin translation，根據STUNT測試client所進行的測試，我們估計，這種錯誤行為高達72.8%。
前面描述的端口預測技術不能處理NB:ConnectionR類型的NAT，這是由于連續的連接會被隨機分配。參考文獻[3]中提出了一種有趣的技術來處理這種情況，即在沖突發生前使用“生日悖論”來減少猜測的次數。該技術初始化439個連接，這樣，被猜測的端口將有95%的可能性與其中的一個匹配。不幸的是，我們發現，有些NAT，如Netgear，限制掛起連接嘗試的總數為1000，這就造成這種方法很快塞死NAT。幸運的是，幾乎沒有NAT證明NB:ConnectionR行為減輕（緩解）這個問題。
6 TCP建立
這一節，通過測試小范圍P2P的TCP建立，我們估計各種NAT穿透方法的成功（幾率），也給出我的經過。TCP穿透NAT方法的成功，依賴于兩臺終端機之間所有NAT的行為，也依賴于這些NAT后面其他主機的活動。第四節分析了相對獨立情況下的各種NAT，而第五節則分析了競爭網絡活動以及對端口預測的影響。結合這兩節的結果，我們可以從數量上估計出每種NAT穿透方法的成功（幾率）。關于TCP穿透方法的部署，我們作了如下的假設。我們假設STUNT server部署的足夠廣泛，可以確保每一對client都有一個STUNT server滿足端口預測的要求，也能都欺騙從每個client的映射地址和端口出現的包。我們假設終端機的堆棧固定，因此終端上所有軟件問題可以解決。最后，由于我們缺乏數據來模擬5.1節所呈現的情況，我們假設這種情況的貢獻可以或略不計。作為這些假設的結果，我們的估計可能比較理想。
P2P的TCP建立依賴與兩個終端的NAT。如果另一個（對方）終端的NAT可以預測，那一個不可預測NAT后面的終端仍能夠建立一個連接；但如果另一個終端的NAT也不可預測，那就不能建立起連接。通過考慮實際觀察到的所有NAT行為，我們評估了廣泛的TCP連通性。圖-8繪制出了各種TCP穿透NAT方法的成功率圖。我們繪制兩種STUNT方法（#1和#2），即參考文獻[9、3、6]中提出的NATBlaster和P2PNAT的圖示。而且，我們還繪制了STUNT#1和#2（方法）修改版的圖示以及未使用低TTL的NATBlaster方法的圖示。我們還繪制了使用端口預測的修改版P2PNAT方法的圖示。這些（穿透）方法中，有些方法中的SYN包之間存在競爭條件，從而導致某些特定的NAT之間的欺騙包。淺灰色的柱表示當每個終端都有均等的機會贏得競爭情況下發送的成功率，這與終端雙方同時調用方法相對應。深灰色的柱表示，當為了有利于成功連接而打破這種競爭時的成功率，這與雙方各自調用（先后，也就是不同時）方法的情況對應，對于第一個調用，一個終端比對方稍微早一點點發起（連接），而對于第二個調用，則順序剛好與此相反。在建立TCP連接中，只要任何一方的調用成功，該嘗試（連接）就宣布成功。
如圖所示，原來所提出的方法中，P2PNAT和STUNT#1的成功率分別是44.6%和73.4%。通過每個終端再多嘗試一次來打破競爭條件后，原來的STUNT#2方法把其成功率提升到了86.0%。與此類似，給P2PNAT方法增加端口預測，允許他處理對稱NAT后，它的成功率增加到84.3%。令人驚訝的是，通過修改原來的方法，不使用低TTL，所有的方法都獲益超過5%！打破競爭條件，因此獲得的收益就是兩種修改后的STUNT方法高達89.1%和88.7%的最好成功率，以及修改NATBlaster方法后85.2%的成功率。
不使用低TTL的SYN所獲得的意外好處，可以這樣解釋。大部分NAT安靜的丟棄掉第一個SYN包（4.2.2節），只有一少部分NAT過濾外發SYN包后（緊跟）的進入的SYN包（表-9）。因此，多數情況下，修改后的方法觸發TCP同時打開，即使他們并不想這樣（同時打開TCP）。相對于向產生TCP RST應答NAT所付出的懲罰來說，成功地TCP同時開發的賠償更大。如果更多的NAT應答TCP RST包或者終端主機的操作系統不支持TCP同時打開的話，這種好處則被完全抹殺了。
6.1 實現
我們在一個P2P程序中用C實現了上述（穿透）方法。該程序運行在圖-9所示的12個局域網連接的windows客戶端上以及廣域網連接的20個客戶端中的大部分上。每個客戶端隨機挑選另一個客戶端，并與其嘗試建立TCP連接。所有的方法按照宣稱工作（處理），只是不再討論不用低TTL的STUNT#2和使用端口預測的P2PNAT。這是因為，我們發現STUNT#1和NATBlaster方法大范圍廣泛的部署是不切實際的，STUNT#1方法需要欺騙任意包的server廣泛部署，而NATBlaster方法所需要的RAW套接字功能由于安全關系而在WindowsXP中被移除。
圖-10顯示了各種方法建立連接和在低延遲網絡情況下報告失敗所用時間的半對數圖。成功連接的時間分布（圖示中的x軸），P2PNAT方法中變化很大，而第二種STUNT方法則非常平和（一致）。這是因為P2PNAT方法重復發起連接直到其中一次成功或者出現超時，而第二種STUNT方法只發起一個連接。從圖-10中的a圖來看，大部分的連接是不成功的，直到21秒進入的連接嘗試（才成功），因而為了取得先前測定的評估的成功率，需要（花費）大量超時時間。個別情況下，當端口預測失敗且peer的NAT應答TCP RST包時，這種大量超時的危險副作用就顯現出來了。由于終端機重復地嘗試連接直到超時時間結束，這就導致P2PNAT方法產生SYN泛濫。誠然，這個問題在原本的P2PNAT方法中是不存在的，因為它不提倡端口預測。
總的來說，我們發現，基于協議的TCP大部分情況下能夠穿透NAT。應用程序必須通過端口預測來處理（解決）“delta”（“δ”）類型NAT，而且，當NAT上有足夠的安全限制時，也必須使用帶外信號來建立連接。延遲不敏感的應用程序，在放棄前，任何一方也都必須嘗試連接兩次（多次）。此外，應用軟件不必依賴NAT保留空閑連接太久的時間，也不應該期望端到端的TCP序號一成不變。盡管，某些特定情況下，所有的TCP穿透NAT方法都不十分完美，但在當前的互聯網中用于建立P2P的TCP連接中，第二種STUNT方法是最好的（魯棒），它88%的情況都是成功的，而且不需要欺騙、RAW套接字或其它超級特權。它使用傳統的TCP協議棧，傳統的協議棧不支持TCP同時打開，然而，利用現代操作系統中的這種好處，它在許多通常情況下提供了100%的成功。最后，我們發現，它也是所有方法中實現最簡單的，而且在Linux下和Windows下都能工作。我們鼓勵應用軟件開發者們，在他們現在還不能在NAT后的peer之間建立TCP的P2P應用軟件中采用這種方法來提供TCP穿透NAT（功能）。
7 相關工作
從Dan Kegel在上世紀90年代后期第一次提出用于P2P游戲的UDP穿透NAT以來，NAT穿透長久以來一直是人們的夢想。他的基本方法被當作標準，并發表在參考文獻[15]中。UDP（穿透NAT）方法在幾個現行的文檔和互聯網草稿中已經有結果（也就是成熟的方法），這些文檔和互聯網草稿把NAT對UDP的行為進行了分類，并計劃把它標準化。不顯式控制NAT的TCP穿透NAT領域，才剛剛起步。本文已經分析了一些方法，也證明了這些方法在當前的互聯網中穿透NAT（的可行性）。參考文獻[6]中包括了類似的研究，作者測試了許多NAT對UDP和TCP穿透NAT特點的一小部分（子集）。我們提出了NAT行為和P2P的TCP建立（連接）的第一個全面研究，為在大范圍商業NAT產品上的TCP穿透NAT技術提供了全面的集合（整理/匯總）。
像UPnP和MIDCOM這樣的協議，為了便于P2P連接，他們允許終端應用軟件顯式的控制NAT。這種類型方法之所以呈下降趨勢，是因為它們需要NAT中存在并支持這些協議。應用軟件開發者們不能夠依賴這些，因此，暫時這些方法不是最好的選擇。
另一個處理TCP連接的方法是TURN[14]，TURN方法中，TCP數據通過第三方代理（中轉），因而，第三方代理具有潛在的網絡瓶頸。通過在UDP上開通IPV6通道的方式，Teredo[14]（方法）允許IPV6包穿透IPV4的NAT。這里，TCP原本就處在IPV6之上。Windows操作系統中已經實現了Teredo。
8 結論及將來的工作
本文第一次對NAT關于TCP方面對特點進行了全面的測評研究。盡管該研究表明TCP穿透當前NAT還有很多問題，不過它還是給了我很多值得高興的（樂觀的）。盡管存在NAT，而這些NAT當初設計時并未考慮過TCP穿透NAT，但我們還是能夠看到，自然環境條件下TCP連接建立的成功率平均達88%，一些普通類型NAT的成功率高達100%。這些數字特別鼓勵一個假設：很多年前可以普遍地假設TCP穿透NAT是不可能的。盡管對許多應用軟件來說，11%的失敗率是不可接受的，但這些應用軟件的用戶至少有選擇，可以選擇買一個支持TCP穿透的NAT設備，NAT提供商也有選擇，可以選擇把他們的NAT設備設計的對TCP更友好。
該研究在某些方面還是有限的（不全面不完整）。第一，我們沒有測試所有現存的NAT設備。我們研究中大部分有效的NAT被限制在北美地區。第二，我測試的范圍太小，也因此在準確預測廣泛的成功率方面是存在偏差的。盡管可以使用市場數據協助，但這些數據在范圍和詳細程度上也是有限的。第三，我們只測試了家用NAT。企業網絡中，“delta”（“δ”）型NAT的端口預測成功率通常更低一些，而這些對測評原本會更有幫助。第四，盡管TCP穿透NAT技術被廣泛地用于（穿透）防火墻，但我們并沒有測試NAT環境之外的防火墻。我們也沒有測試IPV4到IPV6的轉換網關。最后，與其他測評研究類似，這（研究）只是當前的現狀。毫無疑問，在本項目進行過程中，同類NAT的新版本已經展現出與之前版本不同的行為。展望未來，我們希望，我們的TCP穿透NAT測試套件能夠繼續被用來拓寬我們對NAT和防火墻特性的認識，也能夠繼續跟得上NAT產品及其部署的趨勢。
9 感謝
作者非常感謝Bryan Ford、Andrew Biggadile以及那些匿名的IMC評論家，因為他們為本文初稿反饋的珍貴的意見。我們也感謝Synergy Research Group,Inc.提供了及時的市場調查數據。最后，我們感謝許許多多的志愿者，他們在自己的系統上運行了STUNT測試client和P2P的TCP測試，并反饋了結果。
10 參考文獻
[1] AUDET, F., AND JENNINGS, C. Internet draft: Nat behavioral requirements for unicast udp, July 2005. Work in progress.
[2] BASET, S. A., AND SCHULZRINNE, H. An Analysis of the Skype Peer-to-Peer Internet Telephony Protocol. Tech. Rep. CUCS-039-04, Columbia University, New York, NY, Sept. 2004.
[3] BIGGADIKE, A., FERULLO, D., WILSON, G., AND PERRIG, A.NATBLASTER: Establishing TCP connections between hosts behind NATs. In Proceedings of ACM SIGCOMM ASIA Workshop
(Beijing, China, Apr. 2005).
[4] BRADEN, R. RFC 1122: Requirements for Internet Hosts – Communication Layers, Oct. 1989.
[5] EPPINGER, J. L. TCP Connections for P2P Apps: A Software Approach to Solving the NAT Problem. Tech. Rep. CMU-ISRI-05-104, Carnegie Mellon University, Pittsburgh, PA, Jan. 2005.
[6] FORD, B., SRISURESH, P., AND KEGEL, D. Peer-to-peer communication across network address translators. In Proceedings of the 2005 USENIX Annual Technical Conference (Anaheim, CA, Apr. 2005).
[7] GUHA, S. STUNT - Simple Traversal of UDP Through NATs and TCP too. Work in progress. [online] http://nutss.gforge.cis.cornell.edu/pub/draft-guha-STUNT-00.txt.
[8] GUHA, S. STUNT Test Results. [online] http://nutss.gforge.cis.cornell.edu/stunt-results.php.
[9] GUHA, S., TAKEDA, Y., AND FRANCIS, P. NUTSS: A SIP-based Approach to UDP and TCP Network Connectivity. In Proceedings of SIGCOMM’04 Workshops (Portland, OR, Aug. 2004), pp. 43–48.
[10] HUITEMA, C. Internet draft: Teredo: Tunneling ipv6 over udp through nats, Apr. 2005. Work in progress.
[11] JENNINGS, C. Internet draft: Nat classification test results, Feb.2005. Work in progress.
[12] MICROSOFT CORPORATION. UPnP – Universal Plug and Play Internet Gateway Device v1.01, Nov. 2001.
[13] POSTEL, J. RFC 761: DoD standard Transmission Control Protocol,Jan. 1980.
[14] ROSENBERG, J., MAHY, R., AND HUITEMA, C. Internet draft:TURN – Traversal Using Relay NAT, Feb. 2004. Work in progress.
[15] ROSENBERG, J., WEINBERGER, J., HUITEMA, C., AND MAHY, R. RFC 3489: STUN – Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs), Mar. 2003.
[16] STIEMERLING, M., QUITTEK, J., AND TAYLOR, T. MIDCOM Protocol Semantics, June 2004. Work in progress.
[17] TAKEDA, Y. Internet draft: Symmetric NAT Traversal using STUN, June 2003. Work in progress.
[18] VANCE, A., Ed. Q1 2005 Worldwide WLAN Market Shares. Synergy Research Group, Inc., Scottsdale, AZ, May 2005, p. 40.
注釋：
1處在NAT或防火墻后面的網絡（Network behind a NAT or firewall）
2整篇文章中，NAT術語理解為包括防火墻（Throughout this paper, the term NAT is understood to include firewalls）
3有時指雙層NAT（sometimes referred to as dual or double NAT）
4IP中存活時間字段（IP time-to-live field）
5最大段長（Maximum Segment Length）
6來回時間（Round-trip time）
如何使tcp包和udp包穿透防火墻
通過本文的httptunnel 技術同時逃過了防火墻的屏蔽以及系統的追蹤試驗，我們可以看到網絡安全僅僅依靠某種或某幾種手段是不可靠的，同時對安全系統的盲目性依賴往往會造成巨大的安全隱患。希望通過本文能引起管理員對網絡安全防護系統的思考。
什么是http暗藏通道
什么是局域網安全，系統管理員怎樣才能保障局域網的安全？這是一個不斷變化的安全概念，很長的一個時期以來，在局域網與外界互聯處放置一個防火墻，嚴格控制開放的端口，就能在很大程度上掌握安全的主動權，方便的控制網內外用戶所能使用的服務。比如，在防火墻上僅僅開放80，53兩個端口，那么無論是內部還是外面的惡意人士都將無法使用一些已經證明比較危險的服務。
但要注意一點，防火墻在某種意義上是很愚蠢的，管理員對防火墻的過分依賴以及從而產生的懈怠情緒將不可避免的形成安全上的重大隱患，作為一個證明，"通道"技術就是一個很好的例子，這也是本文要討論的。
那么什么是通道呢？這里所謂的通道，是指一種繞過防火墻端口屏蔽的通訊方式。防火墻兩端的數據包封裝在防火墻所允許通過的數據包類型或是端口上，然后穿過防火墻與對端通訊，當封裝的數據包到達目的地時，再將數據包還原，并將還原后的數據包交送到相應的服務上。舉例如下：
A主機系統在防火墻之后，受防火墻保護，防火墻配置的訪問控制原則是只允許80端口的數據進出，B主機系統在防火墻之外，是開放的。現在假設需要從A系統Telnet到B系統上去，怎么辦？使用正常的telnet肯定是不可能了，但我們知道可用的只有80端口，那么這個時候使用Httptunnel通道，就是一個好的辦法，思路如下：
在A機器上起一個tunnel的client端，讓它偵聽本機的一個不被使用的任意指定端口，如1234，同時將來自1234端口上的數據指引到遠端（B機）的80端口上（注意，是80端口，防火墻允許通過），然后在B機上起一個server，同樣掛接在80端口上，同時指引80端口的來自client的轉發到本機的telnet服務端口23，這樣就ok了。現在在A機上telnet本機端口1234，根據剛才的設置數據包會被轉發到目標端口為80的B機，因為防火墻允許通過80端口的數據，因此數據包暢通的穿過防火墻，到達B機。此時B機在80端口偵聽的進程收到來自A的數據包，會將數據包還原，再交還給telnet進程。當數據包需要由B到A返回時，將由80端口再回送，同樣可以順利的通過防火墻。
實際上tunnel概念已經產生很久了，而且很有可能讀者使用過類似的技術，比如下面的網址http://www.http-tunnel.com。它是一個專業提供tunnel服務的公司，通過他們的在線tunnel server,局域網內的用戶可以使用被防火墻所屏蔽的ICQ，E-MAIL，pcanywhere，AIM，MSN，Yahoo，Morpheus，Napster等等諸多軟件。我們看到，這里有ICQ,Napster等軟件，相信我們的讀者很多都使用過走proxy的ICQ,OICQ等等，其實他們的原理是差不多的。
什么是Httptunnel
作為一個實際的例子，我們下面來介紹一個在"非公開領域"使用的的通道軟件，httptunnel。在httptunnel主頁（請參閱參考資料）上有這么一端話，
httptunnel creates a bidirectional virtual data connection tunnelled in HTTP requests. The HTTP requests can be sent via an HTTP proxy if so desired.
This can be useful for users behind restrictive firewalls. If WWW access is allowed through a HTTP proxy, it's possible to use httptunnel and, say, telnet or PPP to connect to a computer outside the firewall.
從這段說明中我們可以看出來它就是我們今天說要介紹的tunnel技術的一個證明，我們下面大致介紹一下它的使用。
httptunnel目前比較穩定的版本是3.0.5, 支持各種常見的unix系統，包括window平臺。可以從相關站點（請參閱參考資料）下載，它的安裝是比較簡單的，照INSTALL文件做就可以了，這里不介紹。
整個軟件安裝完畢后，我們會得到兩個關鍵文件，htc和hts,其中htc是客戶端（c），而hts是server(s)端，我們來看看具體怎么使用的。
假設有A（域名client.yiming.com)機，B(域名server.yiming.com)機，兩機均為solaris環境，A機在防火墻保護中，B機在防火墻以外，防火墻的管理員控制了訪問規則，僅ALLOW 80和53端口的進出數據包。而我們的任務是要利用Httptunnel從A機telnet到B機上，穿過防火墻的限制。操作如下：
首先我們在A上啟動client端，命令很簡單：
client.yiming.com#htc -F 1234 server.yiming.com:80，
系統回到提示符下，此刻我們用netstat -an 可以看到系統內多出了1234端口的偵聽*.1234 *.* 0 0 0 0 LISTEN
然后我們在B機上啟動server端，命令如下：
server.yiming.com#hts -F localhost:23 80
系統回到提示符下，此刻我們用netstat看*.80 *.* 0 0 0 0 LISTEN
80端口處于偵聽狀態，需要注意的是，如果系統本身跑的有web服務（80端口本身處于偵聽），并不會影響Httptunnel的工作。
Ok,server以及client端都啟動了，我們可以開始我們的"通道"試驗了，在client.yiming.com上執行一下如下命令看看：
Client.yiming.com#telnet localhost 1234
Trying 0.0.0.0...
Connected to 0.
Escape character is '^]'.
SunOS 5.7
This is yiming's private box! Any question,contact me with yiming@security.zz.ha.cn
login:
看到B機的登錄提示符了,輸入賬號密碼看看是否工作正常？
Login:yiming
Password: (omit here;) )
sever.yiming.com# ls
bak check go httpd lost+found mrtg run soft wg
OK! 工作正常，和正常的telnet沒有什么差別。
仔細觀察整個過程，會發現在最開始的地方顯示的是Trying 0.0.0.0...，Connected to 0.而不是Trying server.yiming.com…,Connect to server.yiming.com，這就很直觀的可以看出來client端是轉發1234數據包到本機80端口的。（然后再轉發到遠端）而不是直接連接遠端的B機。
上面是比較直觀的測試，為了進一步驗證server和client之間不是通過23端口通訊，我們抓取數據包來看看。我們在server起個抓包工具tcpdump（請參閱參考資料）瞧瞧。
server.yiming.com#tcpdump host client.yiming.com
tcpdump: listening on hme0
14:42:54.213699 client.yiming.com.51767 > server.yiming.com.80: S 1237977857:1237977857(0) win 8760 (DF)
14:42:54.213767server.yiming.com.80 > client.yiming.com.51767: S 1607785698:1607785698(0) ack 1237977858 win 8760 (DF)
14:42:54.216186 client.yiming.com.51768 > server.yiming.com.80: . ack 1 win 8760 (DF)
14:42:54.218661 client.yiming.com.51768 > server.yiming.com.80: P 1:44(43) ack 1 win 8760 (DF)
14:42:54.218728 client.yiming.com.51768 > server.yiming.com.80: P 44:48(4) ack 1 win 8760 (DF)
篇幅所限，上面只是截取了結果中的一點點數據包，但已經可以說明問題了，我們看到server和client之間順利的完成了三次握手，然后開始push數據，而且通訊確實走的是80端口。有點意思噢。
看是看出來了，但太不直白，到底在搞什么呀，我們再稍微改動一下tcpdump的運行方式，進一步在來看看telnet的數據是否被封裝在80端口的數據包內傳輸？
server.yiming.com#tcpdump -X host client.yiming.com
14:43:05.246911 server.yiming.com.80 > client.yiming.com.51768: . 2997:4457(1460) ack 89 win 8760 (DF)
0x0000 4500 05dc 3b23 4000 ff06 e2c2 yyyy yyyy E...;#@......f.D
0x0010 xxxx xxxx 0050 de42 5fd5 ac4f 39ac 016f .f.#.P.B_..O9..o
0x0020 5010 2238 98e4 0000 746f 7461 6c20 3636 P."8....total.66
0x0030 370d 0a64 7277 7872 2d78 722d 7820 2032 7..drwxr-xr-x..2
0x0040 3920 726f 6f74 2020 2020 2072 6f6f 7420 9.root.....root.
呵呵，這次清楚多了，上面應該是一次ls命令的輸出結果，可以清楚的看到telnet的結果！果然telnet的數據是在80端口的數據包內！
Httptunnel帶來的安全問題
寫到這里，我們可以想象一下，如果管理員完全信賴防火墻，那么在一個有這樣隱患的的局域網中，會發生什么樣的后果？
我們可以看到，多年以來，對防火墻的依賴也一直列在SANS的Top 10安全問題中。
既然如此，就很自然的會產生一個問題是：這種httptunnel行為能被發現嗎？
首先我們想到的是使用入侵檢測系統，在目前的網絡安全設計中，防火墻加入侵檢測系統是一種比較流行的安全聯動配置，既然httptunnel繞過了防火墻，那么IDS系統呢？我們來測測看看。
在下面的測試中，我們將使用IDS系統是Snort，版本1.8.2。（請參閱參考資料）這可是大名鼎鼎的開放源代碼的IDS系統，在它的說明中，被描述為一個輕量級的，可跨平臺工作的入侵檢測系統，在2001年12月英國的獨立測試實驗室NSS的評測中（請參閱參考資料），擊敗了包括商用IDS系統的所有對手，這些商用軟件可是包括ISS，CISCO SECURE IDS，CA ETRUST，CYBERSAFE CENTRAX，NFR。有興趣的讀者還可以看這篇名為Open source mounts IDS challenge 的報道（請參閱參考資料）。
好，對Snort的大致介紹完畢，我們來看看結果吧，Snort對整個試驗過程抓獲的數據包產成了告警，如下：
[**] WEB-MISC whisker splice attack [**]
12/02-14:42:54.389175 client.yiming.com:51767-> server.yiming.com:80
TCP TTL:251 TOS:0x0 ID:3327 IpLen:20 DgmLen:42 DF
***AP*** Seq: 0x49CA0BA7 Ack: 0x5FD4DCE3 Win: 0x2238 TcpLen: 20
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
[**] WEB-MISC whisker splice attack [**]
12/02-14:43:03.195006 client.yiming.com:51767 -> server.yiming.com:80
TCP TTL:251 TOS:0x0 ID:3439 IpLen:20 DgmLen:41 DF
***AP*** Seq: 0x49CA0C20 Ack: 0x5FD4DCE3 Win: 0x2238 TcpLen: 20
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
[**] WEB-MISC whisker splice attack [**]
12/02-14:43:04.630268 client.yiming.com:51768-> server.yiming.com:80
TCP TTL:251 TOS:0x0 ID:3496 IpLen:20 DgmLen:41 DF
***AP*** Seq: 0x49CA0C4E Ack: 0x5FD4DCE3 Win: 0x2238 TcpLen: 20
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
我們看到snort對抓獲的數據包產生了WEB-MISC whisker splice attack的告警，然而這種攻擊并沒有發生，同時snort對tunnel數據包沒有察覺。這樣snort就同時出現了IDS系統的兩個問題，false positive，false negative。
這也很正常，因為這也是基于簽名的IDS系統的通病，目前決大數IDS系統包括著名的商用軟件ISS,NFR等都是基于簽名的，也就是說系統維護著一套特定攻擊數據包的數據模式簽名。系統工作時，檢查經過的數據包的內容，和自己數據庫內數據模式簽名對比，如果和某種攻擊模式簽名相同，那么就判斷發生了某種攻擊。
由此我們可以看出很明顯的存在若干問題：如對簽名的依賴不可避免的導致兩個結果，false negative ,false positive。也就是說會產生漏報和誤報，這一點很容易理解，當新出現一種攻擊模式時，由于IDS系統內沒有相應的數據簽名，那么就不可能捕獲相應的攻擊數據包，false negative由此發生。同時，過于依賴簽名模式也很容易誤報，就象我們上面的例子。同時，對數據簽名的依賴會在一定程度上降低系統性能-經過的數據包都需要和IDS系統的簽名對照。（請參閱參考資料）
此外，基于簽名的IDS系統本身有可能由于依據簽名這一特性而被攻擊，一個例子是stick ，這個程序的作者利用IDS系統進行簽名匹配工作原理，發送大量帶有攻擊特征的數據包給IDS系統，使IDS系統本身處理能力超過極限，從而導致IDS系統無法響應。按照作者Coretez Giovanni的說法
