Stun协议实现

在现实Internet网络环境中，大多数计算机主机都位于防火墙或NAT之后，只有少部分主机能够直接接入Internet。很多时候，我们希望网络中的两台主机能够直接进行通信（即所谓的P2P通信），而不需要其它公共服务器的中转。由于主机可能位于防火墙或NAT之后，在进行P2P通信之前，我们需要进行检测以确认它们之间能否进行P2P通信以及如何通信。这种技术通常被称为NAT穿透（NAT Traversal）。最常见的NAT穿透是基于UDP的技术（如下面的RFC3489/STUN），也有基于TCP的穿透技术。NAT穿透技术最重要的是识别目标主机的NAT类型，这也是本文所要介绍的内容。

NAT介绍

nat.png

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

基本NAT

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

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

NAPT（Network Address/Port Translator）

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

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

Full Cone NAT（完全圆锥型）：从同一私网地址端口192.168.0.8:4000发至公网的所有请求都映射成同一个公网地址端口1.2.3.4:62000 ，192.168.0.8可以收到任意外部主机发到1.2.3.4:62000的数据报。
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的数据报。
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类型

在RFC3489/STUN[1]中，基于UDP的NAT(Network Address Translation)穿透技术把主机划分为如下七种NAT类型：

UDP Blocked、Open Internet、Symmetric Firewall、Full Cone NAT、Restricted Cone NAT、Port Restricted Cone NAT、Symmetric NAT。具体解释如下：

（1）Open Internet：主机具有公网IP，允许主动发起和被动响应两种方式的UDP通信。

（2）UDP Blocked：位于防火墙之后，并且防火墙阻止了UDP通信。

（3）Symmetric Firewall：主机具有公网IP，但位于防火墙之后，且防火墙阻止了外部主机的主动UDP通信。

（4）Full Cone NAT：当内网主机创建一个UDP socket并通过它第一次向外发送UDP数据包时，NAT会为之分配一个固定的公网{IP:端口}。此后，通过这个socket发送的任何UDP数据包都是通过这个公网{IP:端口}发送出去的；同时，任何外部主机都可以使用这个公网{IP:端口}向该socket发送UDP数据包。即是说，NAT维护了一个映射表，内网主机的内网{IP:端口}与公网{IP:端口}是一一对应的关系。一旦这个映射关系建立起来（内部主机向某一外部主机发送一次数据即可），任何外部主机就可以直接向NAT内的这台主机发起UDP通信了，此时NAT透明化了。

（5）Restricted Cone NAT：当内网主机创建一个UDP socket并通过它第一次向外发送UDP数据包时，NAT会为之分配一个公网{IP:端口}。此后，通过这个socket向外发送的任何UDP数据包都是通过这个公网{IP:端口}发送出去的；而任何收到过从这个socket发送来的数据的外部主机（由IP标识），都可以通过这个公网{IP:端口}向该socket发送UDP数据包。即是说，NAT维护了一个内网{IP:端口}到公网{IP:端口}的映射，还维护了一个{外部主机IP, 公网{IP:端口}}到内网{IP:端口}的映射。因此，要想外部主机能够主动向该内部主机发起通信，必须先由该内部主机向这个外部发起一次通信。

（6）Port Restricted Cone NAT：当内网主机创建一个UDP socket并通过它第一次向外发送UDP数据包时，NAT会为之分配一个公网{IP:端口}。此后，通过这个socket向外部发送的任何UDP数据包都是通过这个公网{IP:端口}发送出去的；一旦外部主机在{IP:端口}上收到过从这个socket发送来的数据后，都可以通过这个外部主机{IP:端口}向该socket发送UDP数据包。即是说，NAT维护了一个从内网{IP:端口}到公网{IP:端口}的映射，还维护了一个从{外部主机{IP:端口}, 公网{IP:端口}}到内网{IP:端口}的映射。

（7）Symmetrict NAT：当内网主机创建一个UDP socket并通过它第一次向外部主机1发送UDP数据包时，NAT为其分配一个公网{IP1:端口1}，以后内网主机发送给外部主机1的所有UDP数据包都是通过公网{IP1:端口1}发送的；当内网主机通过这个socket向外部主机2发送UDP数据包时，NAT为其分配一个公网{IP2:端口2}，以后内网主机发送给外部主机2的所有UDP数据包都是通过公网{IP2:端口2}发送的。公网{IP1:端口1}和公网{IP2:端口2}一定不会完全相同（即要么IP不同，要么端口不同，或者都不同）。这种情况下，外部主机只能在接收到内网主机发来的数据时，才能向内网主机回送数据。

锥形NAT与对称NAT的区别

所谓锥形NAT 是指：只要是从同一个内部地址和端口出来的包，无论目的地址是否相同，NAT 都将它转换成同一个外部地址和端口。

“同一个外部地址和端口”与“无论目的地址是否相同”形成了一个类似锥形的网络结构，也是这一名称的由来。反过来，不满足这一条件的即为对称NAT 。

举例说明，假设：

NAT 内的主机 A ： IP 记为 A ，使用端口 1000

NAT 网关： IP 记为 NAT ，用于 NAT 的端口池假设为（ 5001-5999 ）

公网上的主机 B ： IP 记为B ，开放端口 2000

公网上的主机 C ： IP 记为C ，开放端口 3000

假设主机 A 先后访问主机 B 和 C

1 ）如果是锥形 NAT ：

那么成功连接后，状态必然如下：

A （ 1000 ） —— > NAT （ 5001 ）—— > B （ 2000 ）

A （ 1000 ） —— > NAT （ 5001 ）—— > C （ 3000 ）

也就是说，只要是从 A 主机的 1000 端口发出的包，经过地址转换后的源端口一定相同。

2 ）如果是对称形 NAT ：

连接后，状态有可能（注意是可能，不是一定）如下：

A （ 1000 ） —— > NAT （ 5001 ）—— > B （ 2000 ）

A （ 1000 ） —— > NAT （ 5002 ）—— > C （ 3000 ）

两者的区别显而易见。

三种CONE NAT之间的区别

仍然以上面的网络环境为例, 假设 A 先与 B 建立了连接:

A （ 1000 ） —— > NAT （ 5001 ）——— > B （ 2000 ）

1） Port Restricted Cone NAT:

只有 B （ 2000 ）发往 NAT （ 5001 ）的数据包可以到达 A （ 1000 ）

B （ 2000 ） —— > NAT （ 5001 ） ——— > A （ 1000 ）

B （ 3000 ） —— > NAT （ 5001 ） — X — > A （ 1000 ）

C （ 2000 ） —— > NAT （ 5001 ） — X — > A （ 1000 ）

该nat 将内网中一台主机的IP和端口映射到公网IP和一个指定端口，只有访问过的IP和端口可以通过映射后的IP和端口连接主机A

2） Restricted Cone NAT

只要是从 B 主机发往 NAT （ 5001 ）的数据包都可以到达 A （ 1000 ）

B （ 2000 ） —— > NAT （ 5001 ） ——— > A （ 1000 ）

B （ 3000 ） —— > NAT （ 5001 ） ——— > A （ 1000 ）

C （ 2000 ） —— > NAT （ 5001 ） — X — > A （ 1000 ）

该nat 将内网中一台主机的IP和端口映射到公网IP和一个指定端口，只有访问过的IP可以通过映射后的IP和端口连接主机A

3） Full Cone NAT

任意地址发往 NAT （ 5001 ）的数据包都可以到达 A （ 1000 ）

B （ 2000 ） —— > NAT （ 5001 ） ——— > A （ 1000 ）

B （ 3000 ） —— > NAT （ 5001 ） ——— > A （ 1000 ）

C （ 3000 ） —— > NAT （ 5001 ） ——— > A （ 1000 ）

该nat 将内网中一台主机的IP和端口映射到公网IP和一个指定端口，外网的任何主机都可以通过映射后的IP和端口发送消息

Linux的NAT

Linux的NAT“MASQUERADE”属于对称形NAT。说明这一点只需要否定 MASQUERADE 为锥形 NAT 即可。

linux 在进行地址转换时，会遵循两个原则：

尽量不去修改源端口，也就是说，ip 伪装后的源端口尽可能保持不变。

更为重要的是，ip 伪装后必须保证伪装后的源地址/ 端口与目标地址/ 端口（即所谓的socket ）唯一。

假设如下的情况（内网有主机 A 和 D ，公网有主机 B 和 C ）：

先后建立如下三条连接：

A （ 1000 ） —— > NAT （ 1000 ）—— > B （ 2000 ）

D （ 1000 ） —— > NAT （ 1000 ）—— > C （ 2000 ）

A （ 1000 ） —— > NAT （ 1001 ）—— > C （ 2000 ）

可以看到，前两条连接遵循了原则 1 ，并且不违背原则 2 而第三条连接为了避免与第二条产生相同的 socket 而改变了源端口比较第一和第三条连接，同样来自 A(1000) 的数据包在经过 NAT 后源端口分别变为了 1000 和1001 。说明 Linux 的 NAT 是对称 NAT 。

对协议的支持

CONE NAT 要求原始源地址端口相同的数据包经过地址转换后，新源地址和端口也相同，换句话说，原始源地址端口不同的数据包，转换后的源地址和端口也一定不同。

那么，是不是 Full Cone NAT 的可穿透性一定比 Symmetric NAT 要好呢，或者说，通过 Symmetric NAT 可以建立的连接，如果换成 Full Cone NAT 是不是也一定能成功呢？

假设如下的情况：

（内网有主机Ａ和Ｄ，公网有主机Ｂ和Ｃ，某 UDP 协议服务端口为 2000 ，并且要求客户端的源端口一定为 1000 。）

１）如果Ａ使用该协议访问Ｂ：

A （ 1000 ） —— > NAT （ 1000 ）——— > B （ 2000 ）

由于 Linux 有尽量不改变源端口的规则，因此在 1000 端口未被占用时，连接是可以正常建立的如果此时Ｄ也需要访问Ｂ：

D （ 1000 ） —— > NAT （ 1001 ）—Ｘ— > B （ 2000 ）

端口必须要改变了，否则将出现两个相同的 socket ，后续由 B(2000) 发往ＮＡＴ（ 1000 ）的包将不知道是转发给Ａ还是Ｄ。于是Ｂ将因为客户端的源端口错误而拒绝连接。在这种情况下， MASQUERADE 与 CONENAT 的表现相同。

２）如果Ａ连接Ｂ后，Ｄ也像Ｃ发起连接，而在此之后，Ａ又向Ｃ发起连接

① A （ 1000 ） —— > NAT （ 1000 ）——— > B （ 2000 ）

如果是 MASQUERADE ：

② D （ 1000 ） —— > NAT （ 1000 ）——— > C （ 2000 ）

③ A （ 1000 ） —— > NAT （ 1001 ）—Ｘ— > C （ 2000 ）

如果是 CONE NAT ：

② D （ 1000 ） —— > NAT （ 1001 ）—Ｘ— > C （ 2000 ）

③ A （ 1000 ） —— > NAT （ 1000 ）——— > C （ 2000 ）

对于 MASQUERADE 来说，只要在没有重复的 socket 的情况下，总是坚持尽量不改变源端口的原则，因此第二条连接仍然采用源端口 1000 ，而第三条连接为了避免重复的 socket 而改变了端口。

对于 CONE NAT ，为了保证所有来自 A(1000) 的数据包均被转换为 NAT(1000) ，因此 D 在向 C 发起连接时，即使不会产生重复的 socket ，但因为 NAT 的 1000 端口已经被 A(1000) “占用”了，只好使用新的端口。

可以看出，不同的 target 产生不同的结果。我们也不能绝对的说，在任何时候，全锥形 NAT 的可穿透性都比对称 NAT 要好，比如上面的例子，如果只存在连接①和②，显然是对称形 NAT 要更适用。因此，选择哪种 NAT ，除了对网络安全和普遍的可穿透性的考虑外，有时还需要根据具体应用来决定。

RFC3489/STUN协议判断过程

输入和输出准备好后，附上一张维基百科的流程图，就可以描述STUN协议的判断过程了。

STEP1：检测客户端是否有能力进行UDP通信以及客户端是否位于NAT后 -- Test1

客户端建立UDP socket，然后用这个socket向服务器的（IP-1，Port-1）发送数据包要求服务器返回客户端的IP和Port，客户端发送请求后立即开始接受数据包。重复几次。

a）如果每次都超时收不到服务器的响应，则说明客户端无法进行UDP通信，可能是：防火墙阻止UDP通信；

b）如果能收到回应，则把服务器返回的客户端的（IP:PORT）同（Local IP: Local Port）比较：

如果完全相同则客户端不在NAT后，这样的客户端是：具有公网IP可以直接监听UDP端口接收数据进行通信或者对称NAT。
否则客户端在NAT后要做进一步的NAT类型检测（继续）。

STEP2：检测客户端防火墙类型 -- Test2

STUN客户端向STUN服务器发送请求，要求服务器从其他IP和PORT向客户端回复包：

a）收不到服务器从其他IP地址的回复，认为包前被前置防火墙阻断，网络类型为对称NAT；

b）收到则认为客户端处在一个开放的网络上，网络类型为公开的互联网IP。

STEP3：检测客户端NAT是否是FULL CONE NAT -- Test2

客户端建立UDP socket然后用这个socket向服务器的(IP-1,Port-1)发送数据包要求服务器用另一对(IP-2,Port-2)响应客户端的请求往回发一个数据包，客户端发送请求后立即开始接受数据包。重复这个过程若干次。

a）如果每次都超时，无法接受到服务器的回应，则说明客户端的NAT不是一个Full Cone NAT，具体类型有待下一步检测（继续）；

b）如果能够接受到服务器从(IP-2,Port-2)返回的应答UDP包，则说明客户端是一个Full Cone NAT，这样的客户端能够进行UDP-P2P通信。

STEP4：检测客户端NAT是否是SYMMETRIC NAT -- Test1#2

客户端建立UDP socket然后用这个socket向服务器的(IP-1,Port-1)发送数据包要求服务器返回客户端的IP和Port, 客户端发送请求后立即开始接受数据包。重复这个过程直到收到回应（一定能够收到，因为第一步保证了这个客户端可以进行UDP通信）。

用同样的方法用一个socket向服务器的(IP-2,Port-2)发送数据包要求服务器返回客户端的IP和Port。

比较上面两个过程从服务器返回的客户端(IP,Port),如果两个过程返回的(IP,Port)有一对不同则说明客户端为Symmetric NAT，这样的客户端无法进行UDP-P2P通信（检测停止）因为对称型NAT，每次连接端口都不一样，所以无法知道对称NAT的客户端，下一次会用什么端口。否则是Restricted Cone NAT，是否为Port Restricted Cone NAT有待检测（继续）。

STEP5：检测客户端NAT是Restricted Cone 还是 Port Restricted Cone -- Test3

客户端建立UDP socket然后用这个socket向服务器的(IP-1,Port-1)发送数据包要求服务器用IP-1和一个不同于Port-1的端口发送一个UDP 数据包响应客户端, 客户端发送请求后立即开始接受数据包。重复这个过程若干次。如果每次都超时，无法接受到服务器的回应，则说明客户端是一个Port Restricted Cone NAT，如果能够收到服务器的响应则说明客户端是一个Restricted Cone NAT。以上两种NAT都可以进行UDP-P2P通信。

一些说明：

STUN Client and Server library(http://sourceforge.net/projects/stun/)

这个库实现了RFC3489中的STUN协议。其中，Client程序输出结果意义如下：

（1）"Open"表示这里的Open Internet

（2）"Independent Mapping, Independent Filter"表示这里的Full Cone NAT

（3）"Independedt Mapping, Address Dependendent Filter"表示这里的Restricted Core NAT

（4）"Indepndent Mapping, Port Dependent Filter"表示这里的Port Restricted Core NAT

（5）"Dependent Mapping"表示这里的Symmetric NAT

（6）"Firewall"表示这里的Symmetric Firewall

（7）"Blocked or could not reach STUN server"表示这里的UDP Blocked
reTurn (http://www.resiprocate.org/ReTurn_Overview)

实现了RFC5389中的STUN协议和TURN协议。
网上一些可用STUN Server（注意：STUN协议指定默认端口为3478）

stun01.sipphone.com

stun.iptel.org

stun.softjoys.com

stun.xten.com（这个STUN Server的实现好像有问题，测试结果与前面三个不相同）

[1] RFC3489中的STUN协议（Simple Traversal of UDP Through NATs）是一个完整的NAT穿透方案，但其修订版本（RFC5389）把STUN协议（Session Traversal Utilities for NAT）定位于为穿透NAT提供工具，并不提供一个完整的解决方案。此外，RFC3489只提供了UDP的NAT穿透，而RFC5389还支持TCP的穿透）。

作者：老鼠AI大米_Java全栈
链接：https://www.jianshu.com/p/1432c729df4d
来源：简书
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。