我有以下情况：
1-我使用堡垒（NAT）实例作为网关，将 ssh 访问转发到我的所有私有实例（使用 iptables）[私有 IP：10.10.1.10 公共 IP：200.147.160.24]
2 - 同一 vpc 下的公共实例（但不在同一个子网下）作为我的堡垒实例（使用互联网网关）[私有 IP：10.10.9.23 公共 IP：186.192.90.5]
我想通过堡垒 (1) 中的 iptables 转发访问我的公共实例 (2)，但我无法做到。结果超时。（所有其他到私有实例的转发均有效）。
这很有趣，因为： - 如果我直接使用公共 IP 来 ssh 公共实例，它可以正常工作。
- 如果我通过 ssh 进入堡垒，然后使用其私有 IP 进入公共实例，它也可以正常工作。
这是我在堡垒中使用的 iptables 规则：
iptables -t nat -A PREROUTING -d 0.0.0.0/0 -p tcp --dport 1500 -j DNAT --to-destination 10.10.9.23:22
这有效：
ssh [email protected]
有效（在堡垒（1）内）：
ssh [email protected]
这不起作用（超时）：
ssh -p 1500 [email protected]
- 安全组中使用的所有端口均已打开。
- 公共 IP 不是真实的，仅举例
任何想法都值得赞赏。
答案1
这里，您遇到了涉及 NAT 的不对称路由情况，这是行不通的。
当然，如果你的目标实例有一个公共 IP，那么堡垒主机上似乎没有太多的堡垒效应……但假设你有一个合乎逻辑的理由，以下是我对这个问题的看法：
我们将客户端机器称为“C堡垒” B，将目标实例称为“目标实例” T。
流量到达：源 IP = C，目标 IP = B。
B 翻译：源 IP = C，目标 IP = T。发送给 T。
T 接收：源 IP = C，目标 IP = T。
T 回复：源 IP = T，目标 IP = C。
回复流量会去哪里？不会去堡垒——它会去往 Internet 网关……这是网关从未听说过的 TCP 流的回复数据包。网关理应丢弃它或向发送实例 T 发送 TCP RST 以断开此无效连接。
客户端 C 不应该看到这个响应，但即使看到了，客户端现在也看到......
源 IP = T，目标 IP = C。
客户端或任何中间状态防火墙都没有预料到这种情况，因此流量被丢弃或拒绝。
对于您的私有地址机器，它们的默认 VPC 路由（我假设）指向堡垒主机，因此这里不存在不对称情况。堡垒可以在返回 C 的途中反向转换地址，一切正常。
现在，理论上，你应该能够通过向堡垒添加第二条规则来使此设置工作，以便这些 ssh 连接采用堡垒主机的 IP 地址作为其来源地址。
保留DNAT规则，您将需要类似这样的东西......
iptables -t nat -A POSTROUTING -d 10.10.9.23/32 -p tcp --dport 22 -j SNAT
当然，这只是我编造的，因为我从来没有机会这样做......但至少它的逻辑是合理的。
现在，假设这个（或类似的东西）有效，您已经解决了可达性问题……并产生了一个新问题：源 IP 地址（在内部服务器的日志中）将始终是堡垒主机。我们别无选择，只能这样做，使转换连接可路由回互联网……但您可能最好只使用其公共地址访问机器。
实现此目的的另一种方法是使用堡垒上的 HAProxy。T 服务器看到的源地址仍将是堡垒主机的内部地址……但现在您在堡垒主机上拥有不错的日志文件，可用于 IP 地址跟踪。当我需要将内部 TCP 服务公开到互联网时，这是我首选的方法，而不是DNAT，因为代理可以提供日志、访问控制和连接统计信息。（HAProxy 既是 http 感知负载平衡器，也是与有效负载无关的 TCP 负载平衡器。我与该产品没有任何关系，只是粉丝）。
答案2
我不确定发生了什么，但怀疑路由问题/不匹配是可能的。您是否尝试过使用 tcpdump 之类的工具来检查数据包是否成功以及所采用的路由？