反向隧道绑不上 172.17.0.1，卡了我一晚上

上周给一台内网机器做反向隧道，想让公网那台机器的 docker0 网桥能访问到内网服务。命令写得很顺，-R 172.17.0.1:18082:127.0.0.1:8000，看上去没有任何问题。

结果连上之后，公网机自己 curl 127.0.0.1 是通的，curl 172.17.0.1 就是不通。

我第一个怀疑对象是 Docker。查 bridge 网段、翻 iptables 规则、把容器网络换成 host 再试一遍，全都没用。又去怀疑是不是防火墙放行没做对，加了一堆 ACCEPT，照样不通。折腾到半夜才想起来看一眼 sshd 的配置。

真相是 sshd 的 GatewayPorts 默认为 no。这个值的意思是：不管你在 -R 里写什么地址，一律只绑到 127.0.0.1。

所以那条 -R 172.17.0.1 的命令根本不报错，sshd 默默把监听地址改成了回环。你以为绑上了，其实外面谁也连不进来，ss 里一看还真有这个端口，就是绑错了地方。

把 sshd_config 里的 GatewayPorts 改成 clientspecified 就好了。这个值表示客户端写什么地址就绑什么地址，写 0.0.0.0 是全网卡，写 172.17.0.1 就只绑 docker 网桥。改完重启 ssh，再连一次，ss 里能看到 172.17.0.1:18082 确实在监听了。

这里还有个后续的坑：重启 sshd 会把你当前的会话和这条反向隧道一起断掉。如果隧道本身就跑在这条连接上，等于自己剪自己的线。用 autossh 的话，配上 ExitOnForwardFailure 和 systemd 的 Restart=always，断线后能自己接上；手工跑的话就得另开一个通道再重启。

现在我的检查清单里多了一条：给新机器建反向隧道之前，先跑一次 sshd -T 确认 GatewayPorts 到底是 no 还是 clientspecified，别等整个服务跑起来、发现前端连不上后端，才反过来怀疑网络。