原文：Characterization and Measurement of TCP Traversal through NATs and Firewalls 原作者：Saikat Guha Paul Francis
我們已經定義特技客戶端-服務器協議，這兩項測試的NAT /防火牆的行為，並建立NAT映射體之間建立TCP連接的助攻。一個完整的協議詳細說明請見[ 7 ]。該協議是由我們組成一個客戶端組件和服務器組件的測試應用程序中實現。如圖 2，在客戶端運行在一個或多個NAT的主機上，而服務器是外部給他們。特技測試客戶端檢測到客戶端和服務器之間的所有的NAT和防火牆的復合行為。雖然目前的測試客戶端和服務器需要超級用戶權限來分析在電線上的原始數據包，要求可以換取一個小的損失在功能上被刪除的客戶端。服務器，此外，至少需要兩個網絡接口，在使用不同的NAT端口分配算法之間正確區分。由客戶端和NAT的特點從他們推斷進行的測試是在后面的部分描述 4。
[摘要]
近些年，標准化社區已經開發出一些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 實驗裝置
我們所使用的客戶機來測試的16 NAT的一組不同的實驗（表 2）。這些措施包括各品牌的NAT，我們可以找到在網上商店在美國的一個。在NAT之后還測試了包括流行的操作系統軟件的NAT實現。在每個實驗測試客戶端主機是唯一的主機內部的NAT和服務器是在同一個以太網段作為NAT的外部接口。客戶端主機被設置為不生成比所造成的測試客戶端。其他任何網絡流量 除了這些實驗室測試中，我們也是在野外測試NAT設備。主要的原因是我們的測試軟件面臨更廣泛的情況下，比我們能夠復制在實驗室中，從而提高其魯棒性和提高我們的信心，其操作。此外，它還提供了什么類型的NAT，我們可以期望看到在實踐中的一個樣本，雖然小，。在這個測試中，我們要求的家庭用戶來運行測試客戶端。這個測試在康奈爾大學和其他大學正在使用的CS的教師和學生93家的NAT（16個獨特的品牌）。測試流量是除了客戶端的主機和其他主機在NAT后面的典型網絡活動，並包括網頁瀏覽，即時消息，對等文件共享，電子郵件等從NAT的品牌組合所產生的數據與繪制新的和舊的型號和固件，但它承認在給定其中大部分居住在東北美國相對較小的用戶群的NAT的選擇偏差。表這種差異是顯而易見，其中的品牌我們的樣本中觀察到的受歡迎程度列`根據樣品'和品牌在2005年第一季度全球SOHO /家庭WLAN市場份額為每Synergy Research Group的[ 18 ]被列在'市場調查'。特別是，水牛技術和Netgear是我們的樣本中代表性不足和其他品牌的比例顯著較高。可在[測試了家里的NAT的完整列表8 ]。
4 NAT的TCP特性
| 分類 | 值 |
| NAT映射 | 獨立 |
| 地址ð | |
| 端口ð | |
| 地址和端口ð | |
| 連接ð | |
| 端點過濾 | 獨立 |
| 地址 | |
| 端口 | |
| 地址和端口 | |
| 響應 | 降 |
| TCP RST | |
| ICMP | |
| TCP序列＃ | 罐頭 |
| 不保留 | |
| 定時器 | 保守的 |
| 積極的 |
表4：重要類別區分不同的NAT。
這一節，我們確定不同NAT怎樣影響TCP的NAT穿透方法。根據NAT的行為，我們划分了五個類別，即NAT映射、終端包過濾、過濾應答、TCP序號預留和TCP定時器。每個類別的分類和NAT能夠接收到的值之間的關系如表-4所示。我們使用STUNT的測試client和前面第三節中描述的server對實驗室中的16個NAT和世界各地的93個NAT進行了分類。完整的測試結果以及更廣范圍的分類集合在參考文獻[8]中有描述。
4.1 NAT Mapping
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對應。
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 端口預測
端口預測允許主機預測的映射地址和端口用於啟動它之前的連接。因此，它可以讓兩台主機啟動，即使映射是通過NAT的分配與對方的映射地址和端口的連接后，啟動連接。圖 6顯示了使用端口預測信息的典型的TCP NAT穿越的嘗試。在圖中，我們假設一個已經確定的NAT它使用的類型。當客戶端一個希望建立與客戶端的連接乙，一個先建立一個TCP連接到特技服務器和學習的映射。的基礎上，注意：的NAT類型M， 一個預測的映射下一個連接。乙不相同，都一個和B交換他們的預測過度越界的通道。每一端然后啟動到對方的映射地址和端口發送一個SYN包的連接。所交換的數據包的其余部分被設計在兩個TCP試圖調和成一個連接和變化從一個NAT穿透方法的另一個方法見 2。第一個SYN和SYN之間的周期為目標的連接可能是一個 弱點窗口取決於NAT類型M。對於某些類型的NAT，如果另一內部主機A“在NAT后面M開始在此期間出站連接，M將分配由預測的映射一個從連接A'代替。 端口預測依賴於NAT映射類型的較早探索在第 4.1。如果NAT的類型是NB的：獨立則映射為連接到特技服務器將被重用來自同一源地址和端口發起不久之后的任何連接。由於該映射的復用是完全在客戶端的控制下，漏洞窗口在這種情況下不存在。然而，該方法引入了2RTT的延遲7到特技服務器的映射可以預測之前。對於一個可能的優化，我們注意到了一些的NAT通常分配一個映射端口等於客戶端使用的源端口。我們稱這些NAT的端口保護。后面這種NAT客戶端可以，以很高的概率，預測映射端口沒有首先建立與特技服務器的連接。如果NAT是不是注：獨立，但有一個固定的Ð然后與服務器的連接后，立即發起一個連接都會有一個映射端口Ð比映射端口服務器觀察高。由於映射從連接變為連接，在脆弱的窗口``流氓''連接嘗試可以偷的映射。此外，這種方法失敗，如果預測的映射已在使用，造成NAT的配置程序來跳過它到下一個可用的之一。 我們實現端口預測在特技測試客戶端和預測映射83家庭用戶的小時。每一分鍾，測試客戶端發起從源地址和端口特技服務器的連接，並學習分配的映射。接着，它使用相同的源地址和端口發起到遠程主機設置為這個實驗的目的的連接。測試客戶端檢查實際觀察到的對所述一個預測基於映射為所述第二連接的映射在第一和NAT的類型。端口預測是成功的，當且僅當它們相匹配。該預測是執行，而用戶使用他們的主機和網絡正常。這包括Web瀏覽器，電子郵件閱讀器，即時通訊和客戶端主機和其他主機的同一個NAT上運行的文件共享應用程序。88.9％的NB的：獨立的NAT端口被保留。這是一個巨大的勝利為實現上述優化的交互式應用程序。我們發現，在的情況下，81.9％的端口是否正確，每次預測。這包括所有的，但注意之一：獨立NAT和37.5％的非NB的：獨立的NAT。對於后者品種，其余62.5％，至少有一次出了60的另一台主機或應用程序偷走了測試客戶端的預測本身的映射。在一個特定的情況下，后面的NB客戶端主機：連接1的NAT被感染了每秒產生幾個隨機地址的SYN數據包導致所有的預言失敗了病毒！在另一種情況下，用戶通過測試發起VPN連接中途導致所有后續請求將被發送通過VPN，從而通過不同類型的NAT。這表明，長時間運行的應用程序可以緩存的NAT映射類型有一段時間了，但必須不時重新驗證時間。總體而言，在案件94.0％，超過四分之三的端口的預測是正確的。因此，一個失敗的嘗試后，如果一個應用程序簡單地重試連接時，它很可能會成功。
6 TCP建立
在本節中我們估計的各種NAT穿越方法的成功，以及匯報我們的經驗與同行點對點的TCP建立一個小的廣域測試平台。的TCP NAT穿越方法的成功取決於兩個末端主機之間的所有的NAT以及在NAT之后的其他主機的活動的行為。第 4分析了多種的NAT的隔離，同時第 5分析競爭的網絡活動及其對端口預測效果。結合從這些部分的結果，我們可以定量估算出每個NAT穿越方法的成功。 我們做出的TCP遍歷方法的部署以下假設。我們假設特技服務器部署廣泛，足以確保為每一對主機，有滿足端口預測要求，可以欺騙看似來自每台主機的映射地址和端口的數據包特技服務器。我們假設endhost棧可以固定在兩端，因此所有的軟件問題都解決了。最后，由於我們缺乏數據模型中科提出的方案 5.1，我們假設從這些場景的貢獻可以忽略不計。由於這些假設，我們估計可能過於樂觀。對等體的TCP建立依賴於NAT的兩端。有一個不可預知的NAT的一個端點仍然可以建立連接，如果另一個端點的NAT是可以預測的，但不是如果它是不可預測的。我們通過考慮所有對NAT行為在實踐中觀察到估計在野外的TCP連接。圖 8幅不同的TCP穿透NAT的方法估計的成功率。我們繪制所建議的兩種特技方式（＃1和＃2），NATBlaster和P2PNAT [9，3，6 ]。此外，我們繪制的特技＃1和＃2和NATBlaster方法不使用低TTL的修改版本。我們還繪制，使用端口預測的P2PNAT辦法的修改版本。還有就是SYN數據包之間的競爭條件在其中的一些方法，導致虛假數據包的某些NAT對。淺灰色線表示當每一端都有贏得比賽的機會相等的成功率，這相當於該方法的調用同時在兩端。暗灰色條表示的成功率，當比賽有利於成功的連接被打破，這相當於該方法的其中的第一次調用，一端稍開始之前，其他的，而第二次調用兩個獨立的調用，順序是相反的。的嘗試被宣告成功，如果任一調用成功地建立TCP連接。 如圖所示，在曲線圖中，原始的方法提出了分別成功的時間P2PNAT和特技＃1 44.6％和73.4％。從各端一次嘗試它打破了競爭條件在原來的特技＃2的方式提升其成功86.0％。同樣，添加端口預測到P2PNAT方法允許它處理對稱的NAT提高其成功率84.3％。出人意料的是，修改原始的方法，不使用低TTL的福利來，都是按〜5％！因此，打破引進競爭條件得到89.1％的最好的成功率和88.7％的兩種改進特技方式和85.2％的改性NATBlaster方法。 意想不到的好處，不使用低TTL的SYN解釋如下。NAT的很大一部分自動刪除第一個SYN包（第 4.2.2）和出站SYN包（表后的NAT只有一小部分過濾入站SYN包 9）。因此在大量的情況下，修改后的方案最終引發TCP同時打開，即使他們不打算。小懲罰他們付出代價的產生一個TCP RST響應的NAT超過補償由成功的TCP同步打開。這種優勢被侵蝕的路程，如果多個NAT響應的TCP RST包，或者如果endhost的操作系統不支持TCP同時打開。
我們實施一個對等的程序用C語言編寫的程序是運行在連接在一個局域網，如圖12 Windows客戶端上面的方法 9，以及一組20個客戶端連接通過WAN稍大。每個客戶端隨機挑選另一個客戶端，並嘗試建立TCP它。雖然所有的方法工作作為標榜，我們限制這種討論特技＃2不低TTL和P2PNAT與端口預測。這是因為我們發現，特技＃1和NATBlaster辦法一個龐大的全球部署是不切實際的;絕技＃1的方法需要一個廣泛部署的服務器，可以任意欺騙數據包，而NATBlaster方法要求已被刪除以下安全RAW套接字功能關注在Windows XP中。