CPE上的STUN和TR069功能和实验

stun上所设计到的4种nat类型：

最近在测试cpe的时候遇到了一个感觉比较老的协议stun和tr069，以前没怎么用过，所以来记录一下：

1. Full Cone NAT: 这种类型的NAT只需一个公共IP地址，它将任何外部IP地址和端口映射到内部网络中的一个特定IP地址和端口。这种类型的NAT不会更改IP地址或端口，因此被称为“全锥形”。

2. Restricted Cone NAT: 这种类型的NAT只会将来自一个外部IP地址和端口的流量映射到内部网络中的一个特定IP地址和端口。但是，只有在内部网络中的特定IP地址和端口向外部IP地址和端口发送数据包时，才能建立连接。这种类型的NAT被称为“受限制的锥形”。

3. Port Restricted Cone NAT: 这种类型的NAT与受限制的锥形NAT类似，但还限制了内部网络中的特定IP地址和端口只能与一个特定的外部IP地址和端口通信。这种类型的NAT被称为“端口受限的锥形”。

4. Symmetric NAT: 这种类型的NAT会将来自外部IP地址和端口的数据包映射到内部网络中的一个特定IP地址和端口，并为该连接创建一个新的映射。当内部网络中的不同IP地址和端口向外部IP地址和端口发送数据包时，将创建不同的映射。这种类型的NAT被称为“对称的”。

备注：上述的这几种nat类型在实际应用过程中，只有第4种类型的nat无法应用与stun，至于为什么不能可以去详细搜一下相关资料；我们家庭里面所使用的路由器基本上nat类型都是属于对称nat类型，openwrt路由器在被一些厂家定制自己的uboot的时候都是默认用的该种类型的nat，可能是考虑的安全吧，因为这种nat类型和路由器上nf_conntrack里面记录的seesion会话数是一个一个地对应的，不同的外网ip映射的公网ip和端口都是不同的，且还有会话超时时间，我没记错的话，openwrt路由器上的udp会话老化时间是60s，icmp是120s，tcp的几种状态机制我不太记得了，所以在测试stun和tr069的时候，模拟nat类型需要排除第4种nat类型；如果想知道自己的当前网络是那种nat类型可以去下载一个nat检测工具来检测一下；一般情况下，光猫是路由模式的话，这种网路环境就是对称nat，如果光猫是桥模式，路由器去pppoe拨号的话，这种网络环境就是全锥型nat类型。

什么是TR069？

这是CPE上的一种设备远程管理平台，用于远程管理和监控网络中的设备和设施。TR-069协议主要用于家庭网关、路由器、光猫等网络设备的远程管理，可以实现远程配置、监控和维护。TR-069采用客户端/服务器模型，通过服务器向客户端发送命令，控制客户端设备的配置和状态。TR-069协议的使用可以提高网络设备的管理效率，减少管理成本，同时也可以提高网络安全性。其实我也不太明白为什么要花钱去买个ACS来管理，因为现在基本上所有做路由器的厂商在进行云管理的时候，一般都通过一些TCP的长连接就管理设备了，不知道为啥还需要用这个老协议。一般acs这个平台就是通过tr069管理自己的路由设备的，比如路由器可以将自己的cpu和基本信息上报给acs平台，acs平台可以通过路由器每次上报的时间间隔所建立的会话来下发一些配置，如重启呀这些乱七八糟的东西，我看到cpe上报的这些信息和我之前所接触的snmp种mib很像，不过snmp是一个比较大的管理协议，且一般在x86架构的设备上使用，可能tr069是实用与这种小型的网络设备的管理吧。

TR069和stun有什么联系？

我们的CPE设备100%都是挂在一个nat网络环境中的，而在这种网络环境中，我们的ACS平台要去下发一些命令配置给CPE就必须要等下一次CPE主动上报后，利用这个上报所建立的seesion去反向给设备下发配置，这样设备才能收到，但是假如我们想随时随地的去下发配置和获取CPE的一些状态信息，那不是每次都要等CPE主动上报的时间间隔才能下发？这显然不是我们所期待的，于是就有个stun，一般stun和acs都继承在一个平台，通过在cpe上配置stun服务器的地址，cpe定时的想stun绑定自己的公网ip和端口，这样acs下一次就可以利用这个绑定的公网ip和端口向CPE发起udp连接，通知CPE主动和acs建立tcp连接，acs好立刻把消息通过这个会话数下发下去。

下图是我的这款CPE的tr069上报的间隔时间为18000s，所以如果我没有stun那么每次下发配置就要等18000秒后，cpe主动上报后我才能下发配置。

 

这里可能就有疑问了，我把它设置个30s或者10s不就完了？这显然是不符合现实的网络环境的，你想不可能就你一台设备在上报消息，而且acs这种平台本身稳定性感觉不高，当这个平台管理了1000台甚至1万台设备的时候，绝对会出现消息拥堵的，所以stun就是为了缓解这种现象的。

具体使用方法 

1、配置好你自己的测试环境的stun服务器地址和前面的TR069相关的配置：

2、搭建好自己的测试环境，模拟好nat，注意一定不能使用对称nat环境否则stun穿透就没啥用的，因为他穿透不进来，这是我的一个拓扑图，我没有公网的stun和acs所以只能在内网搭建环境进行测试。

 

3、环境搭建好后我们去acs上查看就可以看到cpe上报的udpconnect的连接地址和端口了，这个就是stun绑定的公网ip和饥饿端口，也就是我上面的openwrt路由器的外网的ip和端口。 

 

4、这个时候我们就可以不用等待18000s后下配置了，直接在acs上通过udpconnectionrequestaddress先给cpe下发url地址

备注 ：这里acs连续发了三次UDP Connection Request,我去搜索了解了一下，这是acs规定的，避免网络丢包所以连续发了三次，所发送的包里面包含了一个url的消息体格式，ACS向CPE发送一个UDP Connection Request，来触发一个CWMP TR069会话的流程。此示例中，STUN服务器发送了多次相同的UDP Connection Request，以保障消息能被CPE成功接收

5、下面就是开始cpe和acs之间进行相关交互的报文，cpe主动发起TCP与acs建立好连接后开始进行相关配置的下发的操作，在下发配置前，还交互了几个TCP的data报文，我没看懂是什么意思，抓包看，我的cpe和acs之前好像不需要进行auth相关的摘要认证，cpe就直接对acs发起了http请求，然后ACS响应了200 OK，SOAP内容为InformResponse。根据响应头的Set-Cookie信息设置CPE下个请求的Cookie。

 

 6、后面cpe就发起了一个空的http请求，根据TR069协议，消息体长度必须为0，如下案例可以看到Content-Length是0：

 7、ACS响应HTTP 空请求，封装SOAP调用RPC方法，对终端设备进行参数配置或者查询等操作

8、CPE响应上述所下发的配置参数是否成功 

9、ACS下发一个空HTTP响应，根据TR069协议，状态码使用“204（无内容）”，表示本次会话结束，就是目前所有的配置我都下发完了，准备关闭咱们后续的tcp连接了

 

10、开始关闭acs和CPE之前的连接了，后面所需要再次进行下发配置，步骤应该和前面大差不差 

总结

     到这里我的stun和acs的测试已经结束了，可以看到acs这一套的流程还蛮复杂，各种各样的消息体格式，我到现在可能都还有些地方有些模糊。那么就到这里了，有问题留言哦，欢迎前辈们，指正所出现的错误。

备注：上述设计到的acs和cpe之前的交互参考了博文：ACS与CPE的全双工实现-51CTO.COM

如设计到相关侵权问题请立马告知，完全属于无意，秉承学习态度在这里记录自己所遇到的一些新的东西。

这篇好文章是转载于：学新通技术网