在前面的一篇文章中，我給出了一種創建相對猥瑣的假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來回，以表示臣服。
浙江溫州皮鞋溼，下雨進水不會胖。