nat爆破者：在不同nat后的主机间建立tcp连接.txt

P2P穿透NAT的一次探讨和局部实现

|<--------------|-------3-------|
|---------------|-------------->|
|<--------------|---------------|
|---------------|-------------->|
|<--------------|---------------|
|┆             |┆             |
|---------------|-------------->|
|<--------------|---------------|
|-------4------>|<------4-------|
|<------5-------|-------5------>|
|          Case2|(m,n)          |
	    图8：情况6
    情况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:[e-mail].G-mail:[e-mail].E-mail:[e-mail].Q-mail:[e-mail].------//
//------第一次修改，以后修改将加入测试代码，以上内容由weljin翻译,更新将放在http://15038084.qzone.qq.com或http://blogs.impx.net/dragonimp/archive/2004/10/20/487.html,转载请保持来源的完整性------//

6. 实现
    我们已经在LINUX工作站，通过调用libnet和libpcap使用C实现了第2种和第4种情况。第1、3、5、6种情况没有实现。
    协助者和端点都连接到由单独功能组成的库。协助者程序natblaster_server()只需提供其协助者所要监听的端口号。端点连接程序需要提供7个参数：（1）协助者的IP地址和（2）端口号，（3）本地端点外部IP地址，（4）内部IP地址，和（5）端口号，（6）伙伴外部IP地址，和（7）端口号。本地端点和伙伴的端口号必须由协助者帮助为试图的连接建立一个唯一标志符。三元组<本地外部IP，伙伴内部IP，伙伴内部端口>被用于在协助者上的唯一标志。库试图提供一个指定端口的套接字，然而，所返回的套接字不被保证是所指定的端口号。假设natblaster_connect()工作，库返回一个有效的套接字句柄。
    为了测试我们的实现，我们在分离的网络上运行两个端点，每个都位于不同的且有效的NAT后面。第三部分的程序被运行于不在NAT之后的第三部计算机上。我们在英特网上做了比本地网络更多的测试，来确保测试更真实。
    为了创建不会到达伙伴那里并不返回错误消息的包，我们设置了TTL值使其低到不会到达伙伴那里。设置低的TTL值由调用IP_TTL选项的setsockopt()系统调用完成。这选项也需要一个TTL值。这个值必须低于到伙伴的跳跃数，但必须要大于到外部最远的NAT的跳跃数。这套接字选项对于套接字的整个生存期来说必须不是持久不变的。例如，在三次握手成功之后，setsockopt()应该被再一次调用来提高 TTL值，这样后面的数据才确保能到达端点。依靠的是一个低的TTL只工作于是否一个ICMP TTL过期包不被端点的TCP堆栈看到，因为这过期包会导致在端点的套接字失败。我们所测试的NAT都不向前发送ICMP TTL过期包到内部网络。另一种方法是将发送普通包并希望伙伴的NAT默默地丢弃它们，然而，一些NAT可能发送RST包来响应那些未请自来的数据。这行为是详细的执行过程。我们没使用5.3节所描述的TTL决定技术；而是我们选择了我们知道是合适的并且低而普通的TTL值。
    我们为连接前诊断实现了连续的端口分配方法，但没有实现一致转换。我们的实现没有使用一致转换。
    我们的情况2和情况4的实现都非常成功并且能打开直接的TCP连接。情况2真实的打开了连接，而情况4有很高的几率是成功的（就是上面所讨论的，成功率取决于在预测相位的端口发送SYN和SYNACK的数量）。
    由于5.9节最后所给的原因，我们没有实现情况6。我们没实现情况1，3和5是因为LSR在英特网上不是典型地可用的并且我们相信这在实践中会有较低的成功率。
    如前面所论述的，我们使用了增加系统调用所需的标准的Berkelet网络实现。例如，当我们发送一个SYN包但需要知道序列号时，这个SYN包由使用标准的connect()调用所发送的，之后首先开始一个线程来为所发的SYN包观测数据报。这线程能报告所使用的序列号。
    情况2和情况4必须有root的执行权，因为这是libnet和libpcap所要求的。由于无需欺骗或者探嗅，第三方可以以一般用户的权限运行。

7. 总结
    我们已经证明了如何在两个不同的典型的NAT后面的主机之间建立直接的TCP连接，这些解决方案都没有以任何方式改变TCP/IP栈，而是为这些主机建立连接起到了杠杠作用。我们的方案可以为很多的程序所应用，从点对点的通信到即时消息通信。对于这个问题已经存在解决方法包括代理都没有有效地利用网络资源并且伸缩性不好。
    随着IPv6的到来，NAT也许就不再是个网站的组成了，但是，这些情况包括可预测NAT也可以被应用到使用状态的防火墙后面的主机。跟NAT相似，“状态防火墙”有能力只允许从他们所包含的内部网络发起的连接。我们的解决方案双方都可以初始话一个这些防火墙都允许的TCP连接。我们的几种方案在配置有IDSes的场合是不可取的，因为在第四和第六种情况下，都使用了类似于端口扫描的技术。这种情况下最后关闭这样的网络监视设备。尽管如此，我们地解决方案对于大部分的网络来说一般是足够的，甚至对于那些可能都不存在的使用随机分配地址的NAT来说也是适用的。

8. 参考文献
[1] Bryan Ford. NatCheck: Hosted by the MIDCOM-P2P
    project on SourceForge.
    http://midcom-p2p.sourceforge.net.
[2] Bryan Ford, Pyda Srisuresh, and Dan Kegel. Peer-to-Peer
    Communication Across Network Address Translators. In
    USENIX Annual Technical Conference, Anaheim, CA, April
    2005.
[3] Groove Networks. http://groove.net.
[4] Saikat Guha, Yutaka Takeday, and Paul Francis. NUTSS: A
    SIP-based approach to UDP and TCP Network Connectivity.
    In SIGCOMM 2004 Workshops, Aug 2004.
[5] M. Holdrege and P. Srisuresh. Protocol Complications with
    the IP Network Address Translator. RFC 3027, Internet
    Engineering Task Force, January 2001.
[6] Hopster: Bypass Firewall Bypass Proxy Software.
    http://www.hopster.com.
[7] Information Sciences Institute. Transmission Control
    Protocol (TCP). RFC 793, Internet Engineering Task Force,
    September 1981.
[8] Brad Karp, Sylvia Ratnasamy, Sean Rhea, and Scott
    Shenker. Spurring Adoption of DHTs with OpenHash, a
    Public DHT Service. In Proceedings of the 3rd International
    Workshop on Peer-to-Peer Systems, Feb 2004.
[9] Y. Rekhter, B. Moskowitz, D. Karrenberg, G. J. de Groot,
    and E. Lear. Address Allocation for Private Internets. RFC
    1918, Internet Engineering Task Force, February 1996.
[10] J. Rosenberg, J. Weinberger, C. Huitema, and R. Mahy.
     STUN - Simple Traversal of User Datagram Protocol (UDP).
     RFC 3489, Internet Engineering Task Force, September
     2003.
[11] P. Srisuresh and K. Egevang. Traditional IP Network
     Address Translator (Traditional NAT). RFC 3022, Internet
     Engineering Task Force, January 2001.
[12] P. Srisuresh and M. Holdrege. IP Network Address
     Translator (NAT) Terminology and Considerations. RFC
     2663, Internet Engineering Task Force, August 1999.
[13] P. Srisuresh, J. Kuthan, J. Rosenberg, A. Molitor, and
     A. Rayhan. Middlebox communication architecture and
     framework. RFC 3303, Internet Engineering Task Force,
     August 2002.
[14] Jason Thomas, Andrew Mickish, and Susheel Daswani. Push
     Proxy: Protocol Document 0.6, June 2003.
[15] Michael Walfish, Jeremy Stribling, Maxwell Krohn, Hari
     Balakrishnan, Robert Morris, and Scott Shenker.
     Middleboxes No Longer Considered Harmful. In
     Proceedings of USENIX Symposium on Operating Systems
     Design and Implementation, December 2004.