Characterization and Measurement of TCP Traversal through NATs and Firewalls

文章：Characterization and Measurement of TCP Traversal through NATs and Firewalls

作者：Saikat Guha ，Paul Francis

翻译：黄剑

摘要

近年来，权威机构已经开发出相应的技术来解决UDP穿越NAT/防火墙的问题（即是通过确定主机与NAT设备之间的UDP数据流来实现数据联通）。然而，由于TCP连接与生俱来的不对称性，穿越NAT设备的TCP连接较为困难。研究者最近提出了多种有希望的方法来解决穿越NAT设备的TCP连接问题。然而，种种方法的可行性是建立在NAT设备在处理TCP（ICMP）数据包的多样顺序的反应行为上。本文通过对大范围的商用NAT设备进行初步的行为研究来分析对一系列穿越NAT设备的TCP连接的理解。我们开发出了一种公开的、可用的测试软件来测量多种独立的探测以及完整的TCP连接确认。我们在实验室测试了16种商用NAT设备，同时在室外测试了93种家用NAT设备。通过这些测量结果以及商用NAT设备的市场数据，我们对家用网络的成功的NAT数据穿越的相似性进行了评估。这篇文章中的见解可以用来指导TCP-NAT传输协议的设计以及确定穿透NAT/防火墙的行为，其中包括为实现IPv6的数据传输的关键。

1            导言

NAT设备以及防火墙通过将外部主机与受保护网络内部的主机之间建立连接而打破了IP连接模型。如果两端的节点被各自的NAT/防火墙设备所保护起来，在一端与对方NAT设备之间建立连接之前普通的TCP连接是不能成功的。即使各节点的防火墙安全策略允许连接也是一样。举例而言，内部主机初始化TCP连接，并且双方主机也希望能够建立连接。近来的研究已经提出了不采用代理或是通过[9,5,3,6]隧道来进行TCP连接的任务。通过仔细的TCP数据包转换而在NAT设备上建立了必要的连接状态所完成以上目的。然而，并不是所有的NAT设备都是同样的反应，这就会引起各种方法以多种原因失效。理解NAT设备的这些行为和测量它们转移了多大程度的互联网的通用连接对于将其整合为体系结构是至关重要的。

今天的互联网体系和当初TCP/IP协议设计时所预想的有了巨大的差异。防火墙和NAT设备经常使得它难以建立起链路尽管其不违反相应的策略。举例来说，Alice和Bob通过躲藏在NAT设备后或是配置他们的防火墙丢弃入站的SYN数据包而达到不接受未经允许的连接。但是当双方同意建立连接时，如果他们没有重配置NAT设备而使得Alice的SYN数据包被Bob的NAT设备所丢弃的话，那么他们还是不能建立其连接的。尽管如此，NAT/防火墙设备已经网络设施的一部分同时这会持续很长一段时间。即使IPv6被全球推广了，在演化阶段时，IPv4-IPv6的NAT设备也是需要的，并且IPv6的防火墙也是安全所需。因此，建立同意条件下NAT设备后的双方主机的连接机制是必需的。

针对UDP的情况已经被STUN所解决了。在STUN的解决方案里，Alice发送一个UDP包给Bob。尽管Bob的NAT设备会将其丢弃，但是它使得Alice的NAT设备生成本地状态，其可以使得Bob发送数据直达给Alice。而后Bob发送UDP数据包给Alice。Alice的NAT设备认为它是第一个数据包的一部分并且让它通过，同时Bob的NAT设备认为它是一个连接初始化过程并且在本地状态进行设置以接受Alice的数据包。这种方法被Skype所采用，其是一款流行的VoIP应用程序。不幸的是，进行TCP连接要复杂的多。一旦Alice发送她的SYN数据包，她的操作系统栈以及她的NAT设备就会期待接收到来自Bob的SYNACK数据包。然而，因为SYN数据包被丢弃，Bob的栈没有生成SYNACK数据包。解决该问题的被提议的工作区是复杂的，它们同NAT设备之间的交互很少被理解，并且它们所能解决问题的程度也不能得知。因此，像Skype所采用的文件传输模块之类的应用程序显示了像UDP等协议的不当之处。然而这些方法也可能适用，我们相信无论在什么可能的情况下应用程序采用本地操作系统TCP栈都是重要的。这样就能部分避免增加协议栈的复杂性，更重要的是，TCP栈经过多年已经优化为具有高效能以及拥塞控制。

总体来说，这个工作做出了四个贡献。一，我们鉴别并描述了整个NAT特性，这对于TCP穿透NAT传输的研究是很重要的。二，我们对多种提出的方案进行了测量了它们的特性以及P2P的TCP传输的成功率。三，在这些测量的基础上，我们对提出的方案进行了改进。四，我们提供公共领域的软件工具，它们可以用来测量NAT设备以及作为TCP穿透NAT传输应用的基础。综上所述，我们为应用开发者提供了关于实现复杂性与穿透成功率之间的权衡的见解。最后，我们的研究成果能够用于指导NAT设备以及防火墙的标准过程，使得它们更有利于传输而不需要围绕着安全策略行事。

本文采用以下方式组织。第二章讨论已提出的TCP穿透NAT传输方案。第三章和第四章解释我们对测试及观察NAT设备行为的设置。第五章分析端口预测同时第六章分析了P2P的TCP连接。第七章讨论相关工作。第八章总结本文。

2            TCP穿透NAT的数据传输

本章我们将讨论最近在相关文献上所提出的TCP穿透NAT传输方案。在所有的方案里，双方初始化TCP连接。输出的SYN数据包为自己的NAT设备生成了必需的NAT状态。各种方案通过采用本章介绍的不同的机制调节两种TCP连接尝试顺序。发送源SYN数据包的地址和端口被决定为通过端口预测。端口预测允许一主机猜测NAT设备的信息表，以此在建立连接之前发送SYN数据包，并讨论细节。这些方案同时也要求两主机之间的一些合作。这是通过大量的通道例如第三方形成的连接代理或是一个UDP/STUN会话而完成的。一旦直达的TCP连接建立起来了，那些通道就可以关闭。这调和机制会因为不同的NAT设备触发后的不同反应而导致所提出的方案在实际情况中失效。另外，多宿主后的节点不可能序化。在这种情况下，行为观察就成为了几乎不可或缺的一部分。简单来说，我们应当重新定义名词“NAT”的意义为： NAT/防火墙组合。

2.1   STUNT

 

2.2           NAT Blaster

2.3           Peer-to-Peer NAT

2.4           执行

我们在Linux以及Windows两个平台下执行以上的所有方案。我们也开发了一个Windows设备驱动执行一些所需功能用于支持一些不能直接在Windows下执行的方案。第一类STUNT方案要求在Linux以及Windows平台下具备超级用户权限用于在线监听SYN数据包并识得它的顺序。为了能够设置第一个SYN数据包中的TTL值，我们在Linux下使用IP-TTL Socket选项以及我们在Windows下的驱动。我们同时也执行STUNT服务器并且将其置于一个不用于输出过滤器的ISP后，这样可以用于欺骗任意地址。

我们发现在Windows平台下设置TTL值是有疑问的；因此，我们认为最好不去用它。如果TTL值不会降低，主机之一所发出的第一个SYN数据包会在另一端点的SYN数据包发出之前到达另一端点的NAT设备。NAT设备可以默认地丢弃入站的数据包，同时也可以发送ICMP未到达错误信息或TCP RST/ACK信息来回应。这些反应，如果有的话，可能会因为方案的规则......