NAT类型发现

一、前言

之前[一篇文章](https://www.cnblogs.com/bluntwu2022/p/17038282.html" \o "NAT类型检测方案" \t "https://i.cnblogs.com/posts/_blank)中，提出了一个判断NAT类型的方案。该方案是自己研究设计的，比较粗糙。近期研读了关于STUN的一些协议标准，其中RFC3489中就包含了判断NAT类型的标准方案。

与自己设计的方案相比，标准方案有以下优点：

1，利用了STUN协议中定义的一些属性，如CHANGE-REQUEST/MAPPED-ADDRESS/RESPONSE-ADDRESS/CHANGED-ADDRESS等；

2，使用单台服务器就可以完成（需要服务器上至少配置2个IP地址）；

3，步骤更精简；

注意：RFC3489已被RFC5389废弃，且RFC5389也已被RFC8489废弃。在最新的STUN协议标准中，上面提到的属性都已被废弃。

下面介绍一下RFC3489中的NAT类型发现方案。

二、名词解释

首先介绍一下方案中用到的STUN协议中的一些属性。

CHANGE-REQUEST

此属性被客户端使用，请求服务器在发送响应时，使用不同的源IP地址或端口（与客户端请求的目的IP地址和端口不同）。此属性包含2个标志位：

"change IP"：指示服务器更换源IP

"change port"：指示服务器更换源端口

MAPPED-ADDRESS

此属性被包含在服务器的响应中，内容是服务器看到的客户端的源IP和端口信息（经过NAT映射后的）。

RESPONSE-ADDRESS

此属性由客户端使用，指示服务器应该将响应发往哪里。其内容包含地址和端口。

CHANGED-ADDRESS

此属性被包含在服务器的响应中，内容是IP地址和端口。其含义是若客户端在CHANGE-REQUEST中指定了任意的标志位后，服务器的响应将要使用的源IP和端口。

无论客户端是否设置了这些标志位，此属性总是被包含在响应中。

三、NAT类型发现流程

客户端执行3种测试来发现NAT类型。

测试I：

客户端发送一个请求给服务器。此请求中不设置CHANGE-REQUEST中的任何标志位，也不携带RESPONSE-ADDRESS属性。

测试II：

客户端发送一个请求给服务器。此请求中同时设置CHANGE-REQUEST中的两个标志位。

测试III：

客户端发送一个请求给服务器。此请求中设置CHANGE-REQUEST中的"change port"标志位。

客户端首先执行测试I

有以下几种情况：

1，没有收到响应；则客户端会立即知道它无法发起UDP连接；

2，收到响应，客户端检查MAPPED-ADDRESS属性；

(1) 若属性中的地址和端口与发送请求时使用的一致，则客户端知道自己不在NAT之后。继续执行测试II

① 若收到响应，则客户端知道它可以访问互联网（或者，至少客户端位于行为类似完全锥形NAT的防火墙之后，且没有地址转换）。

② 若未收到响应，则客户端知道它位于对称UDP防火墙之后。

上述2种情况，都可以认定客户端位于公网上。

(2) 若不一致，则客户端知道它位于NAT之后。继续执行测试II。

① 若收到响应，则客户端知道它位于完全锥形NAT之后。------测试II中，服务器使用不同的源IP地址和端口进行响应，若能收到，则表面是完全锥形NAT，这种NAT不检查下行报文的源IP和端口。

② 若未收到响应，则客户端重复执行测试I，但使用不同的目的IP地址和端口（这些信息可以从首次执行测试I的响应中获取，包含在CHANGED-ADDRESS属性中）

1) 若此次响应中包含的MAPPED-ADDRESS属性中的IP地址和端口和第一次时不一致，则客户端知道它位于对称NAT之后。

2) 若两次结果一致，则客户端位于限制锥形NAT或端口限制锥形NAT之后。为了确定是哪一种NAT，需要执行测试III。

执行测试III后，若收到响应，则客户端位于限制锥形NAT之后。

执行测试III后，若未收到响应，则客户端位于端口限制锥形NAT之后。

上述过程的流程图总结如下：