转发 通过NAT和防火墙特性和TCP穿透的测评（翻译）

转自 http://blog.csdn.net/sjin_1314/article/details/18178329

原文：Characterization and Measurement of TCP Traversal through NATs and Firewalls 原作者：Saikat Guha Paul Francis

[摘要]

    近些年，标准化社区已经开发出一些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   实验装置

 

我们已经定义特技客户端-服务器协议，这两项测试的NAT /防火墙的行为，并建立NAT映射体之间建立TCP连接的助攻。一个完整的协议详细说明请见[ 7 ]。该协议是由我们组成一个客户端组件和服务器组件的测试应用程序中实现。如图  2，在客户端运行在一个或多个NAT的主机上，而服务器是外部给他们。特技测试客户端检测到客户端和服务器之间的所有的NAT和防火墙的复合行为。虽然目前的测试客户端和服务器需要超级用户权限来分析在电线上的原始数据包，要求可以换取一个小的损失在功能上被删除的客户端。服务器，此外，至少需要两个网络接口，在使用不同的NAT端口分配算法之间正确区分。由客户端和NAT的特点从他们推断进行的测试是在后面的部分描述  4。

    我们所使用的客户机来测试的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中。