NAT类型发现
一、前言
之前一篇文章中,提出了一个判断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之后。
上述过程的流程图总结如下:
四、后记
NAT类型发现的方案是在RFC3489中提出的。后继的RFC5389和RFC8489中,删除了这部分的内容(包括NAT绑定生存期发现)。且将属性MAPPED-ADDRESS更新为XOR-MAPPED-ADDRESS(此属性包含的信息与MAPPED-ADDRESS相同,但对信息做了一些算法处理)。
这些变化的原因总结如下:
1,在RFC3489中,STUN是一个完整的NAT穿越解决方案。在后续的RFC中,STUN变为一个工具,作为完整NAT穿越解决方案的一部分。
2,NAT方案有很多变种,这里给出的检测方法不足以应对日益复杂的NAT环境。
3,MAPPED-ADDRESS中包含明文的IP地址和端口,某些NAT实现会修改报文中出现的公网侧IP地址,导致功能不可用。所以使用XOR-MAPPED-ADDRESS来代替。
五、参考资料
https://www.cnblogs.com/pannengzhi/p/5041546.html
P2P通信标准协议(一)之STUN - 有价值炮灰 - 博客园 (cnblogs.com)