Вопрос или проблема
Клиентские машины могут достигать TCP 25 на сервере “шлюз” (мы контролируем этот сегмент и все брандмауэры там). Этот сервер “шлюз” может достигать SMTP ретранслятора где-то там (мы не контролируем этот путь).
Мы не хотим поддерживать SMTP ретранслятор на сервере “шлюз”, вместо этого просто хотим переадресовать TCP 25 через него. Другие порты будут добавлены позже. UDP тоже.
Временное решение можно было бы сделать с помощью netsh, но даже это не работает:
На “шлюзе”:
telnet a.b.c.d 25 – это работает, я получаю SMTP приветствие и могу создать электронное письмо из telnet приглашения.
Запустил wf.msc на этом шлюзе, создал новое стандартное правило входящего трафика для tcp 25, разрешающее все удаленные адреса на всех сетевых адаптерах. Это самое верхнее правило разрешения, поэтому я предполагаю, что ничего не блокирует входящий TCP 25 на сервере шлюз.
netsh interface portproxy add v4tov4 listenport=25 connectport=25 connectaddress=a.b.c.d (где a.b.c.d – это IP удаленного SMTP сервера)
netsh interface portproxy show all – выглядит хорошо, прокси включен для всех интерфейсов
netstat -an – показывает LISTENING на TCP 25
telnet 127.0.0.1 25 – соединение не удалось.
Хм… что значит “не удалось”? Что это означает? Это TCP NAK, т.е. “отказано”. или что-то другое?
Эта штука с netsh была всего лишь промежуточным тестом.
Предпочтительным долгосрочным решением было бы переадресация портов с постоянным правилом в Защитнике на хосте шлюза, созданным с помощью WF.msc
Вот что я попробовал для этого:
Удалил это “стандартное” правило входящего разрешения для TCP 25, упомянутое ранее, и вместо этого попытался создать правило “пользовательского” ввода.
Смешивает с толку, что WF.msc подразумевает под “удаленными адресами” и даже полем диапазонов там.
Как можно переадресовать TCP-сеанс на множество адресов или даже диапазонов?
Я подозреваю, что это все еще означает IP-адреса источника для входящих соединений.
Но тогда где еще я могу указать целевой IP для переадресации?
Или я смотрю на неправильное решение?
Пожалуйста, не предлагайте сторонние приложения, мы строго привязаны к инструментам и функциям MS.
Ответ или решение
К сожалению, Windows Firewall, в версии WF.msc, не предлагает функциональности TCP-порта для перенаправления, аналогичной функциональности iptables в Linux. Давайте подробнее рассмотрим ваше описание ситуации и возможные решения проблемы.
Ситуация
Ваши клиентские машины могут достучаться до TCP порта 25 на "gateway" сервере, и этот сервер может отправлять электронные письма через SMTP релейный сервер, который находится вне вашей сети. Тем не менее, вы желаете перенаправить TCP 25 через ваш "gateway" сервер вместо создания собственного SMTP релея на этом сервере. Вы также упомянули возможность необходимости подобного решения для других портов и UDP-трафика в будущем.
Проблемы с использованием WF.msc
Вы уже создали правила для фаервола с использованием WF.msc для разрешения входящих соединений на TCP 25. Ваша попытка использования netsh interface portproxy была сделана правильно, но возникла проблема с подключением к порту 25 по локальному адресу (например, telnet 127.0.0.1 25).
663### Что может означать "failed"?
Ошибка с "failed" при попытке подключения по telnet может означать несколько вещей:
- Отказ в соединении (TCP NAK): Это может означать, что на стороне сервера ничего не слушает, или отсутствует соответствующий маршрут.
- Проблемы с настройкой: Возможно, не все компоненты или правила были настроены верно.
Использование netsh
Несмотря на то, что netsh interface portproxy является полезным инструментом для простого перенаправления трафика, важно убедиться, что:
- Настройка действительно применена и активна.
- Возможен доступ к целевому адресу, и там действительно слушает сервер SMTP.
Долгосрочное решение через WF.msc
Понять концепцию "удаленных адресов" и "диапазонов" в WF.msc очень важно. В данном контексте:
- Удаленные адреса — это источники трафика, которые разрешены для подключения к вашему серверу.
- Для перенаправления трафика на другие адреса или диапазоны используется команда
netsh, однако в WF.msc таких настроек нет.
Возможные шаги для решения проблемы
-
Проверка правил WF.msc: Убедитесь, что правила, которые вы создали, по-прежнему активны, и нет конфликтующих правил.
-
Использование netsh для портпрокси: Это остаётся вашим наиболее гибким вариантом. Команда, которую вы использовали, должна сработать, если настройки сети правильные:
netsh interface portproxy add v4tov4 listenport=25 connectport=25 connectaddress=a.b.c.dУбедитесь, что у вас правильно настроены разрешения и что ваша сетевое окружение допускает такие соединения.
-
Проверка маршрутизации и подключения: Убедитесь, что к удаленным адресам нет ограничений, и все правила маршрутизации выполняются.
-
Обратитесь к журналам Windows Event: Эти журналы могут предоставить более детальную информацию о том, что именно пошло не так.
Заключение
В текущем состоянии Windows Firewall (WF.msc) сам по себе не предназначен для выполнения функций перенаправления портов, аналогичных iptables в Linux. Однако, правильная конфигурация с использованием netsh interface portproxy может служить вашим временным и, возможно, постоянным решением. Надеюсь, данные рекомендации помогут вам решить вашу задачу. Если у вас остались вопросы или нужны дополнительные разъяснения, не стесняйтесь задавать их.