在玩 keeplived 时，我发现了这种奇怪的（或者是？）行为。
场景如下：
一个内部网络，有一个网关（称为 gw ）和一组主机（其中一个称为 ih1）。另一个主机（称为 ha ）有两个接口：一个在公共网络中，另一个在内部网络中。一个外部主机（eh1）
[ha] 是一个 keepalived 实例，用于将流量路由到提供 smtp 服务的内部主机。[ih1] 是一个 smpt 服务器，它的默认网关是 [gw]
来自 [eh1] nc [ha] 25 不起作用，而且以一种我完全没有预料到的方式失败了。
当初始数据包到达 [ih1] 时，它会通过其默认网关进行回复，[eh1] 会收到回复，但奇怪的是，它收到的回复不是 [gw] 的公网 IP（因为 [gw] 应该是伪装的，所以这是意料之中的事情），而是 [ih1] 的实际 IP 地址。即：[gw] 正在转发数据包，而不是伪装它们。当然，[eh] 不知道如何直接到达 [ih1]，因此无法建立连接。
挖掘结果表明，所有来自 [ih1] 以回复 [eh] 请求的数据包都不会经过 iptable 的 nat 表的 POSTROUTING 链。
但是如果 [ih1] 发起连接（例如 ping [eh1] 或 ssh [eh1] ），它就会按预期工作。
比较这两种情况，唯一想到的就是在第一个 [gw] 中从未说过初始 SYN 数据包，它看到的只是 SYN/ACK 回复。
编辑：其中 I_LAN 是内部局域网：172.16.0.0/24，而 E_LAN 是外部局域网：192.168.0.0/24
[eh1]-- E_LAN --
---------
---E_LAN--[ha]--I_LAN--| switch |--I_LAN--[gw]--ELAN--
---------
|
[ih1]