Введение.
Шлюз служб терминалов — это служба роли, которая позволяет авторизованным удаленным пользователям подключаться к ресурсам во внутренней корпоративной сети с любого подключенного к интернету устройства, на котором может работать клиент подключения к удаленному рабочему столу.
Шлюз служб терминалов использует протокол удаленного рабочего стола (RDP) через HTTPS для установления безопасного зашифрованного соединения между удаленными пользователями в интернете и внутренними сетевыми ресурсами, на которых работают их приложения для повышения производительности.
Зачем использовать шлюз служб терминалов?
Шлюз служб терминалов предоставляет множество преимуществ, в том числе:
- Шлюз служб терминалов позволяет удаленным пользователям подключаться к внутренним сетевым ресурсам через Интернет с помощью зашифрованного соединения без необходимости настраивать соединения виртуальной частной сети (VPN).
- Шлюз служб терминалов предоставляет комплексную модель конфигурации безопасности, которая позволяет контролировать доступ к определенным внутренним сетевым ресурсам. Шлюз служб терминалов обеспечивает прямое RDP-подключение, а не предоставляет удаленным пользователям доступ ко всем внутренним сетевым ресурсам.
- Шлюз служб терминалов позволяет большинству удаленных пользователей подключаться к внутренним сетевым ресурсам, размещенным за брандмауэрами в частных сетях и через трансляторы сетевых адресов (NAT). При использовании шлюза служб терминалов для этого сценария не требуется выполнять дополнительную настройку сервера или клиентов шлюза служб терминалов.
Более подробно в источнике: Зачем использовать шлюз служб терминалов?
Установка роли.
1. Как всегда производим установку через графическую оснастку. Нажимаем на RD Gateway.
2. Выбираем наши брокеры.
3. Далее нас просят прописать адрес подключения. Так всё на одних и тех же серверах, что и сама точка подключения к ферме(HA), я установлю такое же имя. Мне не придется делать дополнительное имя в сертификате и DNS запись на внешнем хостинге.
4. После успешной установки роли, нас предупреждают об установке сертификата, чего мы и делаем.
Политики авторизации для шлюза терминалов.
После установки службы роли шлюза служб терминалов и настройки сертификата, необходимо создать политики авторизации подключения к службам терминалов (CAP), группы компьютеров и политики авторизации ресурсов (RAP).
Connection Authorization Policies (CAPs) – Позволяют указать, кто может подключаться к серверу RD Gateway.
Resource Authorization Policies (RAPs) – Позволяют указать внутренние сетевые ресурсы, к которым удаленные пользователи могут подключаться через сервер шлюза служб терминалов.
1. После установки, мы видим одну политику CAP.
– Данная политика говорит, что авторизовываться могут пользователи домена. Здесь всё просто, Вы можете создать свою группу, включить в них пользователей и поменять её здесь.
2. Политики RAP.
Здесь мы видим, к каким ресурсам можно подключаться.
RDG_AllDomainComputers – опять же разрешаем пользователям домена подключаться ко всем компьютерам домена.
RDG_RDConnectionBrokers – пользователи домена и наш брокер.
RDG-HighAvailabilityBroker_DNS_RR – позволяет соединение для нашей DNS записи, которую мы установили при настройке группы высокой доступности. То, что я задал такую же запись для шлюза, к этому отношения не имеет.
3. На самом деле, политика RDG_AllDomainComputers и RDG_RDConnectionBrokers пересекаются. Компьютеры домена уже очевидно хранят RDCB сервера, так зачем она ? С таким же успехом я могу выключить их обе и создать свою, которая включала бы RDCB и RDSH сервера.
Потому мне не нужна политика RDG_RDConnectionBrokers, я её отключаю, RDG_AllDomainComputers меня полностью устраивает. Конечный вариант выглядит так:
Экспорт и импорт политик между серверами.
Политики CAP и RAP не реплицируются между серверами. А это значит, что после изменения на одном сервере, их нужно скопировать на второй.
1. Добавляем второй сервер.
Видим, что политики не в актуальном состоянии:
2. Экспортируем настройки с первого:
И импортируем на второй.
Видим, что наши политики теперь в актуальном состоянии с первым сервером:
UDP Транспорт
Транспорт UDP имеет преимущество поддержки трафика в реальном времени по сетям с высокой задержкой. Транспорты HTTP и UDP более эффективны, чем RPC через HTTPS, а это означает, что они обеспечивают конечному пользователю лучшее взаимодействие при низкой пропускной способности или плохом подключении к Интернету.
Данный функционал стал доступен начиная с Windows Server 2012 и версии RDP клиента 8.0.
По умолчанию используется порт 3391.
1. Открываем в Windows Firewall сам порт. Сделаем это с помощью PowerShell.
New-NetFirewallRule -DisplayName "Allow 3391 UDP Port Transport" -Direction inbound -Profile Any -Action Allow -LocalPort 3391 -Protocol UDP– К слову говоря, то, что сам порт не открылся при установки роли, считаю баг и это справедливо только в Windows Server 2019.
2. Далее Вам остается сделать Port Forwarding на Вашем маршрутизаторе. Пример моего роутера Mikrotik:
Подведем итог
Настройки очередной роли для фермы серверов не составляют труда, пользоваться шлюзом можно уже с коробки, главное понимать, для чего есть политика CAP И RAP, не забывать держать их с одинаковыми настройками между серверами и не забыть пробросить UDP порт 3391 на Вашем маршрутизаторе.
Спасибо, что дочитали. С Уважением, Андрей.
