内网隧道到底是什么：从数据流看它的边界

SSH 的 -L 与 -R 方向相反，参数配反会变成把内网端口主动暴露到公网

理解它的关键是画出三条线：入口、信任边界、危险点。

先说结论

漏洞的本质是「不可信数据到达了危险点」，防御的本质是「在中间加一道能正确判断的关卡」。

• 入口：数据从哪来，谁都能改吗
• 边界：跨边界时有没有做类型与格式判断
• 危险点：拼接、解析、执行、反序列化
• 前置条件：需要什么权限、什么配置
• 影响面：能读到什么、能改到什么

数据流：从入口到危险点

隧道流量在网关看来只是一条长连接，可用的特征只有字节数与持续时长，包内容看不到。

信任边界在哪

跳板机的转发规则要按源、目标、端口三元组登记，出现越权组合就告警，这是最有效的一层。

边界两侧的数据可信度不同，所有校验都应该发生在边界上，而不是散落在业务代码里。

这个问题的几个关键事实

决定它「是理论还是现实」的几条：

• SOCKS5 代理本身不做身份鉴别，任何能连上这个端口的人都可以借道，来源与口令都不校验
• 多级跳会让溯源变难，测试记录里必须写清每一跳落在哪台机器上

影响面怎么判

评估危害时先问：需要什么身份、需要开什么配置、能不能碰到内网。三个问题的答案决定了它是「低危」还是「要连夜修」。

为什么总是修不干净

把 -R 绑到 0.0.0.0，内网端口直接对公网开放

隧道建完不做记录，事后自己也说不清走过哪条路

根因通常是「同一个入口有多个解析器」，修了一个，另一个还通。

再补充几点

这几条不改变结论，但会改变你评估风险时的顺序。

• SSH 的 -L 与 -R 方向相反，参数配反会变成把内网端口主动暴露到公网
• 收工后要回收隧道与临时账号，遗留的转发规则是最常见的一种后门
• 用生产跳板机做测试中转，把业务日志污染了

理解数据流，比背 payload 有用得多。