我们在通过远程端口转发进行 SSH 连接时遇到了问题。
该场景是一个企业网络，其中内部网络上的服务器（我们称之为“源”）必须通过 SSH 登录到 DMZ（“目标”）中的服务器。由于 DMZ 中的目标服务器被锁定以用于来自内部网络的连接（甚至无法从内部网络看到），因此我们在 DMZ 中有一个跳转主机（“jumphost”）。我们通过在 jumphost 上设置远程端口转发来做到这一点。
我们从内部网络的原始服务器运行这个命令，到 jumphost：
origin> ssh -R *:1234:target:22 myusername@jumphost
这是在 jumphost 上建立 SSH 会话，使其开始侦听端口 1234（只是一个示例任意端口号），并将该端口上的连接转发到目标服务器端口 22 (SSH)。
然后我们在端口 1234 上建立第二个 SSH 会话，仍然是从源服务器到 jumphost，然后实际连接到端口 22 上的目标服务器 - 这是我们的“真正的”SSH 会话，我们可以在其中完成我们的工作目标服务器：
origin> ssh jumphost -P 1234
跳转主机已配置为允许远程端口转发，在 sshd_config 中有以下设置：
AllowTcpForwarding yes
GatewayPorts yes
此外，源服务器和跳转主机之间的防火墙开口已就位，用于端口 22（用于设置远程端口转发的初始 SSH 连接）和端口 1234（用于转发端口上的后续 SSH 连接）。jumphost和target之间也有防火墙，已经在22端口打开了。
当我们建立第二个连接（通过转发端口的连接）时，连接立即关闭（'连接被远程主机关闭'）。
在目标服务器上运行 tcpdump 没有显示任何活动，即连接似乎被阻止了。
但是，我们能够成功地建立从 jumphost 到目标的常规 SSH 会话。只有当通过转发端口进入时，连接才会关闭，尽管两者都连接到端口 22 上的目标。
更重要的是，如果我们使端口转发指向内部网络上的服务器（即从内部网络的原始连接到 DMZ 中的 jumphost，然后返回到内部网络上的第三台服务器），那么 SSH会话建立成功。
所有这些让我相信某些网络安全设置在起作用，这阻止了通过跳转服务器上的转发端口连接到 DMZ 内的目标服务器。不幸的是，我知识不足，无法知道： …