1. NAT简介

现如今由于IPv4的公网地址已经处理匮乏的状态，而家家户户需要上网的电脑数量正在急剧上升，导致IPv4的公网地址无法满足需求量，NAT正是为了解决这个问题而诞生的。NAT（Network Address Translation）即网络地址转换，其主要作用是将私有内网地址与公网地址进行转换，使局域网内的多台计算机可以共用同一个公网地址进行Internet上的连接，如图1所示。

图1 NAT连接图

其中，NAT路由器中维护了如表1所示的地址映射表。

表1 地址映射表

私网地址	公网地址
192.168.1.1:7777	123.1.2.1:7000
192.168.1.2:8888	123.1.2.1:7001
192.168.1.3:9999	123.1.2.1:7002

例如，内网地址为192.168.1.1:7777的设备1要访问部署在公网的服务器，其IP地址为111.0.0.1，则内网主机经过NAT路由时，会将192.168.1.1:7777转换为123.1.2.1:7000，再与111.0.0.1进行通信。111.0.0.1发回的消息在经过NAT路由器时，会将目的地址123.1.2.1:7000转换为192.168.1.1:7777发送到本地主机设备1中。这样，多台主机的不同应用分别映射到同一公网地址的不同端口中，使用一个公网地址与外界通信，达到了节约公网IP地址的目的。

1.1. 实现方式

1.1.1. 静态NAT

将特定的公网地址和端口号一对一的映射到特定的私网地址和端口号，且此时的私网地址是确定的，即一个私有IP地址固定映射到一个公有IP地址。这种方法主要用在内部网络中有对外提供服务的服务器，如WEB、MAIL服务器时。

该方法的缺点是需要独占宝贵的合法IP地址。即，如果某个合法IP地址已经被NAT静态地址转换定义，即使该地址当前没有被使用，也不能被用作其它的地址转换。

1.1.2. 动态NAT

动态地址转换也是将私网地址与公网地址进行一对一的转换。但是，是随机从已定义的公网地址池中动态地选择一个未使用的地址与私网地址进行转换。当数据传输完毕后，路由器将把使用完的公网地址放回到地址池中，以供其它私网进行转换。但是在该地址被使用时，不能用该地址再进行一次转换。

1.1.3. 动态NAPT

NAPT即网络地址端口转换，首先是一种动态地址转换。路由器将通过记录地址、应用程序端口唯一标识一个转换。通过这种转换，可以使多个私网地址同时与同一个公网地址进行转换并对外部网络进行访问，图2-1所示的NAT路由即为这种转换方式。对于只申请到少量IP地址甚至只有一个合法IP地址，却经常有很多用户同时要求上网的情况，这种转换方式非常有用。

1.2. NAT的分类

NAT的实现方式定义了如何建立私网地址和公网地址的映射关系。在确定完地址映射关系后，RFC3489还根据内外网主机通信的方式，进一步将NAT分为四大类：分别为完全锥形NAT（Full Cone NAT）、限制锥形NAT（Restricted Cone NAT）、端口限制锥形NAT（Port Restricted Cone NAT）、对称NAT（Symmetric NAT）。

1.2.1. 完全锥形NAT

完全锥形NAT将来自同一个内网主机的地址和端口转换为同一个公网地址和端口，且不会因为应用程序的不同而转换为不同的外部端口。同时，当内外网的二元组映射关系建立以后，所有外部主机都可以通过该公网地址和端口向该内网主机发送消息，即不限制消息的来源。这种方式实现简单，但是由于对报文来源不做任何限制，安全性不足。

图2 完全锥形NAT

1.2.2. 限制锥形NAT

限制锥形NAT是完全锥形NAT的一个受限版本，同样是将来自同一个内网主机的地址和端口转换为同一个公网地址和端口，而不管应用程序的类型。其不同之处在于，只有内网主机主动发送消息到达的外网主机才能与该内网主机通过该公网地址和端口进行通信，其他内网主机未发送请求等消息的外网主机无法与其进行通信。即对消息来源的IP进行限制，但不限端口。

 图3 限制锥形NAT

1.2.3. 端口限制锥形NAT

端口限制锥形NAT和限制锥形NAT类似，但是多了端口的限制。只有当内网主机发送消息到达的外部主机的地址和端口才能与该内网主机进行通信，而该外部主机其他端口所发往内部主机的消息依然会被NAT路由丢弃。

图4 端口限制锥形NAT

1.2.4. 对称NAT

这种类型实现的NAT不同于上述三种锥形NAT，该方式在同一个本地主机每次与外网不同主机进行通信时，都会重新建立一个会话，使用不同的端口进行通信。 

图5 对称NAT

如图5中，内网PC对外网PC1和PC3的同一个应用程序（端口9200）发送消息时，对称NAT会将其映射到不同的端口进行通信。

1.3. NAT的影响

NAT虽然完美的解决了IP地址不足的问题，但它仍然存在一些缺陷。因为NAT中有着这样一个机制，所有外界设备对内网主机发出的请求，到达NAT设备后，都会被丢弃。因此，当我们处于NAT设备后面时，所有外界请求的数据都无法到达本机，这就是NAT墙的影响。

要解决NAT墙带来的影响，可以采用打洞的方式：首先让内网主机A发送一条消息给要访问的外网主机B，这样在A的NAT中会留下一个主机B的洞，表示B可以通过这个洞与A进行数据交互。若B也处于NAT设备后面，此时虽然A的这条消息被丢弃了，但是之后B再发送消息给A，则双方就可以正常进行通信了。而要如何协调进行打洞并实现P2P通信，则需要使用到STUN和TURN协议。

2. NAT穿越的解决方案

早期NAT穿越的解决方案使用的是STUN和TURN协议协调配合的方式，需要对NAT类型进行判断后再使用打洞或转发方式进行通信；而ICE协议整合了STUN和TURN协议的方案，无需对NAT类型进行判断。接下来将分别对两种解决方案进行简单的介绍。

2.1. STUN和TURN协议

STUN协议的主要作用是获取服务器或客户端的反射地址和端口号，即通过NAT转换后的公网地址和端口号。STUN中只定义了一个binding方法，可以用于请求/响应类型和指示类型。用于请求/响应类型时，可以获取服务器或客户端的具体绑定的地址；用于指示类型时，可以保持该绑定的激活状态。

TURN协议是STUN协议的一个扩展，主要是当通信双方处于NAT后面，在一些特殊的情形下（例如对称型NAT），无法使用打洞的方式进行NAT穿越时，便需要一个中继进行转发来保持通信，TURN便是这个转发协议。转发的方式虽然加重了服务器负担，但却能保证在最坏的情况下进行通信，同时还不受NAT类型的影响。

早期的RFC3489中定义的STUN协议是作为一个NAT穿越的完整解决方案，其还具有判断NAT类型的作用。利用STUN和TURN协议的协调配合，进行打洞或者转发的方式建立通信双方的连接。具体操作可总结为：

首先假设A、B为通信双方的客户端，C为STUN服务器，C中有两个IP地址分别为IP1和IP2。

（1）获取NAT类型

① A首先给C的IP1和端口1发送UDP包，C在收到该包后，会记录下源IP和端口然后发送一个UDP响应包给A，此时包里面的IP和端口便是NAT外网IP和端口。A在收到包后，将包里的IP和端口与自己发送的IP和端口进行比较，如果相同则说明没有NAT的存在，那么双方不需要进行NAT穿越便可直接通信；如果不同则说明A此时在NAT设备后面，便继续进行第2步的操作。

② A向C的IP1和端口发送一个包，请求C通过IP2和端口发回一个包给A。若此时A收到这个包，则说明A处于完全锥形NAT后面。若没有收到，则进行第3步操作。

③ A向C的IP2和端口2发送一个UDP包，C收到后记录下源IP和端口然后通过IP2和端口2发送给A。A收到包后将该端口和步骤①中获取的端口号进行对比，若相同则处于限制锥形或端口限制锥形NAT设备后面，不同则处于对称NAT后面。因此根据2.1.3.4节对称NAT的描述可知，当目的主机的IP为一个新的IP时，NAT会开启一个新的端口进行发送。

④ 若判断出NAT设备为限制锥形后，A向C的IP2和一个端口发送UDP包，要求C用IP2和另一个端口发回UDP包。若A收到了UDP包，则说明NAT类型为限制锥形NAT；若没有收到UDP包，则说明NAT类型为端口限制锥形NAT。

通过以上四个步骤，便可以完全确定A是否处于NAT设备后面与NAT设备的类型了。

（2）通信处理

① 若A处于完全锥形NAT后面，则其他客户端可以直接与其进行通信。

② 若A处于限制锥形或端口限制锥形NAT后面，则协调TURN服务器进行打洞。通过TURN服务器命令A发送信令给客户端B进行打洞，从而实现通信。

③ 若A处于对称NAT下，由于STUN获取的A的公网端口和A与B通信时的公网端口是不同的，因此无法通过打洞进行通信。此时，采用TURN服务器进行转发的方式实现通信。

2.2. ICE协议

现如今的网络类型纷繁复杂，在有些多层NAT类型的情况下，采用STUN的方法有时无法探测出NAT的类型。因此一个不需要探测NAT类型、更加高效的NAT穿越方法便应运而生，即ICE。ICE的全称为Interactive Connectivity Establishment,即交互式连接建立。他是综合STUN和TURN两种协议方案，通过通信双方互相发探测包，找出一种最合理，最廉价的可行路径。在ICE架构下，SRUN不需要判断NAT类型，只作为一个辅助工具提供反射地址，并将其加入ICE Candidate候选中。因此在RFC5389中STUN协议去掉了NAT类型的判断的能力。

ICE建立连接的流程如图6所示：

图6 ICE建立连接时序

2.2.1. 收集候选地址

ICE建立连接首先要收集所有可能的候选地址，候选地址包括本地主机地址、STUN服务器获取的反射地址（即公网地址）、中继地址。通过与STUN/TURN服务器的交互，可以将所有候选地址加入到ICE candidate中。

2.2.2. Offer/Answer

收集完候选地址后，便需要将这些候选地址通过某种特定的消息协议发送给对端，FreeSWITCH中通过在sdp中加入相应的candidate字段发送给对端。获取到对端的候选地址后，便将其保存下来，以便后续逐一对这些地址的连通性进行测试。

2.2.3. STUN检查

保存的候选地址是对端所有可以进行连接的地址，接下来便开始按顺序对这些地址的连通性进行检查。检查的过程即请求端首先发送STUN Binding Request消息给对端，等待对端返回STUN Binding Response的确认消息。

2.2.4. 启动媒体

此时客户端中会维护一个连接状态表，表中是所有可连通的连接地址，同时还会对该状态表进行排序。排序的依据标准是将计算的“成本”最低的排在第一位，而成本则考虑各种因素的综合来计算，例如根据发送STUN请求和接收STUN应答的往返时间计算，时间约短则成本越低等等。
当A有视频rtp数据要发送时，它检查状态表的第一条记录，如果判断出它的状态是发送就绪，就会用此connection进行发送。否则直接放弃这个发送任务。

2.2.5. 长连接

为了确保NAT映射和过滤规则不在媒体会话期间超时，ICE会不断对使用中的候选项对发送STUN消息进行连通性检查。即对状态表中所有的记录，每隔一段时间就要发送一个Stun Binding Request消息，如果检测到本来是畅通的Connection上Stun Binding Response应答超时了，那它就会更改该Connection状态，执行连接状态表排序时就有可能会向下掉，严重时会从状态表删除该记录。记录被删除后，如果之后该候选地址的连接又恢复了，则会基于该候选地址重新创建Connection。