Перенаправление портов достаточно простая задача для любого шлюза или “железки”. Даже домашний роутер сможет это сделать всего лишь с помощью одной единственной записи, но с TMG все не так просто. Надо отдать дань уважения разработчикам этого продукта за то, что они смогли усложнить задачу перенаправления портов максимально на сколько это вообще возможно.
В простом представлении все выглядит следующим образом: необходимо создать прослушиватель, который бы мониторил запросы на 80 порт; этот прослушиватель будет применяться совместно с правилом, которое в итоге будет редиректить запрос на нужный порт.
Изначально имеем: внутренний домен <внутренний_домен_организации>.local, внешний домен <внешний_домен_организации>.ru, Sharepoint Server 2013, который находится за шлюзом Forefront TMG (внешний url – sharepoint.<внешний_домен_организации>.ru, внутренний url – http://intranet, внутренний адрес 192.168.1.21).
Естественно, сертификаты тут нам будут не нужны, прослушиватель необходимо создать без использования ssl. Основные настройки можно увидеть на скриншоте ниже:
После настройки прослушивателя самое время создать правило, его использующее. Конечно же его задача – простое перенаправление, поэтому никакие проверки подлинности и защищенные соединения использовать мы не будем. Правило будет запрещать соединение по 80 порту и сразу перенаправлять входящие запросы на нужный url. Основные настройки правила находятся на вкладках “Действие”, “Куда”, “Внешнее имя”. Скриншоты можно увидеть ниже.
Задача решена.
Стоит отметить, что есть и более простой способ перенаправления трафика на нужный порт прямо из существующего правила публикации, подробное описание метода есть в статье “HTTP to HTTPS Redirection Options in Forefront TMG and UAG” и изначально я использовал именно этот вариант, т.к. он более “легкий” и логичный. Однако после некоторого времени функционирования этого варианта в тестовом режиме я столкнулся с необъяснимыми глюками, проще говоря перенаправление происходило не всегда и зачастую не работало вообще. Это заставило меня организовать редирект другим способом в отдельном правиле. Пусть последний вариант более сложный, но он интересен следующим – публикация и редирект реализованы из разных правил, а это однозначно большая гибкость в администрировании.
