Итак, я установил Fedora Core 19 впервые в качестве замены старой системы, диск которой окончательно умер. Система служит веб-сервер и шлюз / брандмауэр, защита внутренних систем. Поскольку в нем много сетевых настроек, я получил представление - и обнаружил, что мне действительно нравится - новый демон межсетевого экрана, firewalld.
Я подумал, что все идет хорошо (всегда возникают проблемы), когда вдруг заметил, что внутренний почтовый сервер файл maillog сходит с ума - Мне повезло, что я все еще смотрел его примерно через 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 - или любой другой файл журнала, который я мог бы найти. Как будто ядро просто игнорирует этот порт. Я подумал, что, возможно, внутренняя почтовая система может заблокировать внешний трафик своим брандмауэром, НО шлюз ДОЛЖЕН регистрировать попытки подключения, но я получаю ничего.
любой и вся помощь приветствуется.
Эта проблема не имеет ничего общего с firewalld, хотя она ДЕЙСТВИТЕЛЬНО указывает на ошибку с ведением журнала firewalld.
Проблема заключалась в том, что на время обновления я переключил маршрут по умолчанию внутренней системы, предоставляющей почтовые службы, на другой шлюз / брандмауэр, не участвовавший в обновлении. Я думал, что это хорошая идея, потому что у новой системы были проблемы, подумал я.
Когда я вернул внутреннюю обслуживающую систему SMTP, чтобы использовать новый шлюз в качестве маршрута по умолчанию, все заработало! Оказывается, есть требование, о котором вам никто не говорит - еще не обнаружил, что это задокументировано, но теперь, когда я нашел это, некоторые старожилы подтверждают - что либо маршрут по умолчанию должен быть таким же, как и в том случае, когда пакеты пересылаются из ИЛИ, вы должны иметь специальные маршруты, настроенные для возвращать пакеты по тому же пути, откуда они пришли. ЭТО требование: обратный маршрут должен совпадать с исходным маршрутом.
Удачи вам!