NAT实现原理

按照NAT设备在进行地址映射时行为的不同，NAT可以分为以下四种：

1. Full Cone 

2. Restricted Cone 

3. Port Restricted Cone 

4. Symmentric 

     

  目前主要的NAT类型有如下几种：

  1)Full-cone NAT, also known as one-to-one NAT

• 一旦一个内网地址 (iAddr:iPort) 被映射到一个外部地址 (eAddr:ePort), 来自 iAddr:iPort 的任何数据包将通过 eAddr:ePort 发送.
• 任何外部主机能够通过eAddr:ePort这个地址发送数据包到iAddr:iPort.

  2)Address-restricted-cone NAT

• 一旦一个内网地址 (iAddr:iPort) 被映射到一个外部地址 (eAddr:ePort), 来自 iAddr:iPort 的任何数据包将通过 eAddr:ePort 发送.
• 仅只有接收到主机(iAddr:iPort)通过eAddr:ePort发送的数据包的外部主机通过该主机的任何端口发送到eAddr:ePort的数据包才能够被正确的转发到iAddr:iPort.也就是说主机有关端口无关.

  3)Port-restricted cone NAT

  类似于address restricted cone NAT, 但是端口号有限制.

• 一旦一个内网地址 (iAddr:iPort) 被映射到一个外部地址 (eAddr:ePort), 来自 iAddr:iPort 的任何数据包将通过 eAddr:ePort 发送.
• 仅只有接收到主机(iAddr:iPort)通过eAddr:ePort发送的数据包的外部主机通过该主机的相同端口发送到eAddr:ePort的数据包才能够被正确的转发到iAddr:iPort.

  4)Symmetric NAT

• 来自相同内部ip和port发送到相同目的地ip和port的请求被映射到唯一的外部ip和port地址；如果相同的内部主机采用相同的ip和port地址发送到不同的目的地，那么重新分配映射地址。
• 只有先前收到内部主机发送的包的外部主机才能够发送返回包到内部主机。

  针对前面三种NAT类型（即cone NAT）只要通信双方彼此知道对方的内部地址和外部地址的映射关系，然后通过UDP打洞的方式就可以建立相互连接的通信；但是第四种也就是Symmetric NAT的话由于每次向不同目的地发送数据包时采用不同的外部地址，也就没办法通过直接的方式建立P2P连接。

对称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)：是对上述各种技术的综合，但明显带来了复杂性。

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服务器s
可扩展性	可扩展性好，与具体协议无关
安全性	一般
健壮性	好，支持所有类型的NAT
其他	与P2P穿透方式相比，性能时relay穿透方式的弱点。另外TURN无法 实现负载分担，解决的方式是把media relay服务器的分配工作放在 SIP proxy完成

ICE

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

ICE方案的特性如下表：

特性	说明
实现复杂度	一般
TCP穿透支持	支持
对现有设备的要求	对NAT设备无要求，支持所有类型的NAT设备。客户端必须支持， 网路结构中需增加STUN/TURN服务器
可扩展性	可扩展性好，与具体协议无关
安全性	较好
健壮性	好，适用与所有NAT及NAT拓扑类型，且由于存在中继服务器，NAT 穿透一般总是能成功
其他

其他技术

---

 

参考与引用：

http://pennlee.blog.163.com/blog/static/5259930200752511814652/

https://www.zhihu.com/question/38729355/answer/86531260

http://blog.csdn.net/byxdaz/article/details/52785697

 http://book.51cto.com/art/201408/449058.htm

http://blog.csdn.net/weiyuefei/article/details/52247497