Для системного администратора

Использование шлюза TS Gateway

Согласно народной примете, далеко не всякий пакет с 3389-го порта TCP может достичь системы, предназначенной для публичного использования в интернете. Устройства и программы, отвечающие за безопасность внутренних сетей, как правило, конфигурируются так, чтобы через них пропускался лишь трафик HTTP и/или HTTPS (порты 80 и 443 протокола TCP), блокируя потоки данных, пересылаемых по другим портам.

С помощью средств Windows Server 2008 можно создать шлюз служб терминалов - TS Gateway. Его роль заключается в инкапсулировании протокола RDP с последующей передачей пакетов по обычным HTTP-каналам, защищая их средствами SSL/TLS. Такая технология позволяет реализовывать безопасные подключения без использования VPN и изменения настроек файерволлов, снижающих уровень защиты сети.

Новая роль служб, появившаяся в Windows Server 2008 – TS Gateway – подобна прокси-серверу, с которым взаимодействуют серверы терминалов. TS Gateway имеет встроенные средства контроля входящих подключений и доступа к ресурсам внутренней сети. Только те пользователи, которым будет разрешён доступ к шлюзу, смогут подключиться к нему. Эти пользователи смогут использовать только разрешённые для них ресурсы. Для подключения пользователя может использоваться любой компьютер, который может выступать в роли клиента шлюза и поддерживает RDP.

Рассмотрим по порядку, как удалённый клиент, используя RDP-подключение, получает доступ к ресурсам сети.

• Пользователь запускает RDP-файл (в его роли может выступать сохранённый RDP-файл или ссылка с портала TS Web Access), указывающий на определённый ресурс во внутренней сети
• RDP-файл создаёт подключение к шлюзу, используя SSL-туннель
• Шлюз, в соответствии с политикой авторизации подключений (TS CAP), аутентифицирует клиента и проверяет его полномочия на возможность создания подключения
• В случае успешного завершения проверки клиента, он отправляет запрос на необходимый ресурс – удалённое приложение или подключение к удалённому рабочему столу компьютера, расположенного во внутренней сети
• Шлюз выполняет проверку запроса на соответствие политике авторизации ресурсов (TS RAP)
• Если проверка выполнена успешно, шлюз устанавливает внутреннее RDP-подключение к затребованному клиентом ресурсу. Весь дальнейший поток данных проходит через шлюз, который выполняет его преобразование, отправляя пакеты внутри сети по порту 3389, а в сторону клиента – инкапсулируя в SSL и отправляя их с 443 порта

Работу шлюза мы продемонстрируем на примере сети следующей конфигурации:

Здесь клиент RC1, расположенный на рисунке “за облаком”, будет имитировать подключение из интернета к шлюзу TG1 (запись о адресе TG1 мы для простоты внесём в файл hosts клиента RC1). Моделировать устройства NAT или файерволлы в этом примере не будем, важно, что клиент RC1 и сервер терминалов TS1 расположены в разных сетях. TS1 и TG1 работают под управлением Windows Server 2008, клиент RC1 – Windows XP SP3 с RDP 6.1. Контроллер домена (в примере домен будет называться tstest.local) DC1 управляется Windows 2003 SP2, на нём, помимо DNS, работает центр сертификации предприятия tstestcertcenter (в принципе, ЦС для нашего тестирования необязателен, если использовать самозаверяющий сертификат), который является доверенным корневым центром сертификации для шлюза TG1.

Начнём с сервера терминалов TS1. На нём необходимо будет добавить роль сервера терминалов, установить и настроить приложения и сконфигурировать шлюз. Открываем Диспетчер сервера, переходим в левом окне в раздел Роли, в правом окне щёлкаем ссылку Добавить роли, нажимаем кнопку Далее. Отмечаем флажок Службы терминалов, два раза нажимаем кнопки Далее. Устанавливаем флажок Сервер терминалов(процесс лицензирования сервера терминалов, как и в первом примере, рассматривать не будем), нажимаем Далее два раза. Устанавливаем необходимый режим проверки подлинности на уровне сети (я поставил переключатель в положение Не требовать проверку подлинности), нажимаем Далее. Указываем тип лицензирования - Настроить позже, нажимаем Далее. Указываем, кто сможет подключаться к серверу терминалов (Пользователи домена), нажимаем Далее и Установить. Ждём, когда работа мастера будет закончена, перезагружаем сервер, и дожидаемся окончания процесса конфигурирования.

Теперь перейдём к серверу, который будет использоваться в качестве шлюза. Для него также добавим роль служб терминалов, но в качестве служб роли (и ведь ничего не поделаешь с этой тавтологией – официальная терминология Майкрософт…) укажем Шлюз служб терминалов и Веб-доступ к службам терминалов. Соглашаемся с автоматическим добавлением установки дополнительных служб для указанных ролей и нажимаем кнопку Далее. Откроется страница выбора сертификата для SSL-шифрования. Пока установим переключатель в положение Выбрать сертификат позднее - мы сделаем это при конфигурировании шлюза.

На странице создания политик проверки подлинности переведём переключатель в положение Позднее (мы также настроим их чуть позже) и нажимаем Далее два раза. На странице выбора служб ролей убедитесь, что флажок Сервер политики сети установлен. Нажимаем три раза кнопку Далее, переходим к странице подтверждения и щёлкаем кнопку Установить для завершения процесса установки.

Установим сертификат, который будет использоваться веб-службами для установления SSL-подключений. В оснастке Администрирование выберите Диспетчер служб IIS. В левой панели щёлкните строку с именем шлюза, затем в центральном окне дважды щёлкните значок Сертификаты сервера, расположенный в группе IIS. Если в сети существует внутренний центр сертификации, можно использовать выданный им сертификат, или указать сертификат, выданный одним из доверенных общедоступных центров сертификации (для тестирования сети вполне подойдёт и вариант с созданием самозаверяющего сертификата). Мы установим сертификат, выданный центром сертификации предприятия, который расположен на DC1. Для этого в панели Действия выбираем команду Создать сертификат домена.

Указываем на первой странице мастера необходимые данные (в строке Полное имя укажите DNS-имя шлюза сервера терминалов, в нашем примере это tg1.tstest.local) и нажимаем Далее. Указываем расположение ЦС (для рассматриваемой сети это tstestcertcenter\dc1.tstest.local), вводим имя для сертификата, нажимаем Готово. Сертификат должен появиться в списке веб-сервера.

Переходим к собственно конфигурации шлюза: Администрирование - Службы терминалов - Диспетчер шлюза служб терминалов. В левом окне щёлкаем имя шлюза, затем в центральном окне – ссылкуПросмотр и изменение свойств сертификата.

В открывшемся окне на вкладке Сертификат SSL нажимаем кнопку Обзор сертификатов, выбираем сертификат, полученный на предыдущем шаге для веб-сервера и нажимаем кнопку Установить. Центральное окно диспетчера должно стать таким:

Настроим политики авторизации, отмеченные желтыми предупреждающими значками. Для этого нажимаем расположенные рядом ссылки (или переходим в соответствующий раздел в дереве, расположенном в левом окне диспетчера; затем в панели действий выбираем ссылку Создать новую политику и щелкаем на команде Мастер). Указываем понятное имя политики TS CAP, метод проверки пользователя (пароль/смарт-карта), выбираем группы пользователей, которые смогут подключаться к шлюзу (а если необходимо – и группы компьютеров), задаём, если необходимо, как будет функционировать перенаправление клиентских устройств.

Похожие действия выполняем и для политики TS RAP, указывая группы пользователей, к которым она будет применяться, и задав ресурсы, к которым они смогут получить доступ (для доступа ко всем сетевым ресурсам выберите Разрешить подключение к любому сетевому ресурсу). Разрешённым для удалённых подключений внутри сети оставим 3389 TCP-порт.

Если мы сейчас зайдем с помощью браузера на веб-портал шлюза терминалов, мы увидим, что он работает, но абсолютно пуст. Вернёмся к серверу терминалов TS1. Установим на него необходимые приложения и добавим их в группу удалённых приложений RemoteApp – так же, как в первом примере. В Диспетчере удалённых приложений в панели Действия щёлкнем ссылку Параметры сервера терминалов, чтобы завершить его настройку. На вкладке Сервер терминалов проверим, что флажок Требовать проверку подлинности сервера установлен, а в поле Имя сервера укажем полное DNS-имя TS1 - ts1.tstest.local.

На вкладке Шлюз служб терминалов переводим переключатель в положение Использовать следующие параметры… и указываем имя шлюза и метод входа:

и нажимаем кнопку ОК. Поскольку сервер терминалов и шлюз у нас теперь расположены на физически разных серверах, в окне диспетчера выводится предупреждение, что в группе компьютеров веб-доступа к этому серверу терминалов нет никаких записей:

Открываем оснастку Управление компьютером, переходим в раздел Локальные пользователи и группы, и выбираем Группы. Найдите и двойным щелчком откройте группу Компьютеры веб-клиента сервера терминалов (TS Web Access Computers).

Нажмите кнопку Добавить, установите тип объектов Компьютеры, и добавьте компьютер, который является шлюзом сервера терминалов (в нашем примере это TG1).

Теперь, при нажатии ссылки Обновить в списке Распределение через веб-доступ к службам терминалов диспетчера удалённых приложений RemoteApp предупреждение должно смениться на сообщение о том, что группа компьютеров веб-доступа сформирована. Нам осталось зайти на веб-портал шлюза http://tg1.tstest.local/ts с учётной записью, принадлежащей к группе администраторов, перейти на вкладку Конфигурация и указать в зоне редактора имя сервера терминалов ts1.tstest.local, откуда веб-сервер шлюза будет получать список приложений, доступных удалённым веб-пользователям:

Ну что ж, теперь попробуем подключиться браузером с клиента RC1 к шлюзу TG1, указав в строке адреса http://tg1.tstest.local/ts. На запрос указываем учётные данные для подключения

Теперь вы должны увидеть в окне браузера список приложений, опубликованных для веб-доступа на сервере TS1. Попробуем запустить какое-нибудь из них. Появляется предупреждение, что издателя этого подключения определить не удаётся, но мы всё равно нажимаем кнопку Подключить. Вводим учётные данные для входа ещё раз… и получаем отказ!

Что же случилось? Ведь в первом примере подключение устанавливалось, даже несмотря на предупреждение, что издатель неизвестен? Мы уже не раз упоминали выше, что подключение к шлюзу из внешней сети будет происходить с помощью образования SSL-туннеля. Для его создания обе стороны – и сервер-шлюз, и удалённый клиент должны установить доверительные отношения. То есть клиент так же должен быть уверен, что отправляемые им учётные данные и пароль будут переданы безопасно и по назначению. Удостоверится в этом он может, если в своём хранилище доверенных корневых центров сертификации он обнаружит сертификат, выданный тем же центром сертификации, что и сертификат, пересылаемый клиенту с сервера-шлюза.

Чтобы клиент имел в своём распоряжении такой сертификат, на шлюзе TG1 запустите консоль MMC, добавьте оснастку Сертификаты, укажите, что она будет управлять учётной записью компьютера, компьютер – локальный. В разделе Доверенные корневые центры сертификации щёлкните Сертификаты и выберите сертификат выданный tstestcertcenter, щелкните его правой кнопкой мыши, выберите команду Все задачи, затем Экспорт.

Запустится мастер экспорта сертификатов. Указываем, что закрытый ключ экспортироваться не должен, нажимаем два раза кнопку Далее и указываем имя сертификата и место, где он будет сохранён. НажимаемДалее, затем Готово. Теперь необходимо передать любым образом этот файл сертификата клиенту RC1. На клиенте достаточно щёлкнуть этот файл правой кнопкой мыши и выбрать команду Установить сертификат.

Система автоматически поместит этот сертификат в необходимое хранилище, достаточно будет пару раз нажать кнопку Далее. При последующем подключении соединение должно быть установлено. Осталось проверить, какие порты задействованы в подключении. Вот порты, которые использует удалённый клиент после установления подключения:

А вот что происходит в это же время на шлюзе:

Как видим, шлюз соединён с клиентом с помощью 443 порта TCP, а для связи шлюза с сервером терминалов используется порт 3389. Поскольку в примере использовался доступ к приложениям через веб-портал, начальное соединение клиента со шлюзом будет происходить по HTTP (TCP, 80-й порт). Если необходимо “закрыть” на шлюзе TCP-80 порт, то обеспечить публикацию приложений на клиентах можно с помощью создания RDP-файлов или пакетов msi установщика Windows.

На этих примерах мы продемонстрировали лишь базовые возможности Windows Server 2008 по созданию решений безопасного доступа к ресурсам внутренней сети из любого места, где есть интернет. Мы не уделяли внимание вопросам администрирования, применения групповых политик, аудита и некоторым другим аспектам, поскольку основной целью являлось лишь общее описание механизмов, позволяющих создавать такие безопасные подключения. И, безусловно, необходимо признать, что практическое применение описанных технологий возможно лишь в условиях достаточно современной вычислительной инфраструктуры.

Полезные ссылки

Легкий способ снять квартиру посуточно новосибирск. Быстро, качественно и надежно.