更新：在网络内使用 docker 容器时会发生这种情况。我不确定这是否重要，但它可能会以某种方式影响拓扑...
我无法理解在示例网络中无法解释的行为。基本上，我希望能够通过重定向到其他服务器来切换我的一些服务器（这样我就可以将我的应用程序指向某个数据库服务器，然后将数据库连接切换到另一台服务器而不更改应用程序）。我可能会为此使用类似 rinetd 的东西，但我很好奇为什么一些 iptables 规则没有按我预期的方式工作。
示例网络有 3 个服务器：gw (192.168.0.1/24)、s1 (192.168.0.2/24) 和 s2 (192.168.0.3/24)。gw 是 s1 和 s2 的默认网关。然后我在 nat 表中设置 gw 的 PREROUTING，将流量重定向到 192.168.1.1:5432（位于主网络之外，这意味着它会转到网关）到 s2:5432 (192.168.0.2)。192.168.1.1 地址根本不需要存在，它可以是路由内部网络 (192.168.0.0/24) 之外的任何地址。
现在，我明白了为什么我无法从 gw 网关访问 192.168.1.1:5432，因为流量不经过 NAT PREROUTING（DNAT 发生的地方），并且我知道如何通过向 nat 的 OUTPUT 链添加 DNAT 规则和向 POSTROUTING 添加 SNAT 规则来实现这一点。正如预期的那样，从 s1 访问时，指向 192.168.1.1:5432 将重定向到 192.168.0.2:5432。现在，我不明白的是，当我尝试从 s2 连接到 192.168.1.1:5432 时，为什么连接不被接受或拒绝。我认为连接应该重定向回 s2（192.168.0.2）。
在我的测试中，在 nat 的 POSTROUTING 中执行 SNAT 或 MASQUERADE 也没有任何区别。为什么重定向回 iptables 不起作用？
更新：我在 Freenode 上的 #Netfilter 频道中寻求帮助，结果发现这应该可以工作，正如“evilman_work”在实验室环境中复制时所确认的那样。此外，我们注意到，如果接口处于混杂模式，它也可以在服务器上工作。我们无法找出原因，所以如果您有任何想法，我很乐意听听。这不是什么大问题，因为这是一个使用 Docker 的测试环境，而主机是网关。我想在真正的虚拟机中使用它，所以我怀疑在那种情况下我不会遇到麻烦。也许这是由与 Docker 相关的某些东西引起的……