Коллеги, добрый день. Сегодня мы поговорим о том, как можно предоставить удаленный доступ нашим дорогим пользователям к внутренним ресурсам организации из сети интернет. Обсудим плюсы и минусы подходов, узнаем нюансы конфигурации и эксплуатации сервисов.
Сначала познакомимся с ролью Remore Gateway, затем перейдем к Web Client. Увидим как будет выглядеть подключение со стороны клиента с разных ОС. Также подведем некоторые итоги по проведенной работе.
Remote Desktop Gateway
Описание функционала
Компонент RD Gateway представляет из себя стандартную (доступную из коробки) роль Windows Server. Суть заключается в том, что на периметре локальной сети разворачивается хост на котором инсталлируется компонент RD Gateway. Как нам подсказывает название, он является шлюзом для удаленных подключений. Само подключение производится через RDP клиент (в ОС отличных от Windows может потребоваться поддержка функционала шлюза подключений).
Принципиальным отличием работы компонента от обычного подключения RDP является тот факт, что соединение RDP устанавливается поверх HTTPS (веб-сервер IIS будет инсталлирован автоматически при установке).
Применение этой технологии позволяет более гибко подойти к вопросам публикации, управления и мониторинга удаленных подключений наших коллег:
- По части публикации — нам достаточно опубликовать один порт в сеть интернет, нет необходимости плодить большое количество портов при публикации дополнительных узлов подключения.
- По части управления — мы получаем инструменты политик авторизаций, где мы можем явно указывать: кто, куда и как может подключаться.
- По части мониторинга — мы получаем возможность ведения лога подключений, удачных и неудачных попыток при помощи журналов Windows.
Предварительные требования
- Windows Server 2008+ в качестве ОС узла установки роли.
- Наличие развернутого домена Active Directory.
Наш тестовый стенд
Чтобы легче было понимать материал, опишу нашу тестовую лабораторию на которой мы будем проводить тесты.
Стенд состоит из 4х узлов:
- lab-dc1.party.hard — контроллер домена.
- lab-rds1.party.hard — сервер, на котором уже создано тестовое развертывание служб удаленных рабочих столов.
- lab-rdgw1.party.hard — сервер шлюза удаленных рабочих столов и компонента web client.
- lab-client1 — узел вне домена, моделирует клиентское подключение.
Установка, конфигурация и проверка роли Remote Desktop Gateway
Установить роль возможно произвести разными способами. Мы рассмотрим способ через развертывание служб удаленных рабочих столов.
Установка через развертывание служб удаленных рабочих столов
Начнем с сервера lab-rds1.party.hard. Для инсталляции роли нам необходимо в Диспетчере серверов, где уже существует развертывание инфраструктуры RDS, добавить сервер lab-rdgw1.party.hard для управления.
Затем, через иконку RD Gateway, добавить роль узлу lab-rdgw1.party.hard.
Следующим этапом мы займемся конфигурацией сертификатов.
В результате выполненных действий, статус изменится на Готово к применению.
Проверяем подключение со стороны клиента
Поздравляю, мы произвели необходимый минимум для работы Remote Desktop Gateway. Теперь можно проверять как технология выглядит со стороны внешнего пользователя, которому очень хочется получить удаленный доступ.
Для этого пользователю понадобиться выполнить подключение через RDP клиент. Введем внешнее имя нашего шлюза, которое мы указывали при конфигурации. Также включим настройку Использовать мои учетные данные шлюза удаленных рабочих столов для удаленного компьютера для того, чтобы не вводить одни и те же учетные данные несколько раз.
Также необходимо определить внутренний хост к которому необходимо подключиться с указанием учетных данных.
Так выглядит подключение к шлюзу через стандартный RDP клиент Windows.
В процессе подключения мы можем увидеть предупреждение о невозможности идентифицировать шлюз. Подобное ошибка обязательно возникнет если клиент не доверяет сертификату шлюза удаленных рабочих столов.
В конечном итоге клиент выполняет RDP соединение с интересующим его хостом, который находится позади шлюза.
Мониторинг удаленных подключений
Для того, чтобы узнать информацию об успешных или неудачных попытках подключения к шлюзу мы можем воспользоваться инструментом Просмотр событий. Нужную нам информацию мы найдем журналах Безопасность и Microsoft-Windows-TerminalServices-Gateway.
Для примера я произведу 2 попытки входа.
Первая — учетные данные некорректны.
Вторая — учетные данные корректны.
Нюансы эксплуатации
В ходе изучения технологии я столкнулся с несколькими нюансами которые желательно знать перед вводом в эксплуатацию.
Необходимость решения вопроса с SSL сертификатом для подключения к шлюзу
Этот пункт подразумевает обязательное доверие со стороны клиентов к внешнему сертификату безопасности. Проще говоря, если у клиента нет доверия к сертификату, то подключиться к шлюзу не получится.
Вариантов решения не так уж и много:
- Использование самоподписанного сертификата и ручной импорт клиентам в случае если ПК не в домене и автоматизация этого процесса через GPO если ПК в домене.
- Использование бесплатного сертификата Let’s Encrypt (90 дней). О выпуске и установке сертификата вы можете почитать — здесь.
- Покупка сертификата безопасности на год.
Невозможность указать нестандартный порт подключения на старых RDP клиентах Microsoft
Что касается этого пункта, мы можем столкнуться с ситуацией, когда внешний порт уже занят и нам необходимо выбрать другой.
Такой сценарий, безусловно, поддерживается, однако проблемы могут возникнуть на клиентских машинах со старой версией RDP клиента. При попытке указать внешний адрес и порт подключения будет выдаваться ошибка о невозможности выполнения этого действия.
Решение только одно — установка обновления RDP клиента. Начиная с Windows 8 клиент уже обновлен и такой проблемы замечено небыло.
Возможные проблемы при подключении с ОС отличных от Windows
Функционал, необходимый для подключения через шлюз удаленных рабочих столов, интегрирован в стандартный RDP клиент Microsoft. Однако, если необходимо подключаться с других ОС, необходимо предварительно проверить возможность подключения через шлюз.
HTML5 Web client
Описание функционала
Компания Microsoft пошла дальше в вопросах предоставления удаленного доступа пользователям и выпустила специальный Web client компонент, позволяющий подключаться к рабочему столу или RemoteApp приложению через обычный веб-браузер.
Подобный подход имеет большое преимущество перед классическим подключением через шлюз. Теперь мы не зависим от ОС или конфигурации RDP клиента. Нам достаточно иметь на устройстве любой современный браузер для удаленного подключения.
Схема работы примерно та же. Мы организуем хост с установленным компонентом Web Client на периметре сети и публикуем один порт в сеть интернет.
Также у нас появляется возможность игнорировать вопросы связанные с клиентским доверием к SSL сертификатам. Т.к подключение происходит через веб-браузер, мы можем просто закрыть глаза и использовать самоподписанный сертификат для целей удаленного подключения без необходимости получения или приобретения сторонних.
Также прошу обратить внимание, что компонент Web client и роль Remote Desktop Web Access не одно и тоже. RD Web Access позволяет нам публиковать сеансы и RemoteApp приложения, которые, по факту, будут подключаться через RDP. Web client позволяет нам устанавливать сессию непосредственно в веб-браузере.
Предварительные требования
- В сети должно быть сконфигурировано развертывание удаленных рабочих столов.
- Версия ОС на узлах с ролями Connection Broker, Web Access, Session Host, Gateway должна быть Windows Server 2016+.
- Лицензии CAL должны выдаваться на пользователя, не на устройство.
- На узле Web client должно быть установлено обновление KB4025334.
- Наличие развернутого домена Active Directory.
Установка, конфигурация и проверка Web client
В этой статье мы развернем компонент Web client, как и Remote Desktop Gateway, на отдельном узле — lab-rdgw1.party.hard. Воспользуемся уже сконфигурированной инфраструктурой, описанной выше.
Т.к мы планируем развернуть компонент на узле lab-rdgw1.party.hard, нам необходимо установить на него роль Web Access, иначе, мы столкнемся с невозможностью установки Web client.
Для этого воспользуемся способом установки через развертывание служб удаленных рабочих столов и добавим управляемый хост в Диспетчере серверов.
Теперь перейдем к установке роли Web Access. Для этого выберем пункт Добавить сервера Web Access в Обзоре развертывания.
Укажем узел для развертывания роли.
Подтверждаем установку и ждем ее завершения.
Теперь переходим непосредственно к установке Web client. На текущий момент установка компонента возможна только через PowerShell. Может быть, со временем, разработчики добавят возможность установки через GUI.
Сперва нам необходимо обновить модуль PowershellGet. Открываем Powershell от имени администратора и вводим:
Install-Module -Name PowerShellGet -Force
Для корректной работы нам нужно закрыть и еще раз открыть Powershell от имени администратора, иначе установленный модуль не будет работать.
После установки PowershellGet устанавливаем модуль RDWebClientManagement. Для этого вводим в Powershell:
Install-Module -Name RDWebClientManagement
Также подтверждаем установку и соглашаемся с условиями в процессе выполнения командлета.
Теперь установим модуль Web client выполнив в Powershell командлет:
Install-RDWebClientPackage
Теперь ненадолго переместимся на узел с ролью RD Connection Broker. Отсюда нам нужен сертификат который уже или будет назначен для роли RD Connection Broker. Так как мы разворачиваем тестовый стенд, нам проще создать новый самоподписанный.
После этого нам необходимо найти его в оснастке Сертификаты учетной записи компьютера в виде ключевой пары .pfx и экспортировать публичную часть.
Только что полученный сертификат переносим на сервер lab-rdgw1.party.hard любым доступным способом и сами возвращаемся на него же. 🙂
Импортируем открытую часть сертификата для развертывания Web client.
Import-RDWebClientBrokerCert "C:\users\Administrator\Desktop\lab-rds1.party.hard.cer"
И наконец публикуем компонент.
Publish-RDWebClientPackage -Type Production -Latest
Дополнительная литература
Для более подробных инструкций предлагаю посмотреть документацию Microsoft.
Проверяем подключение со стороны клиента
Итак, проверим как наши пользователи будут удаленно подключаться. Для этого запускаем веб-браузер и вводим внешний fqdn-адрес:
https://ext-lab-rdgw1.party.hard/RDWeb/webclient/
Запустим, единственный в нашем случае, опубликованный ресурс.
Также, для полноты картины, я решил добавить в статью подключение с устройства под управлением Linux.
Для этого точно также запускаем веб-браузер и вводим внешний fqdn-адрес:
https://ext-lab-rdgw1.party.hard/RDWeb/webclient/
Подключение к хостам вне коллекции RDS
У некоторых может возникнуть вопрос:
Возможно ли подключение через веб-браузер к серверам, которые не находятся в коллекции RDS? А к клиентским компьютерам?
Да, такое возможно с небольшой хитростью. Для этого нам необходимо опубликовать RemoteApp приложение удаленного рабочего стола (mstsc) с необходимыми параметрами подключения.
Ниже я покажу пример публикации удаленного подключения к серверу lab-dc1.party.hard.
Подход имеет свои недостатки. Таким образом мы, фактически, устанавливаем 2 RDP соединения. Сначала с узлом RDSH и отсюда устанавливаем новое соединение с нужным нам хостом.
При использовании хитрости описанной выше, наш пользователь увидит в веб-панели только опубликованное приложение, без значка подключения к RDSH узлу коллекции. Это связано с тем, что коллекции могут быть двух типов:
- Сессии
- Приложения RemoteApp
Поэтому, если необходимо сохранить у пользователя как подключение к RDSH узлу, так и к другому серверу или клиентскому компьютеру, необходимо изменить один параметр в реестре.
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Terminal Server\CentralPublishedResources\PublishedFarms\<collection>\RemoteDesktops\<collection>\ShowInPortal
Значение этого ключа должно быть равно 1.
После изменения значения пользователь увидит оба варианта подключения.
Мониторинг удаленных подключений
Для того, чтобы узнать информацию об успешных или неудачных попытках подключения к Web client мы можем воспользоваться инструментом Просмотр событий. Нужную нам информацию мы найдем журнале Безопасность.
Для примера я произведу 2 попытки входа.
Первая — учетные данные некорректны.
Вторая — учетные данные корректны.
При использовании инструментов для автоматизации процесса можно получить более удобный мониторинг и интегрировать его в другие сервисы (напр. Zabbix).
Нюансы эксплуатации
Отсутствие возможности копирования файлов
К сожалению, на момент публикации статьи в компоненте отсутствует возможность копировать файлы между системами. Возможно, в вашей рабочей деятельности это будет являться важным фактором, поэтому это стоит учитывать.
Двойное RDP подключение к хостам вне коллекции RDS
На текущий момент мне не удалось напрямую подключиться к узлам, которые не находятся в RDS коллекции. Пока что мне известен только способ через двойное подключение, где в качестве прокси будет использован RDSH узел. Для пользователя использование этого метода может стать причиной низкого быстродействия удаленного подключения.
Некорректная работа с NAT
При эксплуатации была выявлена проблема, при которой не удавалось установить соединение с RDSH узлами. В ходе диагностики выяснилось, что если доступ к узлу с компонентом Web Client осуществляется с помощью трансляции портов отличных от 443, то подключение не может быть установлено. Если транслировать внешний порт 443 в такой же внутренний, то подобной проблемы не возникает.
Итоги
Мнение
В ходе знакомства с технологиями у меня сложилось впечатление того, что они неплохо друг друга дополняют и могут практически полностью закрыть потребности как пользователей, так и администраторов.
Большой удачей является тот факт, что обе технологии могут работать вместе в гибридном варианте. Более того, они работают через один порт и через один и тот же сервис IIS, который устанавливается при развертывании, что также упрощает жизнь специалистам по эксплуатации.
Как уже упоминалось выше, при использовании некоторых хитростей можно расширить зону применения (публикация rdp клиента для дальнейшего подключения на компьютеры не входящие в коллекции) и предоставить нашим коллегам удаленный доступ вне зависимости от типа и конфигурации их ОС.
Также администраторы получают возможность централизовано (через свойства коллекций или Active Directory) управлять доступом и заниматься мониторингом подключений. Это очень удобно с точки зрения интеграции с уже существующей инфраструктурой. У специалистов по эксплуатации отпадает необходимость дружить другое ПО с учетными данными пользователей в Active Directory.
Коллеги! Если у вас есть замечания или дополнения по предмету этой статьи, прошу оставить комментарий. Возможно, они кому-то пригодятся в будущем.
Решил опубликовать веб-клиент на готовой терминальной ферме. Соединение через браузер устанавливается, производится вход и видны опубликованные приложения. Но при попытке запуска приложения выдает ошибку:
«Потеряно подключение к удаленному компьютеру. Возможно, есть проблема с сетевым подключением. Если это будет повторяться, обратитесь за помощью к своему администратору или специалисту службы технической поддержки.»
Все настроено верно, сертификаты, имена серверов, по обычному RDP и веб-доступу приложения из коллекции запускаются, по веб-клиенту указанная ошибка. Куда копать?
RDCB (он же брокер, он же шлюз он же веб-доступ) и RDSH на разных серверах….
Евгений, приветствую Вас!
Подскажите, менялся ли внешний порт подключения для клиента?
С чем-то подобным сталкивался и я, когда работал с webclient. Тогда я обратил внимание, что если менять порт подключения с 443 HTTPS на нестандартный, появляются ошибки которые Вы описываете.
Ошибка: «Ваш сеанс завершен, так как от удаленного компьютера получен непредвиденный сертификат проверки подлинности сервера. Обратитесь за помощью к своему администратору или специалисту службы технической поддержки.» подскажите решение.