Перенаправление портов достаточно простая задача для любого шлюза или «железки». Даже домашний роутер сможет это сделать всего лишь с помощью одной единственной записи, но с 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» и изначально я использовал именно этот вариант, т.к. он более «легкий» и логичный. Однако после некоторого времени функционирования этого варианта в тестовом режиме я столкнулся с необъяснимыми глюками, проще говоря перенаправление происходило не всегда и зачастую не работало вообще. Это заставило меня организовать редирект другим способом в отдельном правиле. Пусть последний вариант более сложный, но он интересен следующим — публикация и редирект реализованы из разных правил, а это однозначно большая гибкость в администрировании.
comments powered by HyperComments
