firewalld: проблема с переадресацией порта 25, в то время как другие порты переадресовывают просто отлично, в журнале "rich rule" нет записей
Итак, я впервые установил Fedora Core 19 в качестве замены старой системы, чей диск окончательно умер. Система служит веб-сервером и шлюзом / межсетевым экраном, защищая внутренние системы. Поскольку в нем много настроек сети, я познакомился с - и обнаружил, что мне очень нравится - новый демон firewall firewalld.
Я думал, что все идет хорошо (это всегда случается, когда возникают проблемы), когда я вдруг заметил, что файл почтового журнала внутреннего почтового сервера сходит с ума - мне повезло, что я все еще наблюдал его примерно через 6 часов после того, как все заработало.
Расследование показало, что проблема заключалась в том, что моя внутренняя почтовая система (защищенная брандмауэром) почему-то думала, что вся исходящая почта поступает из шлюзовой системы, поэтому это была "внутренняя" система, и спаммеры обнаружили, что это открытая ретрансляция. Я также заметил, что так или иначе, что ОБА внутренние и внешние зоны были помечены как "маскарад" и что фактически воспринимаемые IP-адреса в файле почтового журнала были IP-адресом шлюза. Вход в систему через переадресованный порт ssh также подтвердил, что на внутренней стороне использовался неправильный IP-адрес.
НИКАКОЙ ПРОБЛЕМЫ!"Я ошибочно подумал. ДА, отключение маскировки во внутренней зоне действительно исправило неверный IP, передаваемый внутренним системам при прохождении через шлюз. Однако это НЕ решило проблему, потому что, необъяснимо (пока!) похоже, что порт 25 больше не пересылается!
ДРУГИЕ порты пересылаются, по крайней мере, легко проверяемый ssh-порт, о котором я говорил, есть. Так что, я думал, я просто включу эту причудливую функцию регистрации! Вот команда:
firewall-cmd --zone=external --add-rich-rule='rule family="ipv4" forward-port port="25" protocol="tcp" to-port="25" to-addr="192.168.1.1" log prefix="smtp-to-inside" level="info"'
Я попробовал это с постоянным параметром, а не и т. Д. НИЧЕГО не появляется в / var / log / messages - или любом другом лог-файле, который я мог бы рассмотреть. Это похоже на то, что ядро просто игнорирует этот порт. Я подумал, что внутренняя почтовая система может блокировать внешний трафик с помощью своего брандмауэра, НО шлюз ДОЛЖЕН регистрировать попытки соединения, но я ничего не получаю .
Любая помощь приветствуется.
1 ответ
Эта проблема не имеет ничего общего с firewalld, хотя она ДЕЙСТВИТЕЛЬНО освещала ошибку при ведении журнала firewalld.
Проблема заключалась в том, что на время обновления я переключал маршрут по умолчанию внутренней системы, предоставляющей почтовые службы, на другой шлюз / межсетевой экран, не включенный в обновление. Я думал, что это хорошая идея, потому что у новой системы возникли проблемы, подумал я.
Когда я вернул внутреннюю систему обслуживания SMTP, чтобы использовать новый компьютер шлюза в качестве маршрута по умолчанию, все это заработало! Оказывается, есть требование, о котором никто не говорит - никогда еще не находил это документированным, но теперь, когда я нашел это, некоторые старые таймеры подтверждают - что либо маршрут по умолчанию должен быть установлен так же, как и куда пакеты пересылаются ИЛИ у вас должны быть настроены специальные маршруты для возврата пакетов по тому же пути, откуда они пришли. Это требование: обратный маршрут должен совпадать с исходным маршрутом.
Удачи там!