理解NAT穿透(UDP打洞)-FreeOA

理解NAT穿透(UDP打洞)

2018-08-24 19:35:15

阿炯

1、NAT(Network Address Translator)介绍

NAT有两大类，基本NAT和NAPT。

1.1、基本NAT

静态NAT：一个公网IP对应一个内部IP，一对一转换

动态NAT：N个公网IP对应M个内部IP，不固定的一对一转换关系

1.2、NAPT(Network Address/Port Translator)

现在基本使用这种，又分为对称和锥型NAT。

锥型NAT，有完全锥型、受限制锥型、端口受限制锥型三种：

a)Full Cone NAT(完全圆锥型)：从同一私网地址端口192.168.0.8:4000发至公网的所有请求都映射成同一个公网地址端口1.2.3.4:62000 ，192.168.0.8可以收到任意外部主机发到1.2.3.4:62000的数据报。

b)Address Restricted Cone NAT (地址限制圆锥型)：从同一私网地址端口192.168.0.8:4000发至公网的所有请求都映射成同一个公网地址端口1.2.3.4:62000，只有当内部主机192.168.0.8先给服务器C 6.7.8.9发送一个数据报后，192.168.0.8才能收到6.7.8.9发送到1.2.3.4:62000的数据报。

c)Port Restricted Cone NAT(端口限制圆锥型)：从同一私网地址端口192.168.0.8:4000发至公网的所有请求都映射成同一个公网地址端口1.2.3.4:62000，只有当内部主机192.168.0.8先向外部主机地址端口6.7.8.9：8000发送一个数据报后，192.168.0.8才能收到6.7.8.9：8000发送到1.2.3.4:62000的数据报。

对称NAT：

把所有来自相同内部IP地址和端口号，到特定目的IP地址和端口号的请求映射到相同的外部IP地址和端口。如果同一主机使用不同的源地址和端口对，发送的目的地址不同，则使用不同的映射。只有收到了一个IP包的外部主机才能够向该内部主机发送回一个UDP包。对称的NAT不保证所有会话中的(私有地址，私有端口)和(公开IP，公开端口)之间绑定的一致性。相反，它为每个新的会话分配一个新的端口号。

对称NAT是一个请求对应一个端口，非对称NAT是多个请求对应一个端口(象锥形，所以叫Cone NAT)。

1.3、检测NAT类型：

连接服务器为A，NAT检测服务器为B。

第一步：当一个接收客户端(Endpoint-Receiver ,简称 EP-R)需要接收文件信息时，在其向连接服务器发送文件请求的同时紧接着向检测服务器发送NAT检测请求。此处再次强调是“紧接着”，因为对于对称型NAT来说，这个操作可以直接算出其地址分配的增量(⊿p)。

第二步：当EP-R收到A或B的反馈信息时发现其外部地址与自身地址不同时就可以确定自己在NAT后面；否则，就是公网IP。

第三步：由服务器A向B发送其获得的EP-R的外部映射地址(IPa/Porta)，服务器B获得后进行比较，如果端口不同，则说明这是对称型NAT，同时可以直接计算出其分配增量：
⊿p=Portb-Porta

第四步：如果端口号相同，则由B向EP-R的Porta发送连接请求，如果EP-R有响应，则说明EP-R没有IP和Port的限制，属于全ConeNAT类型。

第五步：如果没有响应，则由服务器B使用其新端口b’向EP-R的Portb端口发送连接请求，如果有响应，则说明EP-R只对IP限制，属于限制性ConeNAT类型；否则就是对IP和port都限制，属于端口限制性ConeNAT类型。

通过上述五步基本可以全部检测出EP-R是否在公网，还是在某种NAT后面。

1.4、NAT映射老化时间

这也是一项可选配置任务，可根据需要为NAT 地址映射表配置老化时间，以控制用户对NAT 配置的使用，确保内、外网的通信安全。

配置NAT 地址映射表项老化时间的方法也很简单，只须在系统视图下使用firewall-nat session { dns | ftp | ftp-data | http | icmp | tcp | tcp-proxy | udp | sip | sip-media | rtsp |rtsp-media }aging-time time-value 命令配置即可。参数 time-value的取值范围为1～65 535的整数秒。如果要配置多个会话表项的超时时间需要分别用本命令配置。

缺省情况下，各协议的老化时间为：DNS(120 s)、ftp(120 s)、ftp-data(120 s)、HTTP(120 s)、icmp(20 s)、tcp(600 s)、tcp-proxy(10 s)、udp(120 s)、sip(1 800 s)、sip-media ( 120 s )、rtsp ( 60 s )、rtsp-media ( 120 s )，可用undo firewall-natsession { all | dns | ftp | ftp-data | http | icmp | tcp | tcp-proxy | udp | sip | sip-media | rtsp |rtsp-media } aging-time 命令恢复对应会话表项的超时时间为缺省值。

2、UDP打洞

2.1、p2p可实现的条件需要：

1、中间服务器保存信息、并能发出建立UDP隧道的命令

2、网关均要求为Cone NAT类型。Symmetric NAT不适合。

3、完全圆锥型网关可以无需建立udp隧道，但这种情况非常少，要求双方均为这种类型网关的更少。

4、假如X1网关为Symmetric NAT， Y1为Address Restricted Cone NAT 或Full Cone NAT型网关，各自建立隧道后，A1可通过X1发送数据报给Y1到B1(因为Y1最多只进行IP级别的甄别)，但B2发送给X1的将会被丢弃(因为发送来的数据报中端口与X1上存在会话的端口不一致，虽然IP地址一致)，所以同样没有什么意义。

5、假如双方均为Symmetric NAT的情形，新开了端口，对方可以在不知道的情况下尝试猜解，也可以达到目的，但这种情形成功率很低，且带来额外的系统开支，不是个好的解决办法。

6、不同网关型设置的差异在于，对内会采用替换IP的方式、使用不同端口不同会话的方式，使用相同端口不同会话的方式；对外会采用什么都不限制、限制IP地址、限制IP地址及端口。

7、这里还没有考虑同一内网不同用户同时访问同一服务器的情形，如果此时网关采用AddressRestricted Cone NAT 或Full Cone NAT型，有可能导致不同用户客户端可收到别人的数据包，这显然是不合适的。

2.2、udp和tcp打洞

为什么网上讲到的P2P打洞基本上都是基于UDP协议的打洞？难道TCP不可能打洞？还是TCP打洞难于实现？
    假设现在有内网客户端A和内网客户端B，有公网服务端S。
    如果A和B想要进行UDP通信，则必须穿透双方的NAT路由。假设为NAT-A和NAT-B。

    A发送数据包到公网S,B发送数据包到公网S,则S分别得到了A和B的公网IP，S也和A B 分别建立了会话，由S发到NAT-A的数据包会被NAT-A直接转发给A，由S发到NAT-B的数据包会被NAT-B直接转发给B，除了S发出的数据包之外的则会被丢弃。所以：现在A B 都能分别和S进行全双工通讯了，但是A B之间还不能直接通讯。

    解决办法是：A向B的公网IP发送一个数据包，则NAT-A能接收来自NAT-B的数据包并转发给A了(即B现在能访问A了)；再由S命令B向A的公网IP发送一个数据包，则NAT-B能接收来自NAT-A的数据包并转发给B了(即A现在能访问B了)。

以上就是“打洞”的原理。

为了保证A的路由器有与B的session，A要定时与B做心跳包，同样，B也要定时与A做心跳，这样，双方的通信通道都是通的，就可以进行任意的通信了。

但是TCP和UDP在打洞上却有点不同。这是因为伯克利socket(标准socket规范)的API造成的。
    UDP的socket允许多个socket绑定到同一个本地端口，而TCP的socket则不允许。
    这是这样一个意思：A B要连接到S，肯定首先A B双方都会在本地创建一个socket，去连接S上的socket。创建一个socket必然会绑定一个本地端口(就算应用程序里面没写端口，实际上也是绑定了的，至少java确实如此)，假设为8888，这样A和B才分别建立了到S的通信信道。接下来就需要打洞了，打洞则需要A和B分别发送数据包到对方的公网IP。但是问题就在这里：因为NAT设备是根据端口号来确定session，如果是UDP的socket，A B可以分别再创建socket，然后将socket绑定到8888，这样打洞就成功了。但是如果是TCP的socket，则不能再创建socket并绑定到8888了，这样打洞就无法成功。

UDP打洞的过程大致如此：

1、双方都通过UDP与服务器通讯后，网关默认就是做了一个外网IP和端口号与你内网IP与端口号的映射，这个无需设置的，服务器也不需要知道客户的真正内网IP

2、用户A先通过服务器知道用户B的外网地址与端口

3、用户A向用户B的外网地址与端口发送消息

4、在这一次发送中，用户B的网关会拒收这条消息，因为它的映射中并没有这条规则。

5、但是用户A的网关就会增加了一条允许规则，允许接收从B发送过来的消息

6、服务器要求用户B发送一个消息到用户A的外网IP与端口号

7、用户B发送一条消息，这时用户A就可以接收到B的消息，而且网关B也增加了允许规则

8、之后，由于网关A与网关B都增加了允许规则，所以A与B都可以向对方的外网IP和端口号发送消息。

TCP打洞技术：

tcp打洞也需要NAT设备支持才行。tcp的打洞流程和udp的基本一样，但tcp的api决定了tcp打洞的实现过程和udp不一样。

tcp按cs方式工作，一个端口只能用来connect或listen，所以需要使用端口重用，才能利用本地nat的端口映射关系。(设置SO_REUSEADDR，在支持SO_REUSEPORT的系统上，要设置这两个参数。)

连接过程：(以udp打洞的第2种情况为例(典型情况))
nat后的两个peer，A和B，A和B都bind自己listen的端口，向对方发起连接(connect)，即使用相同的端口同时连接和等待连接。因为A和B发出连接的顺序有时间差，假设A的syn包到达B的nat时，B的syn包还没有发出，那么B的nat映射还没有建立，会导致A的连接请求失败(连接失败或无法连接，如果nat返回RST或者icmp差错，api上可能表现为被RST；有些nat不返回信息直接丢弃syn包(反而更好))，(应用程序发现失败时，不能关闭socket，closesocket()可能会导致NAT删除端口映射；隔一段时间(1-2s)后未连接还要继续尝试)；但后发B的syn包在到达A的nat时，由于A的nat已经建立的映射关系，B的syn包会通过A的nat，被nat转给A的listen端口，从而进去三次握手，完成tcp连接。

从应用程序角度看，连接成功的过程可能有两种不同表现：(以上述假设过程为例)
1、连接建立成功表现为A的connect返回成功。即A端以TCP的同时打开流程完成连接。
2、A端通过listen的端口完成和B的握手，而connect尝试持续失败，应用程序通过accept获取到连接，最终放弃connect(这时可closesocket(conn_fd))。

多数Linux和Windows的协议栈表现为第2种。

但有一个问题是，建立连接的client端，其connect绑定的端口号就是主机listen的端口号，或许这个peer后续还会有更多的这种socket。虽然理论上说，socket是一个五元组，端口号是一个逻辑数字，传输层能够因为五元组的不同而区分开这些socket，但是是否存在实际上的异常，还有待更多观察。

2.3、另外的问题

1、Windows XP SP2操作系统之前的主机，这些主机不能正确处理TCP同时开启，或者TCP套接字不支持SO_REUSEADDR的参数。需要让AB有序的发起连接才可能完成。

上述tcp连接过程，仅对NAT1、2、3有效，对NAT4(对称型)无效。由于对称型nat通常采用规律的外部端口分配方法，对于nat4的打洞，可以采用端口预测的方式进行尝试。

2.4、一些常用技术

ALG(应用层网关)：它可以是一个设备或插件，用于支持SIP协议，主要类似与在网关上专门开辟一个通道，用于建立内网与外网的连接，也就是说，这是一种定制的网关。更多只适用于使用他们的应用群体内部之间。

UpnP：它是让网关设备在进行工作时寻找一个全球共享的可路由IP来作为通道，这样避免端口造成的影响。要求设备支持且开启upnp功能，但大部分时候，这些功能处于安全考虑，是被关闭的。即时开启，实际应用效果还没经过测试。

STUN(Simple Traversalof UDP Through Network)：这种方式即是类似于我们上面举例中服务器C的处理方式。也是目前普遍采用的方式。但具体实现要比我们描述的复杂许多，光是做网关Nat类型判断就由许多工作，RFC3489中详细描述了。

TURN(Traveral Using Relay NAT)：该方式是将所有的数据交换都经由服务器来完成，这样NAT将没有障碍，但服务器的负载、丢包、延迟性就是很大的问题。目前很多游戏均采用该方式避开NAT的问题。这种方式不叫p2p。

ICE(Interactive Connectivity Establishment)：是对上述各种技术的综合，但明显带来了复杂性。

详述UDP打洞穿透NAT

路由穿透，实现广域网P2P通讯。有4种典型NAT类型，按照NAT设备在进行地址映射时行为的不同，NAT可以分为以下四种：
Full Cone
Restricted Cone
Port Restricted Cone
Symmentric

几种现代穿透协议

STUN

STUN协议为终端提供一种方式能够获知自己经过NAT映射后的地址，从而替代位于应用层中的私网地址，达到NAT穿透的目的。STUN协议是典型的Client-Server协议，各种具体应用通过嵌入STUN客户端与STUN Server端通讯来完成交互。

在典型的运用STUN进行NAT穿透的场景中，STUN客户端首先向位于公网上的STUN服务器发送Binding Request消息，STUN服务器接收到请求消息后识别出经过NAT转换后的公网地址60.1.1.1:12345，将其附加在Binding Response消息中返回给客户端。客户端得到这个地址后用它替换SDP中的私网地址与终端B完成媒体协商。使用STUN进行NAT穿透对应用的要求是必须使用同样的端口与STUN服务器交互和进行应用层通讯，比如当希望使用端口 37000进行RTP包的NAT穿透时，必须同样使用37000端口与STUN服务器通讯，否则从STUN 服务器获得的NAT映射后的地址一般与实际地址时不一样的。另一个要求是STUN客户端与服务器端的通讯和应用使用获得的NAT映射地址进行应用层通讯在时间上必须有连贯性，这源于NAT设备建立的绑定有生存时间，当原绑定消亡后，NAT设备为同一个私网地址建立的新绑定往往不同，因此转换后的公网地址是不同的。

STUN方案的特性如下表：

特性-|-说明
实现复杂度-|-实现简单
TCP穿透支持-|-不支持
对现有设备的要求-|-要求客户端支持，对现有NAT设备无改动要求，需增加STUN服务器
可扩展性-|-可扩展性好，与具体协议无关
安全性-|-一般
健壮性-|-差，不支持symmentric型NAT
其他-|-支持自动检测NAT类型，使用户即使在使用STUN协议无法实现NAT，穿透时还可以根据NAT类型自主选择其他可使用的NAT穿透方案

TURN

TURN解决NAT穿透的思路与STUN类似，都是通过修改应用层中的私网地址达到NAT穿透。与STUN不同的是，TURN是通过两方通讯的“中间人”的方式实现穿透，在这种方式下，要进行通讯的两方分别与位于公网上的TURN服务器建立各自的连接进行通讯，由服务器负责在两方之间进行数据转发。要达到这个目的，实现TURN客户端的终端必须在通讯开始前与TURN服务器进行交互，得到服务器为其临时分配的位于TURN服务器上的公网地址，客户端使用它替换位于应用层中的私网地址。

TURN方案的特性如下表：

特性-|-说明
实现复杂度-|-难于实现，TURN的安全性设计增加终端设置的复杂度
TCP穿透支持-|-支持
对现有设备的要求-|-对现有NAT设备无要求，要求客户端支持，需增加TURN服务器
可扩展性-|-可扩展性好，与具体协议无关
安全性-|-一般
健壮性-|-好，支持所有类型的NAT
其他-|-与P2P穿透方式相比，性能时relay穿透方式的弱点。另外TURN无法实现负载分担，解决的方式是把media relay服务器的分配工作放在 SIP proxy完成

ICE

与STUN和TURN相比，ICE并非是解决NAT穿透问题的协议，而是一个框架，在这个框架中，可以整合其他现存的NAT穿透协议，如STUN、TURN、RSIP等。区别于其他的NAT穿透解决方案，ICE是一种探索和更新式的解决方案，通过搜集自身和对端尽可能多的网络信息(各种网络地址)，尝试在这些地址间建立数据通道，并在这一过程中不断更新先前收集到的信息，从而找出和选择能够进行NAT穿透的数据通道。

STUN服务器采用免费的公用STUN服务器，具体STUN服务器列表在此。

参考来源：

NAT穿透(UDP打洞)

试验UDP打洞穿透NAT