p2p:TCP穿透NAT防火墙

 

原文：Establishing TCP Connections Between Hosts Behind NATs
http://www.andrew.cmu.edu/user/ggw/natblaster.pdf

NATBLASTER:Establishing TCP Connections Between Hosts Behind NATs

 

Andrew Biggadike, Daniel Ferullo,

Geoff Wilson, Adrian Perrig Information Networking Institute,

Carnegie Mellon University

{biggadike, ferullo, ggw, perrig}@.cmu.edu

August 20, 2004

 

 

不同NAT后的主机间建立TCP连接

 

译（初稿）：dragonimp@fzu 2005-6-14

 

摘要

防火墙和网络地址转换（NAT）设备正变得越来越流行了，同时他们也对使用点对点年协议建立连接造成一个非常大的问题。一些NAT设备抑制了来自外部网络到内部网络的TCP请求。这篇文章的目的是提出一个能够在两个NAT设备内部的主机间建立直接的TCP连接的方法，同时又尽量不依赖于第三方主机。我们已经在两个普通的硬件条件下实现了这个功能。我们能够为两个不同典型的NAT后面的主机建立TCP连接。一旦建立了这个连接，应用程序就可以跟原来的TCP一样调用这个连接，而不需要任何其他的帮助。

第一章        前言

NAT技术的出现从某种意义上解决了IPV4的32位地址不足的问题，它同时也对外隐藏了其内部网络的结构。NAT设备把内部网络跟外部网络隔离开来，并且可以让内部的主机可以使用一个独立的IP地址，并且可以为每个连接动态翻译这些地址。此外，但内部主机跟外部主机通信时，NAT设备必须为它分配一个唯一的端口号并连接到同样的地址和端口（目标主机）。NAT的另一个特性是它只允许从内部发起的连接的请求，它拒绝了所有不是由内部发起的来到外部的连接，因为它根本不知道要把这个连接转发给内部的哪台主机。

P2P网络已经日益流行。尽管p2p文件共享软件引发了很多争夺站，比如nepster 和 kazaa之间，但是还是有很多有用的并且合法的P2P软件存在着，比如即时消息共享和文件共享。另一个P2P程序是一个叫OpenHash的项目，它为公众提供了一个可用的分布式的哈希表，很多应用程序都在它的基础上开发了出来，比如很多的即时通信软件和可靠的CD标签库。

不幸的是，两个处于不同NAT后面的主机无法建立TCP连接因为各自的NAT都只允许外出的连接。NAT销售商在已经为NAT设备开发了端口映射的功能来解决这个问题。NAT管理员可以使用端口映射来为那些需要接受那些不是从内部发起的连接请求的主机指定端口。但是这种解决方法根据情况还需要很多其他的支持。当有的服务器需要动态的分配端口的时候，这种方法就很受限了。再说了，如果一般的用户没有权限或者不懂得如果进入NAT设备为他们指定端口映射，那这种方法就一点用处也没有了。

P2p协议对此已经阐述了记者通用的方法。第一个可被p2p协议使用技术是：那些本来不能当作服务器的程序收到了来自请求者的消息后主动向请求者发起连接。这种情况只适用于只有一方在NAT后面的情况。第二种通用的方法是通过两个主机都可以连接得到得代理路由数据，但是这种方法对于两个NAT后面的主机来说效率太低了，因为所有的数据都必须经过代理。其他相关的技术将在第三部分讨论。

我们努力的目标是找出一个可以让NAT后面的两个主机直接建立TCP连接的解决方案。特别地，我们已经开发出几种方案可以用于那些支持端口分配地NAT和那些支持LSR路由的网络。我们的方法是通过第三方提供建立直接连接需要的信息。根据不同的环境，我们开发了几种不同的方案可以在可以预测和适当的时间的情况下建立连接。这些技巧都需要把数据包的TTL值设置得很小，并且捕捉和分析外传得数据包以提供信息给第三方“媒人”。并且人为地向网络发送一些数据包用来检测NAT所分配地端口。补充一点，如果端口分配是随机地，我们就使用一种叫“birthday paradox”的方法减少检测的次数。这种方法需要的空间是直接的穷举所使用的空间的开方。

第二章        NAT的类型

NAT必须考虑路由器的三个重要的特性：透明的地址分配、透明路由、ICMP包负载解析。地址分配是指在一个网络会话开始的时候为内部不可以路由的地址建立一个到可路由地址的映射。NAT必须为原地址和目标地址都进行这样的地址分配。NAT的地址分配有静态的很动态的方式。静态的地址分配必须预先在NAT中定义好，就比如每个会话都指派一对<内部地址，外部端口>映射到某对<内部地址，内部端口>。相反地，动态的映射在每次会话的时候才定义的，它并不保证以后的每次会话都使用相同的映射。

一个相似的特性NAT必须实现的是透明路由。正如上面提到的，NAT是一种特殊的路由它在它所路由的数据包中翻译地址。这种转换基于数据流来改变相应的IP地址和端口。其次，这种转换必须是设备透明的，这样才保证对现有网络的兼容性。一个不是很明显的要求是，NAT必须保证内部网络的数据包不被发送到外部网络去。

最后一个NAT必须实现的特性是当收到ICMP错误包的时候，NAT使用正常的数据包做出同样的转换。当在网络中发生错误时，比如当TTL过期了，一般地，发送人会收到一个ICMP错误包。ICMP错误包还包含了尝试错误的数据包，这样发送者就可以断定是那个数据包发生了错误。如果这些错误是从NAT外部产生地，在数据包头部的地址将会被NAT分配的外部地址所代替，而不是内部地址。因此，NAT还是有必要跟对ICMP错误一样，对在ICMP错误包中包含的数据包进行一个反向的转换。

虽然所有的NAT都实现了这三个特性，但是根据他们的特点和他们所支持的网络环境，他们还可以进入分类。NAT可以分为四种：Two-way NATs,Twice NATs, Multi-homed NATs, 和 Traditional NATs。Two-way NATs，一般也叫双向NAT（Bidirectional NATs），在外部地址和内部地址间执行双向转换，尽管它个数据包只转换一个IP地址。这种NAT是唯一一种允许从外部发起的连接请求。相反地，Twice NATs，它每路由一个数据包都对内部和外部的地址进行转换。这种NAT用在那些外部地址和内部地址交叠的情况下。Multi-homed NATs对于Twice NATs来说，多了一个功能，它可以允许在内部使用不能路由的地址并且还可以有多个连接到外部网络。之所以Multi-homed NATs能够这样做，是因为它跟另一个保持通信以确定他们的地址映射是不变的。Multi-homed NATs允许大量的内部网络和增加冗余来允许多个连接到Internet。到目前为止，最常用的NAT是传统NAT(Traditional NATs)，它可以分为基础NAT（Basic NATs）和NATP（Network Address Port Translation）两种。

基本NAT和NATP的区别它所能分配给内部地址的外部地址是否比内部地址多。一个Simple NAT用在那种所能分配的外部地址跟内部地址的数量相等或者更多的时候。这种NAT进行端口分配，因为每个内部地址都可以分配到一个唯一的外部地址。NATPS用于当NAT所能用来分配的外部地址的数量比内部地址少的时候，最常见的一种情况是很多的内部机器共享一个外部IP地址。在这种情况下，NAT必须分配端口来补充IP用以消除网络传输的不明确的几乎。NAT和NATP共同的地方就是他们都阻止外来的连接，并且都可以进行静态和动态的地址分配。

NAPT是传统NAT中最普遍的一种，因为它允许很多的内部连接共享很少量的外部网络地址。大部分为小型网络设计的商业NAT都是NAPT。我们选择NATP作为我们研究的对象就是因为它的流行和它通过不允许外来连接限制了P2P协议。后面我们就把NATPs简称为NATs了。

我们首先要做的是得到商业防火墙以确定他们的特性跟资料上记载的是否一样。我们使用NatCheck这个程序对三个常用的NAT设备进行了测试：Netgear MR814,Linksys BEFSR41, 和 Linksys BEFW11S4。三个NAT都有相似的行为：他们对UDP和TCP都进行了一致的转换，这表明在内部主机使用<内部IP：内部端口>的时候，NAT是否直接将<内部IP：内部端口>映射到<外部地址：外部端口>，而不管它连接出去的目标主机<目标IP：目标端口>是多少。一致转换是静态NAT与动态NAT截然不同的一个特点，因为这不只是跟内部主机使用的地址有关，而且还跟端口有关。RFC3002明确指出要支持一致转换。没有一个NAT支持环路转换，不管是TCP还是UDP，这表明NAT是否可以正确的处理两个只知道对方外部地址的内部主机之间的连接。在我们的项目中，我们假设两个主机是在不同的NAT后面的，所以这个测试跟我们的目标是无关的。最后，所有的NAT都提供了对非主动请求的外来TCP和UDP包都进行过滤，这个测试可以表明NAT是否预防非主动恳求的外来包进入到内部网络。非主动请求过滤发生在除了Two-way NAT之外的所有NAT中，这也是在不同NAT后面的主机建立P2P连接最主要的障碍了。

第三章        相关研究工作

为了解决NAT给很多协议带来的困难，一种MIDCOM的架构被提了出来。MIDCOM是一种可以允许NAT或者防火墙后面的用户根据需要改变NAT行为的而允许连接的一种协议。这个系统虽然在某些情况下是适用的，当它却不能保证每个时候都可以。在那些用户没有办法控制NAT的情况下，这种方法对于P2P的连接还是行不通的。很多时候NAT或者防火墙后面的用户通过代理服务器进行连接。一种商业的代理解决方法是Hopster提供的，Hopsetr的代理在连接方本地以隧道级别的传输在本地运行，它通过HTTPS连接到Hopster自己的机器。但是，因为Hopster的代理需要所有的传输都经过他们的机器，所有他们的方法跟我们的比起来就显得低效了，具体见第五章。

为了能够进行直接的P2P连接，出现了针对UDP的解决方法。UDP打洞技术允许在有限的范围内建立连接。STUN（The Simple Traversal of User Datagram Protocol through Network Address Translators）协议实现了一种打洞技术可以在有限的情况下允许对NAT行为进行自动检测然后建立UDP连接。在UDP打洞技术中，NAT分配的外部端口被发送给协助直接连接的第三方。在NAT后面的双方都向对方的外部端口发送一个UDP包，这样就在NAT上面创建了端口映射，双方就此可以建立连接。一旦连接建立，就可以进行直接的UDP通信了。在UDP打洞技术可以成功的情况下，我们在这篇文章中所用的有的技术也同样适用。建立TCP连接比UDP连接更有优势。首先，UDP连接不能够依赖建立好的连接，就是不能够持久连接。UDP是无连接的并且没有对明确的通信。一般地，NAT见了的端口映射如果一段时间不活动后就是过期。为了保持UDP端口映射，必须每隔一段时间就发送UDP包，就算没有数据的时候，只有这样才能保持UDP通信正常。第二，很多防火墙都配置成拒绝任何的外来UDP连接。最后，一个单纯的TCP连接的实现更直观，并且现有的代码简单得修改就可以使用我们的技术。

Walfish et al.指出，采用间接得服务可以提供NAT或者防火墙后面主机之间得连通性，通过在两主机向间接服务器打开一个连接，并且服务器在他们之间传输所有得通信，在这篇文章中我们会完成一个不需要这样得间接服务器也能建立起这样得连接。

第四章        问题陈述和假设

假设两个主机在不同的NAT后面，并且都知道对反的IP地址。如果这些主机想直接发起TCP连接，那肯定失败。在直接的TCP连接中，必须有一方是发起者（发送SYN包），另一方必须监听。在两个都在NAT后面的情况下，监听者将不可能收到SYN包，因为SYN包在到达NAT的时候就被丢弃了。这是因为NAT或者防火墙不允许来自INTERNET的未请求的数据包进入他们的网络内部。所以，为了在不同NAT后面的主机之间建立直接的连接，必须让NAT以为这个连接是经过内部主机发起的。我们可以通过让两边的主机都发起一个TCP连接，也就是创建一个SYN包，这样两边的NAT都会以为这个连接是从内部发起的，是经过内部请求的，因此，就可以允许后续的数据经过它的网络了。

为了能够在两主机间成功地建立一个TCP连接，双方必须在发送SYN包前就知道对方的外网端口。这个端口是在内部主机发起的数据包到外部IP经过NAT的时候NAT为其分配的。就像记帐一样，NAT把内部主机和端口跟它分配的端口绑定，我们说这种绑定说NAT的端口映射。NAT不会跟其他的任何主机共享它的绑定信息。所以，我们的技术会说明怎么有效的检测NAT的端口映射的信息。一旦双方都知道了对方的外部端口，双方都发起TCP连接。TCP序列号和应当号在TCP连接的同步中是完整的一部分。序列号不能够指定，只能捕捉它。我们的文章将会说明怎么协议管理这些参数以成功地在任何的环境下建立一个TCP连接。

我们所做的两个假设在我们测试过的NAT中都是成立的。第一个假设是我们假设主机都收不到来自外部网络的ICMP TTL过期包。如果这些包被主机接收，那么TCP连接就会被中断。我们的很多解决方法中都依赖于能够为发送SYN的数据包设置一个很低的TTL值。当SYN包被路由丢弃的时候，TCMP TTL过期包会被发送回NAT。用于我们实现的NAT必须没有转发收到的ICMP TTL过期包给内部网络。如果NAT真的把这个包发送回内部网络，也可以配置防火墙来阻止这类包。我们的另一个假设是NAT看到ICMP TTL过期包的时候映射的端口还不会失效。作为另一个选择，我们可以不修改TTL值，那就必须让目标NAT不会产生TCP RST包。而实际上这个选择是可行的，因为很多的NAT为了防止端口扫描一般都不发送TCP RST包。

第五章        技术

使用图1的模型，我们的目标是让在NA和NB后面的A和B建立直接的TCP连接。

我们已经开发出几种方法可以建立这样的连接，根据NAT和网络情况的不同，我们有对应的方法。考虑以下的信息作为有序的三元组：<NA端口可预测性，NB端口可预测性，源地址可路由>。我们考虑下面几种情况：

Case 1: <可预测, 可预测, LSR>

Case 2: <可预测, 可预测, no LSR>

Case 3: <随机, 可预测, LSR>

Case 4: <随机, 可预测, no LSR>

Case 5: <随机, 随机, LSR>

Case 6: <随机, 随机, no LSR>

 

本章主要部分暂未翻译，精品，要细细来

第六章        实现

我们已经在LINUX工作站，通过调用libnet和libpcap使用C实现了第2种和第4种情况。第6种情况没有实现。

当我们需要希望发送出去的数据包不被对方接收到，也没有返回错误消息，我们可以把发送给对反得数据包得TTL时间设得足够短。我们测试过得NAT都没有返回ICMP的TTL过期的数据包。我们发送出去正常的数据包并且希望对反的NAT只是默默地把它丢弃。第二和第四种情况的实现都很成功，他们都可以建立直接的TCP连接。第二种情况可以可靠地打开连接，而第四种情况地成功率也是很高的（就是上面所讨论的，成功率取决于在预测相位的端口发送SYN和SYNACK的数量）

第二种和第四种情况必须有root的执行权，因为这是libnet和libpcap所要求的。第三方可以以一般用户的权限运行。

第七章        总结

我们已经证明了如何在两个不同的典型的NAT后面的主机之间建立直接的TCP连接，这些解决方案都没有以任何方式改变TCP/IP栈，而是为这些主机建立连接起到了杠杠作用。我们的方案可以为很多的程序所应用，从点对点的通信到即时消息通信。对于这个问题已经存在解决方法包括代理都没有有效地利用网络资源并且伸缩性不好。

随着IPV6的到来，NAT也许就不再是个网站的组成了，但是，这些情况包括可预测NAT也可以被应用到使用状态的防火墙后面的主机。跟NAT相似，“状态防火墙”有能力只允许从他们所包含的内部网络发起的连接。我们的解决方案双方都可以初始话一个这些防火墙都允许的TCP连接。我们的几种方案在配置有IDSes的场合是不可取的，因为在第四和第六种情况下，都使用了类似于端口扫描的技术。这种情况下最后关闭这样的网络监视设备。尽管如此，我们地解决方案对于大部分的网络来说一般是足够的，甚至对于那些可能都不存在的使用随机分配地址的NAT来说也是适用的。

参考文献

[1] Bryan Ford, “NatCheck,” Hosted by the MIDCOM-P2P project on SourceForge, http://midcom-P2P.sourceforge.net/

[2] B. Karp, S. Ratnasamy, S. Rhea, and S. Shenker “Spurring Adoption of DHTs with OpenHash, A Pubilc DHT Service,” In Proceedings of the Workshop on Peer-to-Peer Systems (IPTPS 2004), February 2004.

[3] Groove Networks, http : / /groove . net

[4] “Hopster: bypass firewall bypass proxy soft?

ware” http://www.hopster.com/

[5] Information Sciences Institute, “Transmission Control Protocol,” RFC 793, Internet Engineer­ing Task Force, September 1981.

[6] J. Postel, “Internet Control Message Proto­col,” RFC 792, Internet Engineering Task Force, September 1981.

[7] J. Rosenberg, J. Weinberger, C. Huitema, and R. Mahy, “STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs),” RFC 3349, Inter­net Engineering Task Force, March 2003.

[8] M. Holdrege and P. Srisuresh, “Protocol Com­plications with the IP Network Address Trans­lator,” RFC 3027, Internet Engineering Task Force, January 2001.

[9] Y. Rekhter, B. Moskowitz, D. Karrenberg, G. J. de Groot, and E. Lear, “Address Alloca­tion for Private Internets,” RFC 1918, Internet Engineering Task Force, February 1996.

[10] M. D. Schiffman, “Building Open Source Net­work Security Tools,” Indianapolis: Wiley Pub­lishing, 2003.

[11]P. Srisuresh and M. Holdrege, “IP Network Ad­dress Translator (NAT) Terminology and Con­siderations,” RFC 2663, Internet Engineering Task Force, August 1999.

[12] P. Srisuresh and K. Egevang, “Traditional IP Network Address Translator (Traditional NAT),” RFC 3022, Internet Engineering Task Force, January 2001.

[13] P. Srisuresh, J. Kuthan, J. Rosenberg, A. Moli­tor, and A. Rayhan, “Middlebox communication architecture and framework,” RFC 3303, Inter­net Engineering Task Force, August 2002.

[14]W. Richard Stevens, Bill Fenner, and Andrew M. Rudoff, “Unix Network Programming Vol­ume 1, Third Edition,” Boston: Addison-Wesley, 2004.

[15]M. Walfish, J. Stribling, M. Krohn, H. Balakr­ishnan, R. Morris, and S. Shenker, “Middle­boxes No Longer Considered Harmful,” To ap­pear in Proceedings of USENIX Symposium on Operating Systems Design and Implementation (OSDI 2004), December 2004.

 

posted on 2004-10-20 17:17 dragonimp 阅读(2307) 评论(13)  编辑 收藏

评论

# re: p2p:TCP穿透NAT防火墙

晕，我最想看的就是你品的那一段，品完了没有啊，品完了翻译出来看看啊：）

2006-05-23 11:32 | 疯子阿虹

# re: p2p:TCP穿透NAT防火墙

看了但是后来没有翻译
这是毕业前的事了

2006-05-23 17:48 | dragonimp

# re: p2p:TCP穿透NAT防火墙

第五章        技术
  使用图1的模型，我们的目标是让在NA和NB后面的A和B建立直接的TCP连接。
  我们已经开发出几种方法可以建立这样的连接，根据NAT和网络情况的不同，我们有对应的方法。考虑以下的信息作为有序的三元组：<NA端口可预测性，NB端口可预测性，源地址可路由>。我们考虑下面几种情况：
Case 1: <可预测, 可预测, LSR>
Case 2: <可预测, 可预测, no LSR>
Case 3: <随机, 可预测, LSR>
Case 4: <随机, 可预测, no LSR>
Case 5: <随机, 随机, LSR>
Case 6: <随机, 随机, no LSR>

//------初稿，以下内容由weljin翻译，更新将放在# re: p2p:TCP穿透NAT防火墙

5.5情况2：<可预测的，可预测的，no LSR>
    情况1依靠于可用的松散源路由。许多路由目前是设置了预防松散源路由，同时将代表性地抛弃请求服务的包。同样地，依靠于松散源路由的技术在实际中将有很高的概率会失败。如果松散源路由不可利用，SYN序列号能够利用一个外出通道（他们预先连接到X）和X通信，而不是物理性地让X看到包。注意图2的步骤2，X知道TCP序列号P和Q，因为X正确地接收到两个SYN包。没了LSR就不是这种情况了。
    为了初始连接，每端主机发送一个初始的SYN包到他们的伙伴，虽然他们知道将不能到达目的地。他们这时嗅探包离开网络，标记序列号，并报告这个信息给X。X需要这些包的TCP序列号，因此它将能够转播这些信息回到A和B，那样他们能够产生SYN+ACK包。两条路发的包都不会到达他们标记地址的目的地。
    更简单的方案是每个端点发送一个SYN到他们不考虑的伙伴。在接收端适当的设置NAT和防火墙将由于没有映射存在而不会向前发送这些包到内部网络主机。一些NAT和一些防火墙将发送TCP 重置包(RST)到不请自来的包的源地址。如果NAT没有产生RST包，A和B不能简单的像图2里步骤1的建议发送一个SYN包到对方，因为在接受到RST，NA和NB能够确定洞的建立。如果NAT没有产生RST包，打开的TCP连接将不会突然终止。
    另一种确保SYN包将不会到达它的目的网络的方法是发送带有TTL值低于伙伴的NAT路径长度的SYN包。这包将会在去目的地的路上被明确地抛弃，并且TCP RST包将不会被任何发送者看到。一个ICMP超时包将会被看到并且有一个问题，因为ICMP超时包突然地终止一个TCP连接。然而，如果使用者能够设置他们本地的防火墙抛弃ICMP包或者如果NAT 不会发送ICMP消息包到它的内部网络，TCP连接尝试将不会突然终止。
    一个方案不能包括简单的欺骗SYN包源地址，因此发送者不会接收到ICMP包或者RST包。做这些会在中间件创建一个残废的映射。在看到一个SYN包时，中间件将创建一个从内部IP地址和端口到外部IP和端口的映射。然而，由于一个欺骗的SYN包有一个错误的源IP地址，映射将不会对应到内部网络的主机。加之，一个方案不会包括设置TTL低到连中间件都看不到SYN包，因为这样做不会创建我们需要的允许外部后发到内网的通信的映射。
    假定一个<可预测的，可预测的，no LSR>环境，那连接像我们现在在图3所描述的。
    1.X做了关于5.1节描述的端口预测。X预测到NA的下一端口是4000并预测到NB的下一端口是5000，并经由已经存在的连接告知A和B。
    2.A和B发送一个SYN包到对方，他们知道这包将会被对方的NAT抛弃或者由于TTL超时而被抛弃。
      （a）NA:4000→NB:5000,SYN:P
      （b）NB:5000→NA:4000,SYN:Q
      这一点是在各个端点的真实TCP connect()调用产生的。SYN包由TCP堆栈产生。这在NAT上创建了允许后来的来自伙伴IP地址和端口的通信通过并到达端点的映射。
    3.A和B发送他们留意的ISN（P和Q）到X。
      （a）NA:3999→X:1234,刚使用的ISN号P
      （b）NB:4999→X:1235,刚使用的ISN号Q
      每个端点将需要它的伙伴的ISN，所以他们能够构造合法的SYN+ACK包发到他们的伙伴。
    4.X发送对方所留意的ISN到A和B。
      （a）X:1234→NA:3999,B刚使用的ISN号Q
      （b）X:1235→NB:4999,A刚使用的ISN号P
    5.A和B发送SYN+ACK包到对方
      （a）NB:5000→NA:4000,SYN+ACK:Q,P+1
      （b）NA:4000→NB:5000,SYN+ACK:P,Q+1
      这是三次握手的第二部分。此外，重用了他们原来的序列号P和Q作为在SYN+ACK中的序列号，A和B将确保序列号和应答号的最后状态是5.2节所讨论的真实的TCP连接。
    6.A和B发送ACK包到对方，他们知道这包将会被对方的NAT抛弃或者由于TTL超时而被抛弃。
      （a）NA:4000→NB:5000,ACK:Q+1
      （b）NB:5000→NA:4000,ACK:P+1
      TCP堆栈将自动地为我们发送这些ACK包来完成三次握手。我们不想ACK包到达他们的目的地，由于没有任何一方在等待ACK包。
    作为步骤4到5的变化和情况1和相像，X能够欺骗A和B所需的SYN+ACK包。然而，我们在情况1中为了某些原因选择目前的方法。
    由于步骤2到6在我们的技术中是可重复利用的，所以我们做了函数Case2(integer extPortA, integer extPortB)作为执行步骤2到6，用参数extPortA和extPortB分别替代了外部端口4000和5000。

2006-08-22 11:01 | weljin

# re: p2p:TCP穿透NAT防火墙

5.6情况3：<随机的，可预测的，LSR>
    情况3<随机的，随机的，LSR>是类似于图2所描述的情况1。然而，X不能够预测到两个NAT中一个的端口，比方说NA。A不得不发送它的SYN包首先允许X查看NA所选的端口。X将报告这一信息给B，因此B能够发送它的SYN包到正确的目标IP地址和端口。这个情况1的修改版在图4中描述并解释如下。
    1.X做了关于5.1节描述的端口预测。X不能预测到NA的下一端口，但能够预测到NB的下一端口是5000，并经由已经存在的连接告知A和B。
    2.A和B同步经由X
      （a）NA:m→NB:5000，LSR:X，SYN:P
      （b）X让B知道NA工作于端口m
      （c）NB:5000→NA:m，LSR:X，SYN:Q
      这些SYN包是由TCP connect()调用产生。
      这些SYN在NAT的NA和NB上创建了预期的映射。
    3.调用Case1(m,5000)

2006-08-22 11:02 | weljin

# re: p2p:TCP穿透NAT防火墙

5.7情况4：<随机的，可预测的，no LSR>
    情况4的环境是<随机的，可预测的，no LSR>。我们已经为这个依靠于不拒绝一个带了对应于NAT后的主机在前面初始的连接的一个残废的ACK或者校验和域的TCP包的随机的NAT环境开发了一个方案。这方案被呈现在图5中并解释如下。
    1.X做了关于5.1节描述的端口预测。X不能预测到NA的下一端口，但能预测到NB的下一端口是5000，并经由已经存在的连接告知A和B。
    2.A发送T个SYN包到B，这些包不是被对方的NAT抛弃就是由于TTL超时而被抛弃。
      i = 0
      While i < T
          NA:rand →NB:5000, SYN:anything
          i = i+1
      End While
      这会在NAT NA上创建T个映射，B将最后用SYN+ACK猜到的就是其中一个。
    3.X通知B开始发送SYN+ACK包到NA
    4.B发送许多SYN+ACK包到NA直到有一个到达A
      i = 1024
      While A 还没报告成功
          NB:5000 →NA:i,
          SYN+ACK:,anything,anything, Payload:i
          i = i+1
      End While
    5.A报告穿过NAT的包负荷。
      NA:3999→X:1234,工作于端口m
      A将通过监听来自NB的任何SYN+ACK包的数据报将看到这个残废的SYN+ACK包。
    6.X告诉B连接到A的端口m
      B现在知道SYN包可以发向哪里。
    7.调用Case2(m,5000)
    在步骤2中A所发送的T个SYN包是独立于任何TCP connect()调用。他们仅仅是使用在NAT上创建了T个映射的libnet库产生的包。另一方面，Case2调用的步骤2所产生的SYN包是由A和B的TCP connect()调用产生的。这情况4环境的方案依靠于随机生成端口的NAT的行为。这方案依靠于拒绝带有错误的如序列号或者校验和域的TCP包的中间件。
    T值能够被选择，像B在生成T个SYN+ACK到随机目的端口号后有95%的机会猜到一个正确的外部端口。其实，A的NAT随机地选择T的号（它的外部端口号），这时B必须一直维持猜测直到在A的NAT可选集中B选择了一个。我们能够使用一个概率分析来构造一个高效的工作的最小量被A和B预算的设想。让PrG是B猜到在T个实验中最少一个正确的概率。建设A的NAT已经在[1025，65535]的范围中选择了T个不同的端口号，如果B选择T个不同的端口号，在A的NAT可选集中B不选择一个号的可能性是
    Pr_G =n-T/n * n-1-T/n-1 * n-2-T/n-2 * . . . * n-(T -1)-T/n-(T -1)
其中n是可能选择的端口数（n=65535-1024=64511）。
    Pr_G =(n-i-T/n-i)*（...）*...i=0到T-1相乘
反之，在T个实验中猜到一个是正确的可能性是
    PrG = 1-Pr_G
像之前的规定，T可能被选择如
    PrG > 95%
    1-Pr_G> 95%
计算T的量为T=439的这个乘积。
    0.9506 > 95%
    这结果说明如果A发送439个在A的NAT外部端口得到不同的随机的映射的SYN包，并且B发送许多不同的随机的到目的端口的SYN+ACK包，B在它发送第440个AYN+ACK赶包之前就有大于95%的机会正确地猜测到439个外部端口映射的其中一个。
    原因是仅仅发送T个SYN包至少使用两个资源，第一个是网络带宽的使用，第二是在NAT上创建映射数目。

2006-08-22 11:02 | weljin

# re: p2p:TCP穿透NAT防火墙

5.8情况5：<随机的，随机的，LSR>
    在情况5中的环境是<随机的，随机的，LSR>。为了允许X同步到A和B，B必须知道NA预先发送它的SYN包时所选的端口号。为了确定NA选择的端口，X不得不看A的SYN包。A的SYN包不能被发送直到X确定NB所选的端口号。这个死锁被制成图6的插图。A控制NA端口资源以致不外发SYN包，有效的预防了X知道NA所选的端口号。同样的，B也控制NB端口资源。在他们能够释放所控制资源之前，每端都需要对方的端口。我们让A和B发送两个SYN包松散源路由连接到TCP connect()调用的方案预防这个死锁。这两个SYN包在各自的NAT上创建了所需的映射并允许X获得两个资源，同时等同于情况1和2的类似方式连接。我们情况5的方案展示在图7中并解释如下。
    1.X做了关于5.1接描述的端口预测。X不能预测到NA或者NB的下一端口并经由已经存在的连接告知A和B。
    2.A和B都发送一个SYN包松散源路由穿过X
     （a）NA:m→NB:anything SYN:anything,LSR:X
     （b）NB:n→NA:anything SYN:anything,LSR:X
     （c）X报告m给B并报告n给A。
    这些SYN将在各自的NAT上创建所需的映射。
    3.A和B发送一个SYN到对方松散源路由穿过X
      （a）NA:m→NB:n,LSR:X,SYN:P
      （b）NB:n→NA:m.LSR:X,SYN:Q
    因为一致转换，即使目标端口不同于之前的步骤，NAT仍然为这个包利用所使用的相同映射（因此相同的外部端口号）。
    4.调用Case1(m,n)
    注意，SYN包发送步骤2不是连接到任何TCP connect()调用，而更合适的SYN包发送步骤3应归于一个TCP connect()调用。同理，Casel的调用中SYN+ACK包发送步骤3不绑定到TCP accept()子程序。

2006-08-22 11:02 | weljin

# re: p2p:TCP穿透NAT防火墙

5.9情况6：<随机的，随机的，no LSR>
    情况6的环境是<随机的，随机的，no LSR>。回顾图6的资源图表死锁，A和B从包不可松散源路由保存端口的资源信息。这情况的方案被画成图8并解释如下。
    1.X做了关于5.1接描述的端口预测。X不能预测到NA或者NB的下一端口并经由已经存在的连接告知A和B。
    2.A发送T个SYN包到B同时B发送T个SYN包到A，这些包将被在另一端的NAT抛弃或者由于TTL到期而被抛弃。
    i=0
    While i<T
        NA:rand→NB:rand,SYN:anything
        NB:rand→NA:rand,SYN:anything
        i=i+1
    End While
    这些SYN包在两边的NAT上创建了T个映射。
    3.B和A发送许多SYN+ACK包到他们的伙伴的NAT直到有一个到达他们的伙伴那里。
    i=1024
    While A 还没报告成功
        NB:rand→NA:i
        SYN+ACK:,anything,anything,Payload:i
        NA:rand→NB:i
        SYN+ACK:,anything,anything,Payload:i
        i=i+1
    End While
    4.A和B报告通过NAT的包负荷。
      NA:3999→X:1234,工作于端口m
      NB:4999→X:1235,工作于端口n
    5.X告诉B连接到A的端口m并告诉A连接到B的端口n。
      A和B现在知道他们的伙伴的外部端口号。
    6.调用Case2(m,n)
    情况6远比情况4困难，因为各个端点必须在对方的NAT上正确地猜到一个完整的映射〈源端口，目的端口〉。在情况4中，在非随机的NAT后的端点能够正确地猜到目的端口。当其中一个NAT是可预测时，源端口就被固定了。情况6的搜索空间是情况4的平方，替代64511种可能是4161669121种结合需要猜测。
//------Translated by weljin.QQ:15038084.MSN:weljin@hotmail.com.G-mail:weljin.china@gmail.com.E-mail:weljin@163.com.Q-mail:weljin@qq.com.------//
//------初稿，以上内容由weljin翻译,更新将放在<A&NBSP;TARGET="_NEW"&NBSP;HREF="HTTP: 15038084.qzone.qq.com或http: blogs.impx.net dragonimp archive 2004 10 20 487.html,转载请保持来源的完整性?>weljin