网站做ddns解析网站域名查询ip

在前面的一篇文章中，我给出了一种创建相对猥琐的假TCP隧道的POC：
https://blog.csdn.net/dog250/article/details/107025091

在运营商网络上玩overlay，有多种玩法。在私有协议之外，当然首选TCP，毕竟运营商待见啊！私有协议搞不好会被限制的。

所以TCP协议大有文章可做，传统的观点是对TCP做加法，比如优化其CC算法，增加其丢包探测等，但是这玩意儿有技术门槛啊，不如做减法！把TCP掏空到只剩下运营商设备能认出来的一个空壳子…

这种隧道可以欺骗中间转发设备相信它们是真正的TCP流，而这些设备同时一厢情愿地相信TCP会对它们的丢包，限速等行为作出有益的反馈。但是很显然，这是一场骗局。

最终，这种猥琐的隧道非但不会自我收敛，还会持续侵占大量的资源。

还有一些同样猥琐的隧道协议，美其名曰各类 自研协议：

• 标准UDP隧道，但将UDP协议号改成TCP协议号或者别的。
• 标准TCP隧道，但将TCP协议号改成UDP协议号或者别的。
• Raw IP隧道。
• …

那么，中间转发设备就这么忍受被欺骗吗？它如何检测出类似这种假TCP隧道呢？

也不难：

• 定期往两端发一些已经被ACK的数据，按照TCP规范，TCP应该回复dupACK/SACK。
• 定期故意丢包，按照TCP规范，重传包总是会到来。
• …

总之，就是按照TCP的规范，发送一些 端系统TCP一定会回应的报文 ，然后等待预期的回应，若没有收到，就知道自己大概率受骗了。

此时，中间设备即便是发送RST也不会有用，毕竟这可能是一条私有隧道，而两端运行的只是 看起来像TCP的协议 ，它们不是真正的TCP…

不过，隧道端点如果真的收到了RST，还是哎哟一下的好，以表示我被你打死了，适当配合一下没坏处。具体来讲就是，再也不用RST报文指示的四元组发包，稍微换个IP或者端口，然后假装来个SYN/SYNACK来回，以表示臣服。

浙江温州皮鞋湿，下雨进水不会胖。