Играя с keeplived, я столкнулся с этим странным (или это?) поведение.
Сценарий таков:
Внутренняя сеть, которая имеет шлюз (назовем его gw) и несколько хостов (один из них называется ih1). Другой хост (назовите его ha), который имеет 2 интерфейса: один в публичной сети, второй во внутренней. Внешний хост (eh1)
[ha] является экземпляром keepalived для маршрутизации трафика на внутренние хосты, которые предлагают сервис, говорит smtp. [ih1] - сервер smpt, его шлюз по умолчанию - [gw]
из [eh1] nc [ha] 25 не работает, и если не получится так, как я и не ожидал.
Когда исходный пакет достигает [ih1], он отвечает через шлюз по умолчанию, [eh1] получает ответ, но странная вещь вместо публичного ip [gw] (как и следовало ожидать, потому что [gw] должен маскироваться) он получает ответ с фактическим IP-адресом [ih1]. то есть: [gw] пересылает пакеты, а не маскирует их. Конечно, [eh] не знает, как напрямую связаться с [ih1], поэтому не удается установить соединение.
Копка показывает, что все пакеты, отправленные из [ih1] в ответ на запрос [eh], не проходят через цепочку POSTROUTING таблицы nat в iptable.
Но если [ih1] инициирует соединение (скажем, ping [eh1] или ssh [eh1]), оно работает как положено.
Сравнивая обе ситуации, единственное, что приходит на ум, это то, что первый [gw] никогда не говорит начальный пакет SYN, все, что он видел, это ответ SYN/ACK.
РЕДАКТИРОВАТЬ: где I_LAN является внутренним LAN: 172.16.0.0/24 и E_LAN является внешним LAN: 192.168.0.0/24
[eh1]-- E_LAN --
---------
---E_LAN--[ha]--I_LAN--| switch |--I_LAN--[gw]--ELAN--
---------
|
[ih1]