NAT穿越（转）

NAT穿越（转）(2009-05-20 18:52:03) 标签：nat 穿越 杂谈  分类：工作相关 NAT穿越

原文版权：Copyright (C) The Internet Society (2003).All Rights Reserved.
原文地址：http://midcom-p2p.sourceforge.net/draft-ford-midcom-p2p-01.txt
译文版权申明：请引用此文的作者或网站注明出处：http://blog.csdn.net/hxhbluestar，以尊重译者的劳动成果！

随着IPv6时代的到来，我也一直怀疑，是不是还有必要再去学习NAT技术——因为网络的资源不再如IPv4时代匮乏，而NAT技术正是为解决IP地址的紧缺而存在的，如此，NAT便没有存在的必要了。
但是，随着这篇文章的翻译，我的怀疑慢慢变成庆幸，渐而又变为肯定，通过翻译所学到的东西，不再仅仅是翻译第一手资料带来的成就感，更多的是通过翻译，去领悟技术前辈们的智慧与经验，也通过翻译，养成自己从第一手资料获得信息的习惯，从而将视野放得更宽，让理解更为透彻——至少，很多东西都是要经过仔细斟酌才真正转化为自己思想的一部分的。正是如此，我才坚定的要把这篇文章翻译完，也如之前所提到的，如果时间允许的话，我会用C#来写一些例子，让大家更好的理解NAT技术，掌握NAT技术（主要涉及到即时通讯、文件对等传输和语音应用三个方面）。

这篇文章主要是介绍一下“代理”机制的起因以及给P2P应用带来的不便，不需要任何基础知识：）

1. Introduction
1、简介

关键词：
middleboxe(s) —— 我翻译成“代理”，也许有更好的翻译
host —— 我翻译成“主机”，希望大家不要理解成服务器了，主机就是一台普通的终端机

在当今的Internet中，普遍存在使用“代理”设备来进行网络地址转换（NAT），导致这种现象的原因是 IPV4 地址空间的资源耗尽危机。虽然不对称 asymmetric 的地址分配和连通性制度已经在代理中被定义，但是却给端对端应用程序和协议制定造成了一些特殊的问题。像电话会议和多媒体网络游戏。这些问题即使在 IPV6世界中还是会存在，因为NAT作为IPV4的一种兼容性机制经常被使用[NAT-PT]，并且防火墙将仍然将普遍存在，即使不再需要NAT技术。

当前使用的“代理”技术主要是为 客户端/服务端 C/S 结构设计的，为了实现那些需要连接但是又没有固定IP地址的客户端能够连接到一台配置好的拥有固定IP和DNS域名的服务器。
大 多数的“代理”使用一种 asymmetric 通信模型，即 私网（局域网） 的主机能发起一个“外出”连接去连接公网上的主机。但是公网上的主机却无法发送信息给私网上的主机（除非对“代理”进行特殊的配置），NAPT（网络地址端口转换）的普通情况是，一个私网客户端不需要一个公网的固定的IP地址，但是必须要共享一个由NAPT控制的公网的固定IP地址（当然这个NAPT是处于同一个私网内部的）。这样的话，这些匿名的并且看起来难以触及的藏在NAT之后的内网主机对于像 Web浏览器这种软件来说就不是一个问题,因为内网的主机只需要发起向外部的连接就可以了。这样一来，无法触及也还是有他的优点的——那就是具有保密性。

然而，在P2P的应用中，Internet上的“客户机”之间是需要建立一个通信会话直连的。邀请者和响应者也许会处于不同的NAT之后，也许他们都没有固定IP或者即使有也不是公网的IP地址。举例来说，在一个普通的网络游戏体系结构中，都是通过客户端向一个具有公网固定IP的服务器发起申请进行初始化并通过验证的。同时，客户端之间也要建立直连，才使网络间传输的速度加快，保证数据即时更新（不然抢不到装备啊，呵呵）。
同样的，一个文件共享应用程序也必须通过到一个服务器上去查找它想要的资源，然后再到拥有这个数据的主机上去下载（BT网站，走了一个中介），“代理”造成了很多P2P直连的问题，因为藏在“代理”之后的的主机通常没有固定的端口来使其他的客户端发起的TCP或UDP连接能够最终到达。
RFC 3235[NAT-APPL] 简要的提到了这个问题，但是没有给出任何的解决方案。

在这篇文章中，我们用两种方式讨论 P2P/代理的问题。首先，概要的讲叙已有的P2P应用程序能够在现有的代理机制中的工作原理。然后，我们提供一组应用程序设计指南，基于已有的实践，在现有的配置好的代理上，来使得P2P应用程序操作更加有条理。最后，我们提供了设计指南，为以后的代理机制能够更方便支持P2P应用程序。讨论的焦点是如何直接的、广泛的 配置那些需要经过“代理”的P2P应用程序。

2. 术语

在这一章节中，首先概要的介绍一下“代理”技术的一些术语。然后集中讨论两种造成P2P应用问题的代理机制。

防火墙
防火墙限制了私网与公网的通信，它主要是将（防火墙）认为未经授权的的包丢弃，防火墙只是检验包的数据，并不修改数据包中的IP地址和TCP/UDP端口信息。

网络地址转换（NAT）
当有数据包通过时，网络地址转换器不仅检查包的信息，还要将包头中的IP地址和端口信息进行修改。以使得处于NAT之后的机器共享几个仅有的公网IP地址（通常是一个）。网络地址转换器主要有两种类型：

基础NAT
基础NAT 将私网主机的私有IP地址转换成公网IP地址，但并不将TCP/UDP端口信息进行转换。基础NAT一般用在当NAT拥有很多公网IP地址的时候，它将公网IP地址与内部主机进行绑定，使得外部可以用公网IP地址访问内部主机。（译者注：实际上是只将IP转换，192.168.0.23 <-> 210.42.106.35,这与直接设置IP地址为公网IP还是有一定区别的，特别是对于企业来说，外部的信息都要经过统一防火墙才能到达内部，但是内部主机又可以使用公网IP）

网络地址和端口转换 （NAPT）
这是最普遍的情况，网络地址/端口转换器检查、修改包的IP地址和TCP/UDP端口信息，这样，更多的内部主机就可以同时使用一个公网IP地址。
请参考[NAT-TRAD]和[NAT-TERM]两个文档了解更多的NAT分类和术语信息。另外，关于NAPT的分类和术语，[STUN]在最近做了更多的定义。当一个内部网主机通过NAT打开一个“外出”的TCP或UDP会话时，NAPT分配给这个会话一个公网IP和端口，用来接收外网的响应的数据包，并经过转换通知内部网的主机。这样做的效果是，NAPT在 [私有IP:私有端口] 和[公网IP:公网端口]之间建立了一个端口绑定。
端口绑定指定了NAPT将在这个会话的生存期内进行地址转换任务。这中间存在一个这样的问题，如果P2P应用程序从内部网络的一个[私有IP地址:端口]对同时发出多条会话给不同的外网主机，那么NAT会怎样处理呢？请看以下几种方案。

锥形NAT
（译者注：为什么叫做锥形呢？请看以下图形,终端和外部服务器，都通过NAT分派的这个绑定地址对来传送信息，就象一个漏斗一样，筛选并传递信息）

当建立了一个 [私有IP:端口]-[公网IP:端口] 端口绑定之后，对于来自同一个[私有IP:端口]会话，锥形NAT服务器允许发起会话的应用程序重复使用这个端口绑定，一直到这个会话结束才解除（端口绑定）。

例 如，假设 Client A（IP地址信息如上图所示）通过一个 锥形NAT 同时发起两个外出的连接，它使用同一个内部端口（10.0.0.1:1234）给公网的两台不同的服务器，S1和S2。锥形NAT 只分配一个公网IP和端口（155.99.25.11:62000）给这个两个会话，通过地址转换可以 确保 Client使用端口的“同一性”（译者注：即这个Client只使用这个端口）。而基础NATs和防火墙却不能修改经过的数据包端口号，它们可以看作是锥形NAT的精简版本。

对称NAT
对称NAT，与Cone NAT是大不相同的，并不对会话进行端口绑定，而是分配一个全新的 公网端口 给每一个新的会话。
还 是上面那个例子：如果 Client A (10.0.0.1:1234)同时发起两个 "外出" 会话,分别发往S1和S2。对称Nat会分配公共地址155.99.25.11:62000给Session1，然后分配另一个不同的公共地址 155.99.25.11:62001给Session2。对称Nat能够区别两个不同的会话并进行地址转换，因为在 Session1 和 Session2中的外部地址是不同的，正是因为这样，Client端的应用程序就迷失在这个地址转换边界线了，因为这个应用程序每发出一个会话都会使用一个新的端口，无法保障只使用同一个端口了。

在TCP和UDP通信中，（到底是使用同一个端口，还是分配不同的端口给同一个应用程序），锥形NAT和对称NAT各有各的理由。当然锥形NAT在根据如何公平地将NAT接受的连接直达一个已创建的地址对上有更多的分类。这个分类一般应用在Udp通信（而不是Tcp通信上），因为NATs和防火墙阻止了试图无条件传入的TCP连接，除非明确设置NAT不这样做。这些分类如下：

全双工锥形NAT
当内部主机发出一个“外出”的连接会话，就会创建了一个 公网/私网地址，一旦这个地址对被创建，全双工锥形NAT会接收随后任何外部端口传入这个公共端口地址的通信。因此，全双工锥形NAT有时候又被称为"混杂"NAT。

受限制的锥形NAT
受限制的锥形NAT会对传入的数据包进行筛选，当内部主机发出“外出”的会话时，NAT会记录这个外部主机的IP地址信息，所以，也只有这些有记录的外部 IP地址，能够将信息传入到NAT内部，受限制的锥形NAT 有效的给防火墙提炼了筛选包的原则——即限定只给那些已知的外部地址“传入”信息到NAT内部。

端口受限制的Cone NAT
端口受限制的锥形NAT，与受限制的锥形NAT不同的是：它同时记录了外部主机的IP地址和端口信息，端口受限制的锥形NAT给内部节点提供了同一级别的保护，在维持端口“同一性”过程中，将会丢弃对称NAT传回的信息。

最后，在这篇文档里我们将定义一组新的术语 ，以便更好的对P2P代理相关的行为进行分类。

P2P应用程序
P2P应用程序是指，在已有的一个公共服务器的基础上，并分别利用自己的私有地址或者公有地址（或者两者兼备）来建立一个端到端的会话通信。
P2P代理
P2P代理是一个允许 P2P应用程序进行通信的代理机制

P2P防火墙
P2P防火墙是一个提供了防火墙的功能的P2P代理，但是不进行地址转换.

P2P-NAT
P2P-NAT 是一个 P2P代理,提供了NAT的功能,也提供了防火墙的功能,一个最简的P2P代理必须具有锥形NAT对Udp通信支持的功能,并允许应用程序利用Udp打洞技术建立强健的P2P连接。

回环转换
当NAT的私网内部机器想通过公共地址来访问同一台局域网内的机器的时，NAT设备等价于做了两次NAT的事情，在包到达目标机器之前，先将私有地址转换为公网地址，然后再将公网地址转换回私有地址。我们把具有上叙转换功能的NAT设备叫做“回环转换”设备。

3、基于代理服务上的P2P通信技术
本章节详细地回顾了当前比较流行的一些基于当前代理设备的点对点通信技术，来源于应用或协议设计者的前瞻。

3.1 转发

最可靠，但又是最低效的点对点通信方法，莫过于将p2p网络通信看作一个C/S结构，通过（服务器来）转发信息。举例来说，如下图，两个客户端A和B，均与服务器S初始化了一个TCP或UDP连接，服务器S具有公网固定IP地址,两个客户端分布在不同的私网中，这样，他们各自的NAT代理服务器将不允许他们进行直连。

取而代之的方式是，两个客户端可以把服务器S当作信使来转发消息。比如，为了将消息发送到B，A先发送一条信息给服务器S，服务器S再利用初始化时已经建立的连接，将信息转发给B。

4.程序设计指南
4.1. P2P代理的现状
对于两端都处于NAT之后的P2P直连，当前最佳解决方案仍然是UDP打洞技术，而在各种NAT系统中这种技术也得到了相当广泛的应用。当程序需要进行有效的p2p直连的通讯时候，推荐使用UDP打洞技术，当然，当无法建立直连时，也要做好消息转发的处理。
4.2. 位于同一个NAT后的端与端通信指南
在实际的情况中，还有相当大一部分用户不止两个IP地址（多网卡情况），而是三个或者更多，这种情况下，如果很难决定到底使用哪个地址来注册到服务器，就要应用程序将所有的地址都注册到服务器上去。
4.3. 主机发现
应用程序发送很多包到网络的几个地址上，用于发现哪个地址对于指定的主机来说是最好的。这样是导致网络“空间浪费”的源头之一，就象是在网络上倒垃圾一样；端将会选择不正确的路由地址；就像在内部网中一样（例如：11.0.1.1，分配给DOD [DOD还不能确定是什么，查到相关文献是与美国国防部相关的协议] 的）;因此应用程序在发送hello包时，应该小心地练习。(这段话翻译得不是很好，请求指正)
4.4. 基于TCP 的P2P应用程序
套 接字API被应用程序开发者广泛地使用，但它其实最初是专门设计用于 C/S模式的应用程序的。由于这个自身原因，就出现了一些限制：一个套接字只能绑定一个TCP或者UDP端口；应用程序不允许多个套接字绑定同一个端口（TCP或UDP）用于同时与多个外部节点建立会话；也不允许使用一个套接字来监听这个端口的同时，其他套接字通过这个端口发出向外的初始化会话连接。
上面所说的“单一套接字对应单一端口”绑定约束对于UDP来说并不算一个障碍，因为UDP是一个基于数据报的协议。UDP P2P应用程序设计者可以用recvfrom()和sendto()函数来让一个SOCKET不仅发送而且可以从多个主机上接受数据报文。
但是 TCP就不一样了。TCP中，每个进入和外出的连接都和一个单独的套接字保持关联。Linux 套接字API中使用 SO_REUSEADDR 选项标记了这个问题。在FreeBSD和NetBSD上，这个选项一般来说是无法正常工作的，但是，可以将其改为使用BSD-specific SetReuseAddress call(Linux中并没有这个命令，纯Unix标准中亦不存在），就可以使用了。Win32 API提供了一个等效的SetReuseAddress 命令。使用以上所提到的选项，应用程序就能使用多个套接字用来重用TCP端口。那就是说，打开两个TCP套接字流绑定使用同一个端口，只要使用 listen()在一边并在另外一边使用connect()在另外一端。
4.5. 使用 MidCom 协议
如果应用程序知道它们需要穿越的代理并且这些代理实现Midcom协议，应用程序能使用Midcom协议更容易的穿越代理。
例如：P2P 应用程序需要NAT代理保持终端端口的绑定状态。假如代理可以支持Midcom，P2P应用程序可以控制修改绑定端口(或者绑定地址)的参数，例如生存时间，最大空闲时间，因此应用程序不仅可以直接的连接外部主机而且也可以从外部主机接受连接；这样就不需要定期保持端口绑定的状态。当应用程序不再需要绑定，也可以使用Midcom协议简单的取消绑定。
参考：MidCom方案
MidCom（Middlebox Communications）方案是通过在第三方实体和FW/NAT之间建立中间盒来通信，使FW/NAT设备变为可控的一种新的概念。如图所示，MidCom包括MidCom Agent和Middlebox，Agent通过MidCom协议通知Middlebox建立相应的NAT映射表项。

一般情况下，Middlebox集成在NAT或FW设备中，Agent可在软交换、代理服务器或终端上实现。
由 于应用业务识别的智能从Middlebox移到外部的MidCom Agent上，因此，根据MidCom的架构，在不需要更改Middlebox基本特性的基础上，通过对MidCom Agent的升级就可以支持更多的新业务。这是相对于NAT/ALG方式的一个很大的优势。
从安全性考虑，MidCom方式支持控制报文和媒体流的加密，因此安全性比较高。

这个方法的优势是：当两个客户端都与服务端保持连接的时候，它将始终如一的正常工作。
但是它的劣势也很明显:它将全面依赖并消耗服务器的资源和性能和网络带宽。两个客户端的通信反应时间将明显增加，即使他们与服务器始终保持着连接。名为 TURN 的协议[TURN]定义了一个利用转发技术进行可靠通信的模型。

3.2 反向连接

这里介绍第二种技术，但是它只能在通信的两端只有一端处于NAT之后的情况下。举例来说，假设客户端A处于NAT之后，而客户端B有一个公网IP地址，如下图所示

客户端A的私有IP地址是10.0.0.1，并使用TCP端口1234，客户端A初始化了一个与服务器S（IP=18.181.0.31:1235）的连接。NAT A（IP=155.99.25.11）分配了一个62000的TCP端口给这个连接。因此，服务器S认为客户端A的IP地址是 155.99.25.11:62000。而因为客户端B拥有固定IP地址138.76.29.7，所以在这个端对端的连接中，客户端B使用TCP端口 1234。

现在我们假设客户端B将会与客户端A初始化一个端对端连接会话。B将首先试图
连 接A的任何一个地址——客户端A认为是它自己所有的地址，即10.0.0.1:1234。或者是从服务器S观察到的地址,即 155.99.25.11:62000。然而不论是连接上叙地址中的哪一个，都不可能成功。第一种情况：试图直接连到10.0.0.1肯定会失败，因为 10.0.0.1根本就不是一个可以在公网上路由的IP地址；第二种情况，从B传来的TCP SYN请求将能够到达端口NAT A的端口62000，但NAT A却会拒绝这个连接请求，因为只有外出的连接才允许（进入）。

在所有的尝试都失败之后，客户端B就只能借用服务器S来传递一个到客户端A的请求，请求一个“翻转”的连接到客户端B，而客户端A，在接受了这个通过服务器S转发的请求之后，将打开一个与客户端B通讯的TCP连接（在B的公网IP地址和端口号上）。NAT A允许这个连接通过，因为这个连接起源于NAT A的内部，并且同时客户端B能够受这个连接因为B并不位于NAT之后。
当前很多p2p系统都使用了这种技术。它的主要限制在于：只能有一端位于NAT之后这个技术才能生效。然而当今真实的情况是，越来越多的客户端两端都处于 NAT之后，那么这个方法就是不可行的。因为逆向连接不是一个通用的解决方案，所以在这里就不推荐使用了。应用程序可以选择尝试做逆向连接，但是有可能消息会被自动退回——如果另外一端的消息传递机制既不是“正向”也不是“逆向”连接的话。


Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=331289

3.3. UDP hole punching UDP打洞技术
第三种技术，也是这篇文章主要要研究的，就 是非常有名的“UDP打洞技术”，UDP打洞技术依赖于由公共防火墙和cone NAT，允许适当的有计划的端对端应用程序通过NAT“打洞”，即使当双方的主机都处于NAT之后。这种技术在 RFC3027的5.1节[NAT PROT] 中进行了重点介绍，并且在Internet[KEGEL]中进行了非正式的描叙，还应用到了最新的一些协议，例如[TEREDO,ICE]协议中。不过，我们要注意的是，“术”如其名，UDP打洞技术的可靠性全都要依赖于UDP。
这里将考虑两种典型场景，来介绍连接的双方应用程序如何按照计划的进行通信的，第一种场景，我们假设两个客户端都处于不同的NAT之后；第二种场景，我们假设两个客户端都处于同一个NAT之后，但是它们彼此都不知道(他们在同一个NAT中)。

3.3.1. Peers behind different NATs 处于不同NAT之后的客户端通信

我们假设 Client A 和 Client B 都拥有自己的私有IP地址，并且都处在不同的NAT之后，端对端的程序运行于 CLIENT A,CLIENT B,S之间，并且它们都开放了UDP端口1234。 CLIENT A和CLIENT B首先分别与S建立通信会话，这时NAT A把它自己的UDP端口62000分配给CLIENT A与S的会话，NAT B也把自己的UDP端口31000分配给CLIENT B与S的会话。如下图所示：
Server S
18.181.0.31:1234
|
|
+----------------------+----------------------+
| |
NAT A NAT B

假如这个时候 CLIENT A 想与 CLIENT B建立一条UDP通信直连，如果 CLIENT A只是简单的发送一个UDP信息到CLIENT B的公网地址138.76.29.7:31000的话，NAT B会不加考虑的将这个信息丢弃（除非NAT B是一个 full cone NAT），因为这个UDP信息中所包含的地址信息，与CLIENT B和服务器S建立连接时存储在NAT B中的服务器S的地址信息不符。同样的，CLIENT B如果做同样的事情，发送的UDP信息也会被 NAT A 丢弃。

假如 CLIENT A 开始发送一个 UDP 信息到 CLIENT B 的公网地址上，与此同时，他又通过S中转发送了一个邀请信息给CLIENT B，请求CLIENT B也给CLIENT A发送一个UDP信息到 CLIENT A的公网地址上。这时CLIENT A向CLIENT B的公网IP(138.76.29.7:31000)发送的信息导致 NAT A 打开一个处于 CLIENT A的私有地址和CLIENT B的公网地址之间的新的通信会话，与此同时，NAT B 也打开了一个处于CLIENT B的私有地址和CLIENT A的公网地址(155.99.25.11:62000)之间的新的通信会话。一旦这个新的UDP会话各自向对方打开了，CLIENT A和CLIENT B之间就可以直接通信，而无需S来牵线搭桥了。(这就是所谓的打洞技术)！

155.99.25.11:62000 138.76.29.7:31000
| |
| |
Client A Client B
10.0.0.1:1234 10.1.1.3:1234

UDP打洞技术有很多实用的地方：第一，一旦这种处于NAT之后的端对端的直连建立之后，连接的双方可以轮流担 任对方的“媒人”，把对方介绍给其他的客户端，这样就极大的降低了服务器S的工作量；第二，应用程序不用关心这个NAT是属于cone还是 symmetric，即便要，如果连接的双方有一方或者双方都恰好不处于NAT之后，基于上叙的步骤，他们之间还是可以建立很好的通信通道；第三，打洞技术能够自动运作在多重NAT之后，不论连接的双方经过多少层NAT才到达Internet，都可以进行通信。


译后小记：本来已经翻译好了，是在网文快捕中翻译的，结果，一个全选把所有翻译的内容全部删除了(网文快捕的Bug?：)，不得不痛苦的再翻一遍。不过，有失必有得，第二次翻译流畅多了，希望大家读来还顺口。

3.3.2. Peers behind the same NAT 客户端都处于相同的NAT之后

现在让我们来考虑一下两个客户端(很有可能不知不觉的就会)同时位于相同的NAT之后，而且是在同一个子网内部的情况， Client A与S之间的会话使用了NAT的62000端口，Client B与S之间的会话使用了62001端口，如下图所示：
Server S
18.181.0.31:1234
|
|
NAT
A-S 155.99.25.11:62000
B-S 155.99.25.11:62001
|
+----------------------+----------------------+
| |
Client A Client B
10.0.0.1:1234 10.1.1.3:1234

我们假设，Client A 和 Client B 要使用上一节我们所描述的 “UDP打洞技术”，并通过服务器S这个“媒人”来认识，这样Client A 和Client B首先从服务端S得到了彼此的公网IP地址和端口，然后就往对方的公网IP地址和端口上发送消息。在这种情况下，如果NAT 仅仅允许在内部网主机与其他内部网主机（处于同一个NAT之后的网络主机）之间打开UDP会话通信通道，而内部网主机与其他外部网主机就不允许的话，那么 Client A 和Client B就可以通话了。我们把这种情形叫做“loopback translation”(“回环转换”)，因为数据包首先从局域网的私有IP发送到NAT转换，然后“绕一圈”，再回到局域网中来，但是这样总比这些数据通过公网传送好。举例来说，当 Client A发送了一个UDP数据包到 Client B的公网IP地址，这个数据包的报头中就会有一个源地址10.0.0.1:124和一个目标地址155.99.25.11:62001。NAT接收到这个包以后，就会(进行地址转换)解析出这个包中有一个公网地址源地址155.99.25.11:62000和一个目标地址10.1.1.3:1234，然后再发送给B，虽说NAT支持“loopback translation”，我们也发现，在这种情形下,这个解析和发送的过程有些多余，并且这个Client A 和Client B 之间的对话可能潜在性地给NAT增加了负担。


其 实，解决这个问题的方案是显而易见的。当 Client A和ClientB 最初通过服务器S交换彼此的地址信息时，它们应该发现了自己的IP地址和端口，也就是自己的 Local IP，同时，加上Server S发现的它们的公网地址和端口（即NAT分配给它们的） 。两个客户端同时的发送 数据包到对方的公网地址和私有地址上，然后选择首先使得通信成功的那个地址就可以了。如果两个客户端都位于同一个NAT之后，那么发往私有地址的数据包应该先于发往公网地址的数据包到达，这样就建立了一个不包括NAT的直连通信通道。如果两个客户端位于不同NAT之后，虽然发送到对方私有地址的数据包会毫无疑问的发送失败，但还是很有可能使用他们各自的公网IP地址来建立一条通信通道的。所以检测这些数据包的方法和工作就变得非常重要，不论如何，只要双方都处于不同NAT之后，就完全有可能 Client A 想发送到 Client B 的信息会被发到别的无关的地方去，反之亦然（Client B 想发送到 Client A的消息也会被发到别的无关的地方去）。

(最后一句“unrelated node on A's private network”没有完全理解是什么意思，总之，放到整个语境中，应该就是说，Client A 瞄准 Client B的私有地址端口的信息会被NAT转发到别的地方去，因为两者处于不同的NAT之后，NAT A 如果在 内部网络找到了一个拥有与Client B相同的私有地址的电脑，就会把信息发送过去，这样，就根本不会发送到 Client B 上去)

3.3.3. Peers separated by multiple NATs 客户端分别处于多层NAT之后

在有些网络拓扑中就存在多层NAT设备，如果不熟悉网络拓扑的知识，要想建立一条“理想的”端对端连接基本上是不可能的。让我们来看看下图这种情况：
Server S
18.181.0.31:1234
|
|
NAT X
A-S 155.99.25.11:62000
B-S 155.99.25.11:62001
|
|
+----------------------+----------------------+
| |
NAT A NAT B
192.168.1.1:30000 192.168.1.2:31000
| |
| |
Client A Client B
10.0.0.1:1234 10.1.1.3:1234

假如 NAT X 是由 Internet服务供应商（ISP） 配置的一个 大型工业 NAT，它使用少量的公网IP地址来为一些客户群提供服务；NAT A 和 NAT B 则是为ISP的两个客户群所配置的小一点的独立NAT网关，它们为各自客户群的私人家庭网络提供IP地址。只有 Server S 和NAT X 拥有 公网固定IP地址，而NAT A 和 NAT B所拥有的“公网”IP地址对于ISP的寻址域来说则实际上“私有”的，这时 Client A的地址对于NAT A的寻址领域来说是“私有”的，Client B的地址对于NAT B的寻址域来说同样是“私有”的。
还是跟以前一样，每个客户端都建立了一个“外出”的连接到服务器S，导致NATA 和 NAT B 分别进行一次 公有/私有 转换，并导致 NAT X 为 每个 会话都建立了一个 公有/私有 的转换。（也就是把私有地址转换成为公网地址的过程，NAT的本质工作）

现在让我们假设 Client A 和 Client B 想要建立一条 端对端 的UDP 直连。理想的方法应该是 Client A 发送一条 信息到 Client B 在NAT B的公网地址192.168.1.2:31000上,这个地址在ISP的寻址域内；同时 Client B也发送一条消息到Client A 在 NAT B的公网地址上，也就是192.168.1.1:30000；如果能这样发的话，问题就解决了。可惜Client A和 Client B根本就不可能知道对方的这个地址，因为Server S只记录了他们真正的公网地址155.99.25.11:62000和155.99.25.11:62001。即使 Client A 和 Client B 通过某种途径得知了这些地址，还是不能够保证这样就能进行通话了，因为这些地址是由ISP的私有寻址域分配的，可能会与私有域所分配的其他无关客户端地址相冲突因此，如果客户端之间想要进行端对端的通信的话，别无选择，只能通过他们真正的公网地址来进行；并且 NAT X必须还得支持 “loopback translation”才行。

3.3.4. Consistent port bindings 保持端口绑定

在使用“UDP打洞技术”时有一点必须要注意：它只能在双方的NAT都是cone NAT（或者干脆没有NAT）时才能正常工作；这些NAT在自己的公网UDP端口被使用时保持着端口的绑定——[私有IP，私有UDP端口]对和[公网 IP，公网UDP端口]对的一一对应。如果像 symmetricNAT那样给每个新的会话都分配一个新的公网端口，那么UDP应用程序想要与其他外部客户端进行通话，就无法重复使用已经建立好的通信转换。
伴随着 cone NAT 的推广，“UDP打洞技术”也被越来越广泛的应用。然而，仍存在一小部分使用 symmetric NAT 的网络，那么在这小部分网络环境中，就不能使用“UDP打洞技术”。

（注：因为我国的国情，网络技术应用得比较晚，所以可以说绝大部分的网络都是cone NAT，所以 UDP打洞技术基本上可以畅通无阻的使用，只是还要注意对NAT是否支持“loopback translation”的测试）

3.4. UDP port number prediction UPD端口号预言

让我们来考虑这样一种情况，有两个客户端 A 和 B，他们都藏在不同的NAT后面，他们都开放了一个UDP连接给具有固定IP的Server S：如下图
Server S
18.181.0.31:1234
|
|
+----------------------+----------------------+
| |
Symmetric NAT A Symmetric NAT B


NAT A 分配了它自己的UDP端口62000，用来保持 客户端A 与 服务器S 的通信会话， NAT B 也分配了31000端口，用来保持 客户端B 与 服务器S 的通信会话。通过与 服务器S的对话，客户端A 和 客户端B 都相互知道了对方所映射的真实IP和端口。
客户端A发送一条UDP消息到 138.76.29.7:31001(请注意到端口号的增加)，同时 客户端B发送一条UDP消息到 155.99.25.11:62001。如果NAT A 和NAT B继续分配端口给新的会话，并且从A-S和B-S的会话时间消耗得并不多的话，那么一条处于客户端A和客户端B之间的双向会话通道就建立了。
客户 端A发出的消息送达B导致了NAT A打开了一个新的会话，并且我们希望 NAT A将会指派62001端口给这个新的会话，因为62001是继62000后，NAT会自动指派给从服务器S到客户端A之间的新会话的端口号；类似的，客户端B发出的消息送达A导致了 NAT B打开了一个新的会话，并且我们希望 NAT B 将会指派31001这个端口给新的会话；如果两个客户端都正确的猜测到了对方新会话被指派的端口号，那么这个客户端A－客户端B的双向连接就被打通了。其结果如下图所示：
A-S 155.99.25.11:62000 B-S 138.76.29.7:31000
| |
| |
Client A Client B
10.0.0.1:1234 10.1.1.3:1234

明显的，有许多因素会导致这个方法失败：如果这个预言的新端口（62001和31001）恰好已经被一个不相关的会话所使用，那么NAT就会跳过这个端口号，这个连接就会宣告失败；如果两个NAT有时或者总是不按照顺序来生成新的端口号，那么这个方法也是行不通的。

如 果隐藏在NAT A后的一个不同的客户端X（或者在NAT B后）打开了一个新的“外出”UDP 连接，并且无论这个连接的目的如何；只要这个动作发生在 客户端A 建立了与服务器S 的连接之后，客户端A 与 客户端B 建立连接之前；那么这个无关的客户端X 就会趁人不备地“偷” 到这个我们渴望分配的端口。所以，这个方法变得如此脆弱而且不堪一击，只要任何一个NAT方包含以上碰到的问题，这个方法都不会奏效。