TMG и Remote Desktop Gateway — на одном сервере.

Вместо вступления.

Фирма Microsoft не страдает минимализмом. Она часто рекомендовует отводить под каждую функцию (серверный продукт либо роль или группу связанных ролей Windows Server) по отдельному серверу.
Понять Microsoft можно. С одной стороны, фирма она крупная, клиенты ей тоже все больше интереснны немаленькие (потому что и бюджеты на IT у них тоже немаленькие), а в таких контрах каждая такая функция вполне способна полностью загрузить и не один сервер. С другой стороны, чем меньше функций выполняет сервер, тем проще обеспечить его работоспосбность, надежность и безопасность. Наконец, чем больше серверов — тем больше лицензий, что для Microsoft — понятно, прямая прибыль.

Но для тех, кто, подобно мне, работает в малом и среднем бизнесе, такой подход малоприемлем — он ведет к растрате серверных ресурсов. И даже виртуализация положения не спасает. Если использование процессора и памяти она позволяет сделать более эффективным, то с уменьшением затрат на лицензии дело обстоит куда хуже. Редакция Entetprise практически не дает выигрыша в цене лицензии на один сервер по сравнению со Standard (даже если использовать ее для лицензирования всех дозволенных 4-х виртуальных машин, которые далеко не всегда нужны в таком количестве). Редакция же Datacenter  для малого-среднего предприятия явно избыточна, особенно если учесть, что ей требуется сервер с несколькими физическими процессорами — а это в наше время многоядерных процессоров может быть само по себе роскошью.

Вот и приходится мне и моим коллегам искать и находить способы совмещения нескольких функций на одном сервере. Об одном из таких совмещений я сейчас расскажу.

Постановка задачи и возможные проблемы с совместимостью.

Итак, мы планируем разместить на одном сервере, играющем роль шлюза в сеть нашего предприятия, и межсетевой экран — продукт Threat Management Gateway 2010 (далее — TMG), и шлюз для серверов терминалов — роль Remote Desktop Gateway Windows server 2008 R2 (далее — RDG).
Что может этому помешать?


Если TMG используется лишь как прокси-сервер и межсетевой экран для исходящих подключений в Интернет, то установить и использовать его вместе с RDG просто: совместно используемых ресурсов, из-за которых возможен конфликт, в этом случае нет.

Но это — лишь самый простой вариант использования TMG, не исчерпывающий всех его возможностей:TMG может использоваться и как сервер VPN, и как «обратный» прокси-сервер для публикации внутрених веб-приложений (таких как MS Sharepoint Server или MS Exchange Server). Хотелось бы иметь возможность использовать совместно с RDG и его в этом качестве. Но в этом случае конфликты, к сожалению, возможны. Посмотрим, как можно их избежать.

Первый ресурс, из-за которого возможен конфликт — политики удаленного доступа: удаленный доступ TMG в режиме проверки подлинности Windows (а точнее, исползуемый TMG компонент Windows Server под названием «Маршрутизация и удаленный доступ» (RRAS)) использует их для авторизаций подключений VPN, а RDG — для хранения политик подключения (Connection Access Policies, CAP), доступ к которым он получает через локальный RADIUS-сервер (в Windows Server 2008 он называется NPS).

К счастью, политики удаленного доступа, которые создает по умолчанию для своих нужд RDG, настроены таким образом, что использовать их может только  RDG, на RRAS они не влияют и наоборот — политики, используемые локальным RRAS не влияют на RDG.

Достигается это за счет введения специфичного для производителя (Microsoft) атрибута RADIUS, который называется MS-Network-Access-Server-Type ( см. http://msdn.microsoft.com/en-us/library/cc243442(PROT.10).aspx ). Cерверы, которые авторизуются через RADIUS (их принято называть Network Access Server, NAS) посылают в этом атрибуте свой тип, а каждая из политик удаленного доступа привязана к определенному типу: в свойствах политики удаленного доступа он указывается на вкладке Overview в разделе Network Connection Method. RRAS использует политики, для которых в качестве типа указано «Unspecified», а RDG — «Remote desktop gateway».

Второй ресурс, из-за которого возможен конфликт — это порт HTTPS (его номер — 443) на внешнем интерфейсе: клиенты служб удаленных рабочих столов используют для подключения к RDG протокол RPS over HTTPS, а TMG использует HTTPS для публикации внутренних веб-приложений и для удаленного доступа по протоколу SSTP. Вообще-то, в Windows этот порт обычно прослушивается драйвером режима ядра http.sys (для команд типа netstat это выглядит как будто этот порт прослушивает процесс System), а все остальные службы — и Inetrnet Information server (IIS), который реализует поддержку RPC over HTTPS, и SSTP, и многие другие — указывают, что этот драйвер должен перенаправлять им запросы с определенными путями в URL — и, таким образом, в принципе, в Windows этот порт является разделяемымым ресурсом. Но разработчики TMG тут проявили оригинальность (точнее — долгую память, поскольку TMG ведет свою родословную от ISA Server 2000, т.е. еще с тех времен, когда драйвера http.sys в Windows не было) — в TMG этот порт прослушивает непосредственно процесс брандмауэра mspsrv.exe. Поэтому просто так RDG совместно с TMG в режиме веб-публикации не заработает. Однако, в таком случае возникает вопрос — а как же SSTP работает совместно с TMG — раз он тоже, как и IIS, использует драйвер http.sys?

И ответ на этот вопрос позволит нам решить проблему с RDG. Оказывается, TMG публикует SSTP точно так же, как он публикует внутренние серверы. При включении SSTP в TMG мы указываем объект Web Listener, который будет принимать запросы на подключение по STTP, а TMG создает правило публикации типа «мост HTTPS-HTTP», перенаправляющее трафик для пути в URL, определенном в протоколе SSTP (а именно — /sra_{7BBA195980-CD49-458b-9E23-C84EE0ADCD75}/), на другой порт локального компьютера, причем — в уже в расшифрованном виде, по протоколу HTTP без SSL. SSTP же настраивается таким образом, чтобы принимать подключения по HTTP без SSL. Такой способ настройки (его называют «разгрузка SSL» (SSL offload) довольно часто применяется в различных вариантах развертывания различных приложений, использующих HTTPS — и RDG его, к счастью, тоже поддерживает. TMG же позволяет привязать к одному Web Listener несколько правил публикации — он выбирает, какое правило использовать, по пути, указонному в URL в запросе.
Таким образом, контуры решения определились: мы устнавливаем RDG в режиме SSL offload и публикуем его на TMG. Посмотрим, как это реализуется на практике.

Решение. Заставляем TMG и RDG работать совместно.

Здесь я не буду описывать, как устанавливать и настраивать Thread Management Gateway 2010. Просто будем считать, что у нас есть уже установленный TMG, с настроенным на нем прослушивателем (Web Listener).  Прослушиватель настроен на прием соединений HTTPS (порт 443) на IP-адресе внешнего интерфейса, а используемый в прослушивателе сертификат содержит имя, разрешающееся в этот IP-адрес — это имя мы будем использовать в качестве имени Remote Desktop Gateway в свойствах RDP-подключения на клиентском компьютере.  На вопросе настройки доверия к этому сертификату на клиtнтском компьютере, с которого будут осуществляться подключения через RDG, тоже останавливаться не будем — считаем, что оно настроено.  Способ аутентификации, настроенный в свойствах прослушивателя, может быть любым -главное, чтобы прослушиватель разрешал неаутентифицированные подключения (галочка Require all users to authenticate в окне диалога, вызываемом по кнопке Advnaced на вкладке Authentication свойств прослушивателя не установлена). Использоваться этот прослушиватель может и для поддержки протокола SSTP, и для публикации внутреннего веб-приложения, а может не использоваться вообще — для нас это неважно. Единственное ограничение — он не должен использоваться для публикации Outlook Anwhere на внутреннем сервере с тем же внешним именем, которое мы используем и для RDG — потому что эта публикация использует протокол RPC over HTTP, нужный нам для публикации RDG, и путь в правиле для этой публикации будет конфликтовать с путем, который

Следующий шаг — установка на шлюзе роли Remote Desktop Services с единственной службой роли Remote Desktop Gateway. Роль устанавливается обычным образом, через мастер добавления ролей. На странице выбора роли и выбора служб роли выбираем, соответственно Remote Desktop Services и Remote Desktop Gateway и соглашаемся с утановкой необходимых ролей (Веб-сервер и сервер политики сети) и компонентов. На странице выбора сертификатов указываем, что сертификат мы выберем позднее (вариант «Choose a certificate for SSL encryption later»). Политики подключения и ресурсов модно настроить и на этапе установки роли, и позднее — в  нашем случае это не играет никакой роли. Настройки ролей Network Policy and Access Server и Web Server (IIS) тоже оставляем по умолчанию. Жмем кнопку Install и дожидаемся установки RDG.

Теперь RDG необходимо сконфигурировать, потому что в установленном таким образом состоянии он еще неработоспособен. Заходим в оснастку управления RDG (через Server manager или через меню Администрирование), выбираем в панели навигации слева наш сервер и нажимаем No в ответ на предложение перезапустить службу RD Gateway, потому ччто сертификат, используемый IIS, не соответствует сертификату RDG (ведь сертификат мы еще не установили). В панели детализации мы видим предупреждение о том, что сервер сконфигурирован не полностью.

Чтобы сконфигурировать RDG на сервере, заходим в режим редактирования его свойств (с помощью кнопки Properties на панели действий или команды локального меню). На вкладке SSL Certificate выбираем вариант «Select an existing cerificate…»

и затем, нажав кнопку Import certificate выбираем из списка именно тот сертификат, который используется прослушивателем. На вкладке SSL Bridging ставил галочку напротив Use SSL Bridging и выбираем вариант HTTPS-HTTP bridging

Нажимаем кнопку OK и выбираем Yes в появившемся окне с предложением перезапустить службу RD Gateway. После некоторого ожидания появляется еще одно окно, теперь — с предложением перезапустить пул приложений IIS, используемый для выполнения компонента RPC over HTTP. Опять-таки, выбираем Yes.

Но это еще не все. Если зайти в оснастку IIS Manager, то мы увидим, что веб-сайт, в рамках которого работает компонент RPC  over HTTP (обычно это Default web site) не запущен, а попытка запустить его вручную приводит к не слишком внятному сообщению об ошибке про некий файл, занятый другим процессом. Смысл этой ошибки становится понятным, если мы заглянем в привязки (bindings) этого веб-сайта и вспомним о возможных конфликтах между RDG и TMG, про которые написано выше: сайт настроен на прием соединений по протоколу HTTPS на порт по умолчанию (443) для всех адресов (адрес привязки — 0.0.0.0). 

Можно решить, что, раз мы настроили RDG на использование внешнего моста HTTPS-HTTP  (его роль будет играть TMG) то эта привязкаэта привязка не нужна. Действительно, эту привязку можно удалить, запустить после этого веб-сайт и с помощью правила публикации на TMG, которое будет описано ниже, шлюз RDG заработает. Но если после этого зайти в оснастку управления RDG, то мы увидим то же самое предупреждение о несконфигурированном сертификате, как на рисунке выше. А если попробовать презапустить службу Remote Desktop Gateway, то она не сможет найти сертификат, и шлюз удаленных рабочиз столов перестанет работать. Очевидно, разработчики Microsoft в качестве места хранения сертификата, используемого службой Remote Desktop Gateway выбрали метабазу IIS. Попытки изменить параметры привязки (IP-адрес, порт) так, чтобы не было конфликта адресов, но служба Remote Desktop Gateway при этом находила свой сертификат, тоже ни к чему не приводят: похоже, эта служба жестко настроена на использование сертификата к  порту по умолчанию (443), а драйвер http.sys пытается  прослушивать этот порт сразу на всех адресах. Так что, хотя эта привязка не используется для работы RDG в режиме публикации, удалить или изменить ее мы не можем — а она мешает запустить веб-сайт из-за конфликта с TMG.

Тупик? Нет. Драйвер http.sys позволяет до некоторой степени управлять тем, какие конечные точки (комбинации адрес+порт) он пролушивает. К сожалению, драйверу можно указать не пары адрсес+порт, а только адреса, на которых он будет прослушивать ну;ные ему порты. Но для нашей цели этого достаточно.

Адреса, которые будет использовать драйвер http.sys, указываются командой

netsh http add iplisten <адрес_IPv4_или_IPv6>

Если не введен ни один адрес, то драйвер http.sys будет прослушивать все адреса (это настройка по уолчанию). Адреса достаточно ввести один раз и они будут запомнены в реестре и использоваться постоянно, даже после перезагрузки. 

В нашем случае потребуется ввести указанную выше команду, как минимум, для адреса IPv4 обратной петли: netsh http add iplisten 127.0.0.1. Возможно (если используется, например, управление шлюзом через WinRM), имеет смысл повторить команду для адреса интерфейса внутренней сети. Если используется IPv6, то можно ввести еще одну команду для адреса IPv6 по умолчанию — «::»  После ввода нужного количества команд netsh http add iplisten веб-сайт, используемый компонентом RPC over HTTP запускается и при сохранении привязки SSL к адресу и порту по умолчанию.

Однако, TMG может прослушивать и обычный порт HTTP (номер 80), например — для работы автоматического обноружения веб-прокси. Поэтому, на вский случай (и уж тем более — если веб сайт не запускается несмотря на исключение адреса внешнего интерфейса из числа используемых драйвером http.sys), имеет смысл зайти в привязки веб-сайта RPC over HTTP и изменить привязку протокола HTTP, чтобы использовать другой номер порта (к счастью, эта настройка не влияет на службу RDG).

Естественно, в реальной работе настроить адреса для драйвера http.sys и порт протокола HTTP в Default web site следует заранее, до настройки RDG. Но в этой статье я поменял порядок настроек, чтобы было лучше понятно, чем вызвана необходимость в них.

И, наконец, чтобы шлюз RDG заработал, нужно создать для негоправило публикации в TMG. Процесс создания правила описан в документации по TMG, здесь лишь указаны необходимые настройки (как они выглядят в диалоговом окне свойств правила), позволяющие опубликовать RDG и вызывающие как можно меньше конфликтов с правилами публикации других служб. Итак:

  • на вкладке Listener должен быть выбран прослушиватель, который принимает соединения по HTTPS на внешнем интерфейсе с адресом, соответсвующим имени шлюза RDG;
  • на вкладке To должно быть указано, что правило применяется для сайта с именем шлюза RDG (как он указан в свойствах подключения RDP), и дополнительно указано, что адрес компьютера — 127.0.0.1, галочка, предписывающая пересылать оригинальный заголовок Host установлена;
  • на вкладке Public Name указано, что правило принимает запросы только для веб-сайта с именем шлюза RDG;
  • на вкладке Paths указано, что правило применяется только к внутреннему пути /rpc/* и внешний путь совпадает с внутренним;
  • на вкладке Bridging долно быть указано, что публикуется веб-сервер, и что запросы переправляются на порт HTTP, который мы выбрали при настройке Deafult web site;
  • на вкладке Authentication Delegation должно быть указано, что делегирования аутентификации не производится, но клиент может аутентифицироваться непосредственно на опубликованном веб-сайте.

Вот и все. Настроенный таким образом шлюз помимо функций, обеспечиваемых TMG, будет выполнять и функции шлюза удаленных рабочих столов — что во многих случаях позволит избавиться от потребности в лишних подключениях VPN.

Реклама
  1. No trackbacks yet.

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s

%d такие блоггеры, как: