STUN 服务器搭建与 NAT 类型检测

Hello，各位小伙伴大家好，前些日子给大家分享了一系列 区块链搭建的过程，在实现这个区块链的过程中呢，我碰到了一个所有区块链都会遇到的问题，那就是区块链的去中心化实现。

这去中心化网络可以说是 P2P 的一种结构，但是目前互联网的 的地址不够用，导致我们很多家用的机器以及企业网络都会采用一种 方式来共用一个出口 ip。

因此，我们要实现 P2P 结构的网络，让每一个节点连接起来，首先要解决的问题是如何让 背后的各个节点连接起来，我翻阅了很多资料，找到了一种比较通用的解决方案，通过一个具有公网 IP 的服务器来实现 NAT 穿透。具体细节有一个博主讲的非常清楚，感兴趣的小伙伴可以翻阅一下：https://evilpan.com/2015/10/31/p2p-over-middle-box/。

不同 NAT 类型会有不同的 NAT 穿越方式，比如我们最常见的 Full Cone 类型的 NAT，就可以使用 UDP 打洞的方式来实现穿越

好，为了实现 NAT 穿越，我们首先要进行 NAT 类型检测。

STUN 服务器搭建

NAT 类型检测常用的方式就是利用 STUN 服务器来进行，使用 STUN 协议与 STUN 服务器进行交互达成 NAT 类型的判断，具体判断流程我们稍后再讲，先来搭建一个 STUN 服务器。

当然我们公网上也有很多免费的 STUN 服务器，不过经过我的测试，大部分因为用于 ，防火墙并不支持 STUN 协议的 UDP 3478 端口

安装相关依赖

下载 Stunman

解压 Stunman

编译 Stunman

编译成功之后文件夹中会生成三个文件：、、

校验编译

运行

输出success表示编译成功

运行服务

现在我们可以用 来运行 STUN 服务了，这里我们选择后台运行的方式。

检查运行情况

通过 netstat 来查看 3478 端口是否开始监听。

如果看到正常监听说明服务已经运行起来了。

NAT 类型检测

好了，上面我们的 STUN 服务器已经搭建好了，接下来就要用上我们的 STUN 协议来检测 NAT 类型了。

NAT 类型

首先我们要知道目前有哪些 NAT 类型。

如果小伙伴看过了 https://evilpan.com/2015/10/31/p2p-over-middle-box/ 这篇博文的话可以跳过这一小段

NAT 类型包括以下几种：

锥形 NAT - Cone Nat

全锥形 NAT - Full Cone Nat

受限锥形 NAT - Restricted Cone Nat

端口受限锥形 NAT - Port-Restricted Cone Nat

对称 NAT - Symmetric Nat

这些 NAT 有什么区别和特点呢？

Cone Nat

在建立了一对（公网IP，公网端口）和（内网IP，内网端口）二元组的绑定之后，Cone NAT会重用这组绑定用于接下来该应用程序的所有会话（同一内网IP和端口），只要还有一个会话还是激活的，换句话说只要咱们的中间件绑定过后，我们内网IP和端口对应的公网IP和端口不会再发生变化

Symmetric Nat

与 Cone Nat 正好相反，不在所有公网-内网对的会话中维持一个固定的端口绑定，会为每个新的会话开辟一个新的端口，也就是说咱们的每一个会话经过 Nat 映射之后的公网端口都会发生变化

Full Cone Nat

在一个新会话绑定了 公网IP和端口 与 内网IP和端口 之后，这个公网的端口会接受所有发往这个端口的数据，无论来自哪个终端。

这种 Nat 方式占绝大多数

Restricted Cone Nat

这种 Nat 映射的公网端口只会接受内部之前发送过一个或者多个数据包的IP地址的数据。

Port-Restricted Cone Nat

与 Restricted Cone Nat 类似，这种方式的 Nat 不仅要限制外部的 IP 地址是之前内部发送过数据包的 IP 地址，而且端口也一起加入了限制，往这个映射端口发送的数据的源的 IP-Port 对必须是之前内部发送过的数据包的 IP-Port 对。

检测流程

有了不同 NAT 类型的特点，我们就可以对这些不同功能的 NAT 来进行检测了，有位大牛梳理了一张检测的说明图如下：

按照这样的检测流程，我用 golang 实现了一份检测程序（当然也封装成了 API 供大家调用），代码地址：https://git.dev.tencent.com/MrNullPoint/NatCheck.git，在 Release 中我们可以下载到检测程序的 1.0.0 版本，后续我会迁移到 GitHub 上供大家 来使用。