Вопрос или проблема
У меня есть довольно большой опыт работы с переадресацией TCP-портов в мире UNIX (netcat, iptables), но теперь мне нужно сделать то же самое на Windows Server 2022.
Клиентские машины могут достигать TCP 25 на “шлюзевом” сервере (мы контролируем этот межсетевой экран). Этот “шлюзевой” сервер может достигнуть SMTP ретрансляции, где-то там (мы не контролируем этот путь).
Мы не хотим поддерживать SMTP ретрансляцию на “шлюзевом” сервере, вместо этого мы просто хотим переадресовать TCP 25 через него. Позже будут доступны и другие порты. UDP тоже.
Временное решение будет с netsh, но даже это не работает:
На “шлюзе”:
telnet a.b.c.d 25 – это работает
Запустил wf.msc и создал новое стандартное правило для входящих соединений на tcp 25, принять все удаленные адреса
netsh interface portproxy add v4tov4 listenport=25 connectport=25 connectaddress=a.b.c.d
netsh interface portproxy show all # выглядит хорошо
telnet 127.0.0.1 25 – соединение не удалось.
Что значит “не удалось”?
Это “отказано”?
Предпочтительное долгосрочное решение – сделать это с помощью постоянного правила в Защитнике:
Удалил это стандартное правило для входящих соединений и попробовал “пользовательское” входящее правило. Запутанно, что имеется в виду под “удаленные адреса(ами)” и даже диапазонами в этом поле.
Как можно переадресовать к многим адресам или даже диапазонам?
Я подозреваю, что это все еще означает IP-адреса источника для входящих соединений.
Но тогда, где еще я могу указать IP-адрес назначения для переадресации?
Или я смотрю не на то решение?
Пожалуйста, не предлагайте сторонние приложения, мы строго привязаны к инструментам и функциям MS.
Ваша проблема требует рассмотрения на нескольких уровнях конфигурации сети и системы.
Вы проверили, что правило netsh interface portproxy для порта 25 правильно настроено и что межсетевой экран разрешает входящий трафик на порту 25 от всех удаленных IP-адресов без каких-либо конфликтующих или ограничительных правил?
После установки правила portproxy, вы проверили текущую конфигурацию с помощью:
netsh interface portproxy show all
Шлюзевой сервер активно слушает на TCP-порту 25?
Вы можете проверить это, выполнив:
netstat -an | findstr :25
Можете ли вы успешно подключиться к внешнему SMTP-серверу (a.b.c.d) на порту 25 с шлюза с помощью telnet?
Пример:
telnet a.b.c.d 25
Когда вы выполняете telnet 127.0.0.1 25 на шлюзе, вы получаете ошибку “связь отказано” или “связь не удалась”?
Есть ли на шлюзе какое-либо стороннее антивирусное или межсетевое программное обеспечение, которое может блокировать переадресацию портов?
Требует ли шлюз конкретной конфигурации маршрутизации для достижения внешнего SMTP-сервера, такой как статические маршруты?
Вы проверяли журналы событий Windows на предмет ошибок, связанных с переадресацией портов или netsh?
Есть ли какие-либо правила межсетевого экрана, которые могут блокировать трафик от шлюза к внешнему SMTP-серверу?
Вы убедились, что правило переадресации применяется к правильным сетевым интерфейсам на шлюзе?
Ответ или решение
Создание пользовательского правила для перенаправления портов в Windows Firewall
Проблема, с которой вы столкнулись, требует внимательного анализа всех аспектов конфигурации сети и системных настроек на Windows Server 2022. Давайте разберем каждый из моментов, чтобы обеспечить единое понимание и устранить путаницу.
Проверка конфигурации правил перенаправления
-
Правила Portproxy: После того, как вы создали правило Portproxy с помощью команды:
netsh interface portproxy add v4tov4 listenport=25 connectport=25 connectaddress=a.b.c.dнеобходимо убедиться в корректности его конфигурации. Вы можете сделать это, выполнив следующую команду:
netsh interface portproxy show all -
Состояние порта: Проверьте, действительно ли сервер-прокси (шлюз) слушает на TCP порту 25. Для этого выполните:
netstat -an | findstr :25Если вы не видите статус "LISTENING", это может указывать на то, что служба не запущена или что правило не применяется.
-
Тестирование соединения: Попробуйте выполнить подключение к внешнему SMTP-серверу (a.b.c.d) с вашего шлюза с помощью следующей команды:
telnet a.b.c.d 25Это поможет вам удостовериться, что ваше соединение с удаленным сервером установлено. Также выполните:
telnet 127.0.0.1 25Важно понимать, какой именно ответ вы получаете. "Connection refused" означает, что приложение не слушает на этом порту, в то время как "Connection failed" может указывать на другие проблемы в конфигурации сети или доступа.
Настройка правил Windows Defender Firewall
-
Правила входящего трафика: Если вы решаете использовать Windows Defender Firewall для разрешения входящего трафика на порт 25, важно понимать, как работают параметры «remote addresses» и «groups». При создании пользовательского правила вы действительно задаете удаленные IP-адреса, которым разрешен доступ, а не IP-адреса для перенаправления.
-
Перенаправление: В Windows Firewall нет прямой функции для перенаправления трафика с одного IP на другой (как это делается в iptables на Linux). Вместо этого вам необходимо настроить правила так, чтобы разрешить необходимый трафик. Расширенные возможности контроля могут быть реализованы с помощью PowerShell или других инструментов, но вы уже указали, что строго следуете возможностям Microsoft.
-
Использование диапазонов адресов: Если вы хотите разрешить трафик для нескольких адресов или диапазонов, вы можете использовать списки, которые вы можете указать в поле «remote addresses». Это поле позволяет вводить диапазоны в формате CIDR (например, 192.168.1.0/24).
Дополнительные проверки
- Убедитесь, что другие сторонние антивирусные или фаерволлы не блокируют ваш трафик.
- Проверьте логи событий Windows на наличие ошибок, связанных с перенаправлением портов или сетевыми настройками.
- Удостоверьтесь, что шлюз имеет правильные маршруты для достижения внешнего SMTP-сервера.
Заключение
Чтобы добиться успешного перенаправления трафика на Windows Server 2022, необходимо настроить как Portproxy, так и правила Windows Firewall, обращая особое внимание на разрешения для входящего трафика. Эти шаги помогут вам устранить возникшие проблемы и настроить необходимое перенаправление без использования сторонних инструментов. Подходите к настройке системно, и при возникновении дополнительных вопросов не стесняйтесь обращаться к документации Microsoft или специализированным форумам для получения поддержки.