STUN

原文链接: https://segmentfault.com/a/1190000008056434

STUN是RFC3489规定的一种NAT穿透方式,它采用辅助的方法探测NAT的IP和端口。STUN的探测过程需要有一个公网IP的STUN server,在NAT后面的UAC必须和此server配合,互相之间发送若干个UDP数据包。UDP包中包含有UAC需要了解的信息,比如NAT外网IP,PORT等等。UAC通过是否得到这个UDP包和包中的数据判断自己的NAT类型。

NAT的探测过程
假设有如下UAC(B),NAT(A),SERVER(C),UAC的IP为IPB,NAT的IP为IPA ,SERVER的IP为IPC1 、IPC2。

STEP1
B向C的IPC1的port1端口发送一个UDP包。C收到这个包后,会把它收到包的源IP和port写到UDP包中,然后把此包通过IPC1和port1发还给B。这个IP和port也就是NAT的外网IP和port,也就是说你在STEP1中就得到了NAT的外网IP。

如果向一个STUN服务器发送数据包后,没有收到STUN的任何回应包,那只有两种可能:1、STUN服务器不存在,或者弄错了port;2、NAT设备拒绝一切UDP包从外部向内部通过(不支持cone NAT)。

当B收到此UDP后,把此UDP中的IP和自己的IP做比较,如果是一样的,就说明自己是在公网,下步NAT将去探测防火墙类型。如果不一样,说明有NAT的存在,系统进行STEP2的操作。

STEP2
B向C的IPC1发送一个UDP包,请求C通过另外一个IPC2和PORT(不同与SETP1的IPC1)向B返回一个UDP数据包(server两个IP是为了检测cone NAT的类型)。

如果B收到了这个数据包,说明NAT来者不拒,不对数据包进行任何过滤,这也就是STUN标准中的full cone NAT。遗憾的是,full cone nat太少了,这也意味着能收到这个数据包的可能性不大。如果没收到,那么系统进行STEP3的操作。

STEP3
B向C的IPC2的port2发送一个数据包,C收到数据包后,把它收到包的源IP和port写到UDP包中,然后通过自己的IPC2和port2把此包发还给B。

和step1一样,B肯定能收到这个回应UDP包。此包中的port是我们最关心的数据。如果这个port和step1中的port一样,那么可以肯定这个NAT是个CONE NAT,否则是对称NAT。道理很简单:根据对称NAT的规则,当目的地址的IP和port有任何一个改变,那么NAT都会重新分配一个port使用,而在step3中,和step1对应,我们改变了IP和port。因此,如果是对称NAT,那这两个port肯定是不同的。

如果到此步的时候PORT是不同的,那么你的STUN已经死了。如果相同,那么只剩下了restrict cone 和port restrict cone,系统用step4探测是是哪一种。

STEP4
B向C的IPC2的一个端口PD发送一个数据请求包,要求C用IPC2和不同于PD的port返回一个数据包给B。

如果B收到了,那也就意味着只要IP相同,即使port不同,NAT也允许UDP包通过,显然这是restrict cone NAT。如果没收到,没别的好说,port restrict NAT。

//---------------------------------------

NAT路由类型判断
根据上面的介绍,我们可以了解到,在实际的网络情况中,各个设备所处的网络环境是不同的。那么,如果这些设备想要进行通信,首先判断出设备所处的网络类型就是非常重要的一步。举个例子来说:对于视频会议和VoIP软件,对位于不同NAT内部的主机通信需要靠服务器来转发完成,这样就会增加服务器的负担。为了解决这种问题,要尽量使位于不同NAT内部的主机建立直接通信,其中,最重要的一点就是要判断出NAT的类型,然后才能根据NAT的类型,设计出直接通信方案。不然的话,两个都在NAT的终端怎么通信呢?我们不知道对方的内网IP,即使把消息发到对方的网关,然后呢?网关怎么知道这条消息给谁,而且谁允许网关这么做了?

为了解决这个问题,也就是处于内网的主机之间能够穿越它们之间的NAT建立直接通信,已经提出了许多方法,STUN(Session Traversal Utilities for NAT,NAT会话穿越应用程序)技术就是其中比较重要的一种解决方法,并得到了广泛的应用。在这个部分,我们将重点介绍下STUN技术的原理。(PS:除此之外,还有UPNP技术,ALG应用层网关识别技术,SBC会话边界控制,ICE交互式连接建立,TURN中继NAT穿越技术等等,本文不一一做介绍。)

四、STUN协议
STUN是一种网络协议,它允许位于NAT(或多重NAT)后的客户端找出自己的公网地址,查出自己位于哪种类型的NAT之后以及NAT为某一个本地端口所绑定的Internet端端口。这些信息被用来在两个同时处于NAT路由器之后的主机之间建立UDP通信。该协议由RFC 5389定义。STUN由三部分组成:STUN客户端、STUN服务器端、NAT路由器。STUN服务端部署在一台有着两个公网IP的服务器上。大概的结构参考下图。STUN客户端通过向服务器端发送不同的消息类型,根据服务器端不同的响应来做出相应的判断,一旦客户端得知了Internet端的UDP端口,通信就可以开始了。

image
STUN协议定义了三类测试过程来检测NAT类型。

Test1:STUN Client通过端口{IP-C1:Port-C1}向STUN Server{IP-S1:Port-S1}发送一个Binding Request(没有设置任何属性)。STUN Server收到该请求后,通过端口{IP-S1:Port-S1}把它所看到的STUN Client的IP和端口{IP-M1,Port-M1}作为Binding Response的内容回送给STUN Client。 Test1#2:STUN Client通过端口{IP-C1:Port-C1}向STUN Server{IP-S2:Port-S2}发送一个Binding Request(没有设置任何属性)。STUN Server收到该请求后,通过端口{IP-S2:Port-S2}把它所看到的STUN Client的IP和端口{IP-M1#2,Port-M1#2}作为Binding Response的内容回送给STUN Client。

Test2:STUN Client通过端口{IP-C1:Port-C1}向STUN Server{IP-S1:Port-S1}发送一个Binding Request(设置了Change IP和Change Port属性)。STUN Server收到该请求后,通过端口{IP-S2:Port-S2}把它所看到的STUN Client的IP和端口{IP-M2,Port-M2}作为Binding Response的内容回送给STUN Client。

Test3:STUN Client通过端口{IP-C1:Port-C1}向STUN Server{IP-S1:Port-S1}发送一个Binding Request(设置了Change Port属性)。STUN Server收到该请求后,通过端口{IP-S1:Port-S2}把它所看到的STUN Client的IP和端口{IP-M3,Port-M3}作为Binding Response的内容回送给STUN Client。

STUN协议的输出是: 1)公网IP和Port 2)防火墙是否设置 3)客户端是否在NAT之后,及所处的NAT的类型

因此我们进而整理出,通过STUN协议,我们可以检测的类型一共有以下七种:

A:公开的互联网IP。主机拥有公网IP,并且没有防火墙,可自由与外部通信 B:完全锥形NAT。 C:受限制锥形NAT。 D:端口受限制形NAT。 E:对称型UDP防火墙。主机出口处没有NAT设备,但有防火墙,且防火墙规则如下:从主机UDP端口A发出的数据包保持源地址,但只有从之前该主机发出包的目的IP/PORT发出到该主机端口A的包才能通过防火墙。 F:对称型NAT G:防火墙限制UDP通信。

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

STUN_第1张图片
STEP1:检测客户端是否有能力进行UDP通信以及客户端是否位于NAT后 – Test1 客户端建立UDP socket,然后用这个socket向服务器的(IP-1,Port-1)发送数据包要求服务器返回客户端的IP和Port,客户端发送请求后立即开始接受数据包。重复几次。 a)如果每次都超时收不到服务器的响应,则说明客户端无法进行UDP通信,可能是:G防火墙阻止UDP通信 b)如果能收到回应,则把服务器返回的客户端的(IP:PORT)同(Local IP: Local Port)比较: 如果完全相同则客户端不在NAT后,这样的客户端是:A具有公网IP可以直接监听UDP端口接收数据进行通信或者E。 否则客户端在NAT后要做进一步的NAT类型检测(继续)。

STEP2:检测客户端防火墙类型 – Test2 STUN客户端向STUN服务器发送请求,要求服务器从其他IP和PORT向客户端回复包: a)收不到服务器从其他IP地址的回复,认为包前被前置防火墙阻断,网络类型为E b)收到则认为客户端处在一个开放的网络上,网络类型为A

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通信。

通过以上过程,至此,就可以分析和判断出客户端是否处于NAT之后,以及NAT的类型及其公网IP,以及判断客户端是否具备P2P通信的能力了。当然这是自己个人笔记的第一篇,后面,再作一篇笔记《NAT穿透原理浅析(二)》分析下不同NAT类型的穿透打洞策略。

你可能感兴趣的:(STUN)