Сервер шлюза удаленных рабочих столов настройка windows 10

Remote Desktop Gateway это один из сервисов роли Remote Desktop Services в Windows Server для организации защищенного доступа из Интернета к службам рабочих столов и опубликованным RemoteApp приложениям через HTTPS шлюз. Сервер с ролью RD Gateway выступает в роли посредника между внешними клиентами и развернутыми внутри службами RDS. При использовании RDGW пользователям не нужно настраивать VPN для подключения к RDS в корпоративной сети. Для подключения используется стандартный клиент Remote Desktop Connection (mstsc.exe). В этой статье рассмотрим процесс развертывания шлюза Remote Desktop Gateway на Windows Server 2019 (инструкция применима для Windows Server 2022/2016 и 2012 R2).

Установка роли RDS-Gateway в Windows Server

Служба шлюза удаленных рабочих столов не является обязательным компонентом фермы RDS, поэтому ее нужно установить отдельно. В большинстве случае рекомендуется использовать отдельный сервер для развертывания RDGW или можно совместить его с RDWeb.

Предполагается, что в вашей сети уже развернута служба каталогов Active Directory и ферма серверов RDS.

Вы можете установить роль Remote Desktop Gateway через Server Manager (Add roles & Features -> Server Role -> Remote Desktop Services) или с помощью PowerShell.

При установке службы RDGW также устанавливаются веб сервер IIS и роль NPS (Network Policy Server).

Убедитесь, что роль RDS-Gateway установлена:

Get-WindowsFeature RDS*

Или установите роль в Windows Server с помощью команды Install-WindowsFeature:

Install-WindowsFeature RDS-Gateway -IncludeAllSubFeature –IncludeManagementTools

Создайте группы доступа в Active Directory с помощью консоли ADUC или с помощью PowerShell:

• rdgwExtUsers – группа пользователей, которым разрешено аутентифицироваться на RDGW;
• rdgwExternalAdmins – группа для доступа к терминальным серверам через RDGW;
• msk-rds-farm — должна включать в себя все хосты RDSH и RD Conneciton Broker, к которым вы хотите разрешить подключаться через шлюз удаленных рабочих столов.

Настройка политик доступа RDS Gateway

Для управления политиками и правилами доступа на RDGW используется консоль RD Gateway Manager (tsgateway.msc). Здесь нужно настроить два типа политик:

• Connection Authorization Policies (RD CAP) – определяют кому разрешено авторизоваться на шлюзе RDS;
• Resource Authorization Policies (RD RAP)– определяют кому и к каким ресурсам (компьютерам) внутренней сети разрешено подключаться через RDGW.

Создайте сначала политику RD CAP:

1. Разверните Policies -> Connection Authorization Policies и выберите пункт меню Create New Policy -> Wizard;
2. Укажите имя политики (rdgwExtUsers);
3. Выберите тип аутентификации (по паролю и/или по смарт карте), укажите группу пользователей, которым разрешено аутентифицироваться на RDGW;
4. В окне Enable or Disable Device Redirection можно указать какие устройства разрешено прокидывать в RDP сессию (буфер обмена, принтера, локальные диски и т.д.);
5. Далее можно настроить таймауты для RDP сеансов;
6. Подтвердите создание политики.

Также вы можете создать политику клиентского доступа RDGW с помощью PowerShell:

Import-Module -Name RemoteDesktopServices
New-Item -Path 'RDS:GatewayServerCAP' -Name 'rdgwAllowAutht-CAP' -UserGroups rdgwExtUsers -AuthMethod '1'

Затем создайте политику RD RAP:

1. В консоли RD Gateway Manager выберите Policies -> Resource Authorization Policies и выберите пункт меню Create New Policy -> Wizard;
2. Укажите имя политики: rdgwExternalAdmins;
3. Укажите имя группу, которой разрешено подключаться к внутренним RDS ресурсам;
4. На вкладке Network Resources нужно указать к каким RDS серверам разрешено подключаться вашим внешним пользователям (msk-rds-farm);
5. Далее укажите разрешенные для подключения порты. По-умолчанию рекомендуется открыть только стандартный RDP порт 3389. Но вы можете открыть и дополнительные порты;
6. Политика готова.

Правило RAP также можно создать с помощью PowerShell:
New-Item -Path RDS:GatewayServerRAP -Name allowextAdminMskRDS -UserGroups [email protected] -ComputerGroupType 1 -ComputerGroup [email protected]

Настройка SSL сертификата для Remote Desktop Gateway

Для защиты подключения к шлюзу RDS на нем нужно установить сертификат. Оптимально использовать коммерческий сертификат, выданный внешним центром сертификации. Возможно использовать бесплатного SSL сертификат Let’s Encrypt (установка Let’s Encrypt сертификата на IIS для Remote Desktop Gateway). Также вы можете использовать самоподписанный SSL сертификат Windows, но здесь имейте в виду что внешние клиенты должны обязательно доверять такому сертификату. Если клиент не доверяет сертификату на сервере RDGW, он не сможет подключиться к шлюзу (самоподписанные SSL сертификаты можно импортировать на клиентов вручную или через GPO) .

В поле Subject Name (CN) или Subject Alternative Name сертификата должно обязательно содержаться DNS имя сервера RDGW, которое будет использоваться для подключения внешними клиентами (доступное из интернета).

1. Откройте свойства сервера RDGW в консоли RD Gateway и перейдите на вкладку SSL Certificate;
2. В этом примере мы используем самоподписанный сертификат. Выберите пункт Create a self-signed certificate -> Create and Import Certificate;
3. Укажите имя сертификата (это DNS будет использоваться вашими клиентами для подключения к RDGW) и каталог, в который нужно сохранить сертификат (это сертификат нужно распространить на клиентов);

В Windows Server 2019 для подключения к RDGateway используются следующие порты:

• HTTPPort (default) —
  443/TCP
• UDPPort (default) —
  3391/UDP
  (использование транспортного протокола UDP не обязательно, но его поддержка позволяет значительно улучшить производительность туннеля и качество картинки в RDP сессии)

Не забудьте открыть (пробросить) эти порты на ваш RDGW хост на сетевом оборудовании.

Откройте консоль RDGW Manager и убедитесь, что в ней нет ошибок и все пункты зелёные.

Настройка RDP клиента для подключения шлюзу RD Gateway

Теперь можно настроить клиент Remote Desktop Connection для подключения к вашим внутренним RDS хостам через шлюз удаленных рабочих столов.

1. Запустите клиент
   mstsc.exe
   ;
2. На вкладке General укажите имя RDSH хоста, RDS фермы, или компьютера к которому вы хотите подключиться по RDP (можно также указать имя пользователя и использовать сохраненные учетные данные для RDP подключения);
3. Затем перейдите на вкладку Advanced и щелкните на кнопку Settings в разделе Connect from anywhere (Configure settings to connect through Remote Desktop Gateway when I am working remotely);
4. Выберите опцию Use these RD Gateway server settings, укажите внешнее DNS имя по которому доступен ваш RDGW сервер (напоминаю, что это имя должно быть указано в сертификате).Если вы используете нестандартный порт для RDGW, его нужно указать после имени сервера через двоеточие, например: gw.winitpro.ru:4443;
5. Чтобы не при подключении клиент не запрашивал пароль два раза, включите опцию Use my RD Gateway credentials for the remote computer;
6. Нажмите кнопку Connect и введите пароль для подключения к RDGW серверу в окне RD Gateway Server Credentials;
7. Клиент должен установить подключение с RDS/RDP хостом в вашей локальной сети;
8. Запустите консоль RD Gateway Manager, перейдите в раздел Monitoring и проверьте, что в списке отображается подключение вашего клиента.

Если вы используете утилиту RDCMan для RDP подключений, параметры RD Gateway можно задать на вкладке GatewaySetting. Включите опцию Use a TS Gateway server и укажите параметры подключения.

Отслеживать удачные и неудачные подключения пользователей через RDGW можно с помощью журнала событий Applications and Services Logs -> Microsoft -> Microsoft-Windows-TerminalServices-Gateway -> Operational.

При успешном подключении пользователя через RDGW в журнале появится событие с Event ID 205 от источника TerminalServices-Gateway

The user "winitprokbuldogov", on client computer "xx.xx.xx.xx", successfully connected to the remote server "msk-rdsman.winitpro.ru" using UDP proxy. The authentication method used was: "Cookie".

Если вы хотите запускать RemoteApp через RD Gateway, нужно добавить в *.rdp файл remoteapp следующие строки:

gatewayhostname:s:gw.winitpro.ru
gatewayusagemethod:i:1

В этой статье мы показали, как настроить роль Remote Desktop Gateway на Windows Server для реализации защищенного удаленного доступа в вашу сеть с помощью RDP over HTTPS.

Данная статья представляет собой пошаговую инструкцию по настройке Windows 10 в качестве терминального сервера с доступом по RDP.

После настройки, к одному компьютеру смогут одновременно подключаться несколько пользователей по RDP (Remote Desktop Protocol — протокол удалённого рабочего стола). Наиболее популярное применение данного решения — работа нескольких пользователей с файловой базой 1С.

Процесс настройки показан на примере Windows 10 Enterprise x64, однако данное руководство полностью подходит для установки на других ОС Windows.

.

.

Для настройки Windows 10 в качестве терминального сервера с доступом по RDP понадобятся:

1. Компьютер с установленной операционной системой Windows 10 и правами администратора, подключённый к локальной сети;

2. Компьютер в локальной сети, с которого будет производиться подключение и который имеет RDP клиент (прим. требуется ОС Windows XP/Vista/7/8/8.1/10 и т.д.);

3. Библиотека: RDP Wrapper Library.

Скачать RDP Wrapper Library v.1.6.2
Скачать c GitHub RDP Wrapper Library

.

I. Создание пользователя и настройка прав для доступа по RDP

1. Нажмите на значок поиска  , затем с помощью поисковой строки найдите и выберите Управление учетной записью (Рис.1).

Рис.1

.

2. В открывшемся окне выберите Семья и другие люди, затем нажмите Добавить пользователя для этого компьютера (Рис.2).

Рис.2

.

3. Нажмите на пункт У меня нет данных для входа этого человека (Рис.3).

Рис.3

.

4. Нажмите на пункт Добавить пользователя без учетной записи Майкрософт (Рис.4).

Рис.4

.

5. В соответствующих полях введите имя пользователя (прим. в данном примере это UserRDP), пароль для новой учётной записи и подсказку для пароля, затем нажмите Далее (Рис.5).

Рис.5

.

6. В окне параметров Вы увидите нового пользователя (прим. в данном примере это UserRDP) (Рис.6).

Рис.6

.

7. Нажмите на значок поиска  , затем с помощью поисковой строки найдите и выберите Этот компьютер, через правую кнопку мыши откройте меню и нажмите Управлять (Рис.7).

Рис.7

.

8. В открывшемся окне выберите: Служебные программы > Локальные пользователи и группы > Пользователи, затем выберите пользователя (прим. в данном примере это UserRDP), перейдите на вкладку Членство в группах и нажмите Добавить… (Рис.8).

Рис.8

.

9. Нажмите Дополнительно… (Рис.9).

Рис.9

.

10. Нажмите Поиск, выберите из списка Пользователи удаленного рабочего стола и нажмите OK (Рис.10).

Рис.10

.

11. Нажмите OK (Рис.11).

Рис.11

.

12. Нажмите Применить, затем OK (Рис.12).

Рис.12

.

II. Настройка терминального сервера с доступом по RDP

1. Нажмите на значок поиска  , затем с помощью поисковой строки найдите и выберите Система (Рис.13).

Рис.13

.

2. Нажмите Настройка удалённого доступа, в открывшемся окне перейдите на вкладку Удалённый доступ, выберите пункт Разрешить удалённые подключения к этому компьютеру, затем нажмите Применить и OK (Рис.14).

Рис.14

.

3. Распакуйте (прим. с помощью WinRAR или просто открыть через Проводник) скачанную Вами ранее библиотеку RDP Wrapper Library. Откройте папку и запустите от имени администратора (прим. используя правую кнопку мыши) файл install, после чего начнётся установка (Рис.15).

Рис.15

.

4. После окончания установки нажмите любую клавишу (Рис.16).

Рис.16

.

5. Нажмите на значок поиска  , затем с помощью поисковой строки найдите и выберите Выполнить (Рис.17).

Рис.17

.

6. В открывшемся окне введите gpedit.msc и нажмите OK (Рис.18).

Рис.18

.

7. Выберите: Конфигурация компьютера > Административные шаблоны > Компоненты Windows > Службы удалённых рабочих столов > Узел сеансов удалённых рабочих столов > Подключения > Ограничить количество подключений (Рис.19).

Рис.19

.

8. В открывшемся окне выберите пункт Включить, установите в параметрах разрешённое количество подключений к удалённым рабочим столам на 999999, затем нажмите Применить и OK. Перезагрузите компьютер (Рис.20).

Рис.20

.

III. Подключение к удаленному рабочему столу

1. Используя второй компьютер, находящийся в той же локальной сети, нажмите Пуск, с помощью поисковой строки найдите, а затем выберите Подключение к удалённому рабочему столу (Рис.21).

Рис.21

.

2. В открывшемся окне ведите имя компьютера к которому следует подключиться (прим. Тот, на котором производились все настройки), затем нажмите Подключить (Рис.22).

Рис.22

.

3. Прежде всего, выберите пользователя (прим. в данном примере это UserRDP) и введите пароль от учётной записи, который Вы указывали ранее (прим. см. Рис.5), затем нажмите OK (Рис.23).

Рис.23

.

4. В появившемся окне нажмите Да, после чего начнётся сеанс удаленного подключения (Рис.24).

Рис.24

.

Настройка Windows 10 в качестве терминального сервера с доступом по RDP завершена!
.

Опубликовано: 08.07.2020

Используемые термины: Remote Desktop Gateway, Active Directory, Терминальный сервер.

В данном руководстве мы рассмотрим развертывание роли шлюза удаленных рабочих столов (Remote Desktop Gateway или RDG) на отдельном сервере с Windows Server 2019. Действия будут аналогичны для Windows Server 2012 и 2016 (даже, в основных моментах, 2008 R2). Предполагается, что в нашей инфраструктуре уже имеются:

1. Служба каталогов Active Directory — настроено по инструкции Как установить роль контроллера домена на Windows Server.

2. Два терминальных сервера — настроено по инструкции Установка и настройка терминального сервера на Windows Server.

Пошагово, мы выполним следующие действия:

Установка роли

Открываем Диспетчер серверов:

Переходим в Управление — Добавить роли и компоненты:

При появлении окна приветствия нажимаем Далее (при желании, можно поставить галочку Пропускать эту страницу по умолчанию):

На страницы выбора типа установки оставляем выбор на Установка ролей или компонентов:

Выбираем целевой сервер — если установка выполняется на сервере локально, то мы должны увидеть один сервер для выбора:

Ставим галочку Службы удаленных рабочих столов:

Дополнительные компоненты нам не нужны:

… просто нажимаем Далее.

На странице служб удаленных рабочих столов идем дальше:

Выбираем конкретные роли — нам нужен Шлюз удаленных рабочих столов. После установки галочки появится предупреждение о необходимости поставить дополнительные пакеты — кликаем по Добавить компоненты: 

Откроется окно для настроек политик:

… нажимаем Далее.

Откроется окно роли IIS:

… также нажимаем Далее.

При выборе служб ролей веб-сервера ничего не меняем:

… и идем дальше.

В последнем окне ставим галочку Автоматический перезапуск конечного сервера, если требуется:

Нажимаем Установить:

Дожидаемся окончания установки роли:

Сервер может уйти в перезагрузку.

Настройка RDG

Для настройки Microsoft Remote Desktop Gateway мы создадим группу компьютеров в Active Directory, настроим политику для RDG и создадим сертификат.

Создание групп для терминальных серверов

Политика ресурсов позволит задать нам конкретные серверы, на которые терминальный шлюз позволит нам подключаться. Для этого мы откроем консоль Active Directory — Users and computers (Пользователи и компьютеры Active Directory) и создаем группу:

* в данном примере мы создаем группу All terminals в организационном юните Servers Group. Это группа безопасности (Security), локальная в домене (Domain local).

Добавим в нашу группу терминальные серверы:

* в данном примере у нас используются два сервера — Terminal-1 и Terminal-2.

Закрываем консоль Active Directory — Users and computers.

Настройка политик

Для предоставления доступа к нашим терминальным серверам, создадим политики для подключений и ресурсов.

В диспетчере сервера переходим в Средства — Remote Desktop Services — Диспетчер шлюза удаленных рабочих столов:

Раскрываем сервер — кликаем правой кнопкой по Политики — выбираем Создание новых политик безопасности:

Устанавливаем переключатель в положении Создать политику авторизации подключений к удаленным рабочим столам и авторизации ресурсов удаленных рабочих столов (рекомендуется):

Даем название политике:

Задаем параметры авторизации:

* мы указали, что пользователи должны подтверждать право вводом пароля, также мы указали, что для применения политики они должны принадлежать группе Domain Users.

В следующем окне есть возможность настроить ограничения использования удаленного рабочего стола. При желании, можно их настроить:

* в нашем случае ограничений нет. При необходимости, устанавливаем переключатель в положение Отключить перенаправление для следующих типов клиентских устройств и оставляем галочки пункты для ограничений.

Далее настраиваем временные ограничения использования удаленного подключения. Если в этом есть необходимость, оставляем галочки в состоянии Включить и указываем количество минут, по прошествии которых сеанс будет отключен:

В следующем окне мы увидим вне введенные настройки:

Идем далее.

Откроется страница создания политики для авторизации ресурса — задаем для нее название:

Указываем группу пользователей, для которой будет применяться политика:

* как и при создании первой политики, мы добавили группу Domain Users.

Теперь выбираем группу ресурсов, на которую будет разрешен доступ со шлюза терминалов:

* мы выбрали группу, созданную нами ранее в AD.

Указываем разрешенный для подключения порт или диапазон портов:

* в данном примере мы разрешим подключение по порту 3389, который используется по умолчанию для RDP.

Нажимаем Готово:

Политики будут созданы.

Настройка сертификата

Для работы системы нам необходим сертификат, который можно купить или получить бесплатно от Let’s Encrypt. Однако, с некоторыми неудобствами, будет работать и самоподписанный. Мы рассмотрим вариант настройки с ним.

Запускаем «Диспетчер шлюза удаленных рабочих столов» — кликаем правой кнопкой по названию нашего сервера — выбираем Свойства:

Переходим на вкладку Сертификат SSL:

Выбираем вариант Создать сомозаверяющий сертификат и кликаем по Создать и импортировать сертификат:

Задаем или оставляем имя для сертификата — нажимаем OK:

Мы увидим информацию о создании сертификата:

Консоль диспетчера шлюза перестанет показывать ошибки и предупреждения:

Сервер готов к работе.

Подключение к серверу терминалов через шлюз

Выполним первое подключение с использованием шлюза. В качестве клиентской операционной системы могут использоваться Windows, Linux, Mac OS. Рассмотрим пример на Windows 10.

Запускаем «Подключение к удаленному рабочему столу» (приложение можно найти в Пуск или ввести команду mstsc). На вкладке Общие вводим локальное имя конечного сервера, к которому мы хотим подключиться:

* в нашем случае мы будем подключаться к серверу terminal-1.dmosk.local.

Переходим на вкладку Дополнительно и кликаем по Параметры:

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

* важно указать именно имя сервера, а не IP-адрес. В моем примере имя сервера rdp.dmosk.local (данное имя не является правильным внешним, но это только пример).

Кликаем Подключить:

Если мы используем самозаверенный сертификат, приложение выдаст ошибку. Кликаем по Просмотреть сертификат:

Переходим на вкладку Состав и кликаем Копировать в файл:

Указываем путь для выгрузки файла:

Открываем папку, куда сохранили сертификат. Кликаем по сохраненному файлу правой кнопкой и выбираем Установить сертификат:

Выбираем Локальный компьютер — Далее:

В качестве размещения сертификата выбираем Доверенные корневые центры сертификации:

Импортируем сертификат.

После снова пробуем подключиться к удаленному рабочему столу через шлюз:

Система запросит логин и пароль для подключения (возможно, дважды) — вводим данные для учетной записи с правами на подключение (на основе настройки политики RDG).

Настройка Remoteapp через Gateway

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

…
gatewayhostname:s:rdg.dmosk.local
gatewayusagemethod:i:1
…

* где:

• gatewayhostname:s:rdg.dmosk.local — добавленная строка. Настройка говорит, что если при подключении к серверу нужно использовать шлюз, то это должен быт rdg.dmosk.local.
• gatewayusagemethod:i:1 — отредактированная строка. Указывает, что необходимо использовать шлюз.

Пробуем подключиться.

Несколько терминальных серверов и dns round robin

При наличие нескольких серверов терминалов, мы можем создать несколько записей в DNS, чтобы получать по round robin разные серверы:

Однако, при попытке подключиться к незарегистрированному серверу мы увидим ошибку:

Для решения переходим в настройку шлюза — кликаем правой кнопкой по Политики авторизации ресурсов и выбираем Управление локальными группами компьютеров:

Выбираем нужную группу компьютеров и нажимаем Свойства:

* в моем случае это была единственная группа, созданная по умолчанию.

На вкладке Сетевые ресурсы добавляем имя, созданное в DNS:

Теперь подключение будет выполняться без ошибок.

Возможные ошибки

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

1. Учетная запись пользователя не указана в списке разрешений шлюза удаленных рабочих столов.

Причиной является отсутствие пользователя, под которым идет подключение к шлюзу, в группе, которой разрешено использование политики. Для решения проблемы проверяем настройки политики — группы пользователей, которым разрешено использование политики и к каким ресурсам разрешено подключение. В итоге, наш пользователь должен быть в нужной группе, а терминальный сервер, к которому идет подключение должен быть указан в соответствующей группе ресурсов.

2. Возможно, удаленный компьютер указан в формате NetBIOS (например, computer1), но шлюз удаленных рабочих столов ожидает полное доменное имя или IP-адрес (например, computer1.fabrikam.com или 157.60.0.1).

Обращение к терминальному серверу выполняется по незарегистрированному имени. Необходимо проверить настройку в клиенте подключения или зарегистрировать ресурс, как мы это делали при настройке нескольких терминальных серверов.

3. Сертификат шлюза удаленных рабочих столов просрочен или отозван.

В данном случае нужно проверить, какой сертификат привязан к RDG. Также нужно убедиться, что привязанный сертификат, на самом деле, не просрочен или отозван. В крайнем случае, можно заново создать сертификат.

Как настроить Remote Desktop Gateway

В инструкции описана установка и настройка шлюза удаленных рабочих столов Remote Desktop Gateway (Terminal Services Gateway) в домене Active Directory. Описана настройка SSL-сертификата для шлюза и пример подключения.

Что такое Remote Desktop Gateway?

Виртуальный сервер на базе Windows

RD Gateway предоставляет множество преимуществ:

Примечание: для подключения через шлюз ваш сервер должен входить в домен Active Directory, настройка шлюза может выполняться на любом сервере в домене от имени администратора домена.

Установка роли

Выберите ваш сервер из пула.

Далее вы увидите краткую информацию о роли.

Для работы этого сервиса необходимо веб-сервер IIS и дополнительные административные инструменты, они будут предложены автоматически, если не были установлены ранее.

Добавьте данные функции.

Установите все выбранные компоненты на VPS с помощью кнопки Install.

Создание политики авторизации подключения и ресурсов

Перед вами откроется менеджер шлюза.

В открывшемся окне выберите Create RD CAP and RD RAP (recommended), чтобы с помощью одного процесса настроить обе политики.

Введите удобное имя для политики авторизации подключения.

На следующем шаге выберите наиболее удобный метод аутентификации: пароль или smartcard. Далее добавьте группы пользователей которые смогут подключаться к этому RD Gateway серверу, для это нажмите Add Group.

Выберите нужную группу, например администраторов домена или контроллеры домена. Выполнить поиск можно с помощью кнопки Check Names.

После добавления групп можно переходить к следующему действию.

Выберите устройства и ресурсы удаленной сессии, которые будут доступны клиентам использующие шлюз.

Выберите нужные для вас значения таймаутов: времени простоя и времени работы сессии.

Перепроверьте выбранные настройки.

Далее вы перейдете к настройке политики авторизации ресурсов. Введите удобное имя политики.

Также добавьте группы пользователей, которые смогут подключаться к сетевым ресурсам.

Выберите группу, содержащую серверы, на которых указанные группы пользователей могли бы работать с удаленным рабочим столом. Для этого нажмите Browse.

В этом примере используется встроенная группа под названием Domain Controllers. Вы можете создавать дополнительные группы, содержащие серверы, которые связаны или принадлежат к определенным отделам или сотрудникам. Таким образом, на предыдущих шагах вы можете назначать группы на основе потребностей пользователей и разрешать им доступ только к определенным серверам.

Убедитесь, что добавлена нужная группа.

Если порт по умолчанию удаленного рабочего стола на серверах был изменен, используйте эту страницу для указания порта. В противном случае выберите разрешение подключения только к порту 3389.

Проверьте указанные настройки для политики.

Далее отобразится результат создания политик.

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

Установка SSL-сертификата

Для шлюза удаленного рабочего стола должен быть установлен SSL-сертификат. Чтобы установить SSL-сертификат, щелкните имя сервера удаленного рабочего стола в консоли управления удаленным рабочим столом и выберите View or modify certificate properties.

Возможно 3 способа импорта сертификатов:

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

Введите имя сертификата и его расположение на сервере. Нажмите OK.

Сертификат будет сгенерирован.

Теперь самоподписанный SSL-сертификат успешно установлен на TCP-порт 443 (порт SSL по умолчанию).

В целях безопасности рекомендуется изменить порт SSL для шлюза удаленных рабочих столов на другой номер. Обычно компании делают это, чтобы попытаться обмануть хакеров, которые могут ориентироваться на стандартный порт 443.

Чтобы изменить номер порта для шлюза RD, щелкните правой кнопкой мыши имя сервера и выберите свойства в консоли управления удаленным рабочим столом (Action →Properties).

Измените значение HTTP-порта на любое удобное значение и сохраните изменения.

Подтвердите изменения, нажав Yes.

Подключение через шлюз

Для подключения откройте стандартное приложение Windows Подключение к удаленному рабочему столу (mstsc.exe). На вкладке Дополнительно нажмите на кнопку Параметры.

В открывшемся окне выберите Использовать следующие параметры сервера шлюза удаленных рабочих столов. Введите имя сервера в следующем формате и нажмите OK:
rdgateway. :

На вкладке Общие в поле Компьютер введите домен, в поле Пользователь имя пользователя и нажмите Подключить. При необходимости можете сохранить параметры входа.

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

Введите пароль от учетной записи.

В результате будет произведено подключение к удаленному рабочему столу через шлюз RD Gateway. Это можно проверить с помощью команды tracert:

Из вывода видно, что трассировка идет через шлюз.

P. S. Другие инструкции:

Ознакомиться с другими инструкциями вы можете на нашем сайте. А чтобы попробовать услугу — кликните на кнопку ниже.

Источник

Как сделать работу с Microsoft Remote Desktop лучше

Хочу поделиться несколькими советами по настройке удаленного подключения к рабочим местам по RDP. Расскажу как проапгрейдить древний RPC-HTTP до UDP, похвалю и поругаю Windows 10 и AVC, разберу решение нескольких типичных проблем.

Считаем, что для подключения используется Remote Desktop Gateway (RDGW), а в качестве серверов выступают рабочие станции. Использовать RDGW очень удобно, потому что шлюз становится общей точкой входа для всех клиентов. Это дает возможность лучше контролировать доступ, вести учет подключений и их продолжительность. Даже если VPN позволяет подключиться к рабочим машинам напрямую — это не лучший вариант.

RDGW настраивается быстро, просто, а Let’s Encrypt и win-acme легко решают проблему с доверенным сертификатом.

Есть три транспортных протокола по которым клиент может подключиться с серверу:

RPC-HTTP ( плохо )
HTTP ( лучше )
HTTP+UDP ( отлично )

Под сервером будем понимать рабочую машину, под клиентом — домашнюю.
Первое, с чего стоит начать, это «плохо» превратить в «отлично».

Апгрейд RPC-HTTP до HTTP

Подключение в сессию с использованием RPC-HTTP легко определить по внешнему виду полоски подключения.

Здесь нет значка качества подключения (о нем ниже), а значит мы используем старый RPC, обернутый в TLS — это очень медленно. Дело, конечно, не только в обертке — сам протокол меняется с каждым релизом ОС, меняются кодеки, алгоритмы упаковки изображения. Чем свежее протокол, тем лучше.

Windows XP или Vista

В XP можно поднять протокол с 5.1 до 7. Хотфикс windowsxp-kb969084-x86.exe

Но RDP 7 не работает по HTTP и UDP. Поможет только апгрейд клиента и сервера до Windows 7 и новее.

Сначала надо обновить протокол до RDP 8.1, а затем включить его. Поддержка добавляется обновлениями, которые сгруппированы в один загрузочный пакет:

www.microsoft.com/en-US/download/details.aspx?id=40986
Windows6.1-KB2574819-v2-x64.msu
windows6.1-kb2592687-x64.msu
Windows6.1-KB2830477-x64.msu
Windows6.1-KB2857650-x64.msu
Windows6.1-KB2913751-x64.msu (заменен kb2923545)

Так вы получите и свежий клиент mstsc.exe, и поддержку RDP 8.1 серверной части ОС.
Было:

После этого протокол надо включить ключом реестра (для этого можно использовать adm шаблон в комплекте с Windows 7).

Включите поддержку транспорта UDP в групповой политике.

Перезагружаем сервер с Windows 7. Тот самый случай, когда может потребоваться перезагрузиться дважды — значение в реестре должно быть установлено до того, как включился RDP, а групповая политика применяется позже.

Если все получилось, то при подключении к серверу в полоске сессии появится иконка качества подключения (как в телефоне для мобильной сети):

Протокол работает «из коробки».

Апгрейд HTTP до HTTP+UDP

Если ваша сеть не склонна к потере пакетов, UDP существенно (для CAD — радикально) повышает отзывчивость сервера за счет использования FEC для сокращения ретрансмиссии, а также перехода подтверждения доставки пакетов с уровня системного стека TCP/IP на уровень протокола RDP-UDP.

От каждого клиента подключается одна основная управляющая сессия по HTTP (в этом канале также передается клавиатура/мышь), плюс одна или несколько сессий UDP для передачи картинки или других виртуальных каналов.

Мы коснемся только верхушки айсберга. Есть 3 различных версии протокола RDP-UDP. Кроме того, сам UDP может работать в двух режимах UDP-R (reliable) и UDP-L (lossy). С Microsoft ничего просто не бывает. Но поскольку от нас здесь ничего не зависит, просто имейте в виду — чем новее операционная система, теме более современный протокол используется.

Снаружи RDP-UDP оборачивается в Datagram Transport Layer Security (DTLS) RFC4347, в чем вы можете убедиться открыв Wireshark.

Что же нужно для включения UDP?

RDP-UDP поддерживается начиная с RDP 8.

На клиенте должен быть открыт порт udp/3389. Если вы его закрыли локальным firewall, ACL на свитче или внешнем файрволле — порт надо открыть.

Для сервера Remote Desktop Gateway к порту tcp/443 надо открыть udp/3391.

Порт можно поменять, вот как он настраивается:

Для Windows 7 обязательно должен быть включен NLA (Network Level Authentication).

Можно включить в групповой политике

В чем связь непонятно. Но без NLA на 7-ке не работает, на более свежих релизах NLA для работы UDP не обязателен.

После установления сессии по HTTP, клиент и сервер пробуют согласовать подключение по UDP. Если есть выпадение пакетов или задержки, то сессия UDP не запустится. Точный алгоритм отказа согласования UDP до конца не понятен.

Если все настроено, то после подключения нажмите на кнопку качества связи. В окошке будет указано, что согласован UDP.

На шлюзе это выглядит так:

Если у вас Windows 10 и на сервере, и на клиенте, то это самый быстрый и беспроблемный вариант. В Microsoft активно дорабатывают RDP, и в свежих релизах 10 вы можете рассчитывать на неплохую скорость работы. Коллеги не смогли обнаружить разницу между Citrix и Windows 10 RDP по скорости работы в AutoCAD.

Согласование AVC с аппаратным кодированием можно увидеть в журнале событий (подробнее в статье выше):

Замечу только, что проблема искажений все же есть даже с h.264 4:4:4. Она сразу бросается в глаза если работать в PowerShell ISE — текст ошибок выводится с неприятным искажением. Причем на скриншоте и на фотографии все отлично. Волшебство.

Также косвенным признаком работы AVC являются время от времени появляющиеся зеленые квадраты по углам.

AVC и аппаратное кодирование в свежих билдах должно работать из коробки, но групповая политика никогда не бывает лишней:

С учетом того, что AVC кодируется аппаратно видеокартой, то обновить драйверы видео — хорошая идея.

О проблемах

Если проблема возникает на Windows XP или Vista, попробуйте сначала обновить протокол до 7 версии (писал в начале статьи). Обязательно включите поддержку CredSSP. На сайте Microsoft статьи уже удалены, но Интернет помнит.

Если не помогло — «доктор говорит в морг, значит в морг». Что испытала на себе операционная система за последние 15 лет — лучше об этом даже и не думать.

Иногда помогает отключение NLA на сервере. Выяснить причину не получилось, домашние машины все разные.

Некоторые клиенты пытаются авторизоваться с использованием NTLMv1. Причины разные, но исправить на клиенте можно так:

Если вы молоды и дерзки ничего не боитесь, то есть более радикальное решение — отключение Channel Binding на Remote Desktop Gateway

Делать так не надо. Но мы делали. 🙂 Для клиента, который настаивал (нет не так, НАСТАИВАЛ) что NTLMv1 на рабочих станциях ему необходим. Не знаю, может там серверы на NT4 без SP еще в работе.

Отключение RDP 8+ в Windows 10

Если ничего не помогает, а идеи кончились, можно воспользоваться недокументированным ключом для даунгрейда протокола RDP до 7 версии.

Сам не делал, и вам не советую. Но кому-то, пишут, что помогает.

Компонент Dr.Web SpIDerGate может запретить подключение. В этом случае возвращается ошибка:

В статистике Dr.Web будет запись:

В комментариях к этой статье со мной связался сотрудник Dr.Web и наша проблема решилась в ближайшем обновлении антивирусных баз.
Если у вас такая же ошибка, лучше обратиться в поддержку.
Как временное решение, можно внести URL вашего RDGW в исключения:

И только если не помогло отключить компонент SpIDer Gate полностью.

Встретился списанный компьютер из какой-то компании, где в качестве системного прокси был прописан местный TMG, и подключение к RDGW не работало. Это можно исправить так:

Переключение раскладок клавиатуры

Иногда приезжают лишние раскладки. Можно отключить проброс раскладки с клиента

Масштабирование приходит с клиентской машины, и если на домашнем ноутбуке стоит 125%, то и на рабочей машине будет так же. На серверах это можно отключить, а на рабочих станциях не нашел как. Но в магазине приложений Windows 10 есть «современный» клиент.

В нем можно настроить DPI:

Как мониторить шлюз с RDGW

Есть счетчик производительности «Шлюз служб терминаловТекущие подключения», который немного глючит, если нет подключений или сервер долго не перезагружался. Он показывает именно число подключений, но как мы помним, для HTTP+UDP их как минимум два, а может быть и больше. Поэтому это не совсем объективный показатель числа подключений сотрудников.

Есть класс WMI Win32_TSGatewayConnection. Его содержимое соответствует тому, что вы видите в разделе «Наблюдение» шлюза удаленных рабочих столов.

С ним число подключений можно посчитать поточнее:

Just for fun есть утилита Remote Display Analyzer. Бесплатная версия мне ничего полезного не показала, но вдруг кому-то пригодится.

А как же тонкий тюнинг, настройка нескольких десятков параметров сессии?

Здесь уместен принцип Парето: 20% усилий дают 80% результата. Если вы готовы инвестировать ваше время в оставшиеся 20% результата — отлично. Только имейте в виду, что когда вы читаете статью о настройке протокола в Windows 7, то не знаете про какой протокол писал автор — 7, 8 или 8.1. Когда читаете про Windows 10 без указания релиза — проблемы те же. Например, пишут что в свежих билдах Windows 10 кодек AVC/h.264 изменился на RDPGFX_CODECID_AVC444V2, а в Windows Server 2016 остался RDPGFX_CODECID_AVC444.

Из всех таких советов мы используем только две настройки:

Вот мы и подошли к концу статьи. Хотел покороче, а получилось как всегда. Рад, если кому-то эти советы помогут сэкономить время или улучшить настройку своей инфраструктуры.

Источник

Установка и использование Remote Desktop Gateway

В данном руководстве мы рассмотрим развертывание роли шлюза удаленных рабочих столов (Remote Desktop Gateway или RDG) на отдельном сервере с Windows Server 2019. Действия будут аналогичны для Windows Server 2012 и 2016 (даже, в основных моментах, 2008 R2). Предполагается, что в нашей инфраструктуре уже имеются:

1. Служба каталогов Active Directory — настроено по инструкции Как установить роль контроллера домена на Windows Server.

Пошагово, мы выполним следующие действия:

Установка роли

Открываем Диспетчер серверов:

При появлении окна приветствия нажимаем Далее (при желании, можно поставить галочку Пропускать эту страницу по умолчанию):

На страницы выбора типа установки оставляем выбор на Установка ролей или компонентов:

Выбираем целевой сервер — если установка выполняется на сервере локально, то мы должны увидеть один сервер для выбора:

Ставим галочку Службы удаленных рабочих столов:

Дополнительные компоненты нам не нужны:

. просто нажимаем Далее.

На странице служб удаленных рабочих столов идем дальше:

Выбираем конкретные роли — нам нужен Шлюз удаленных рабочих столов. После установки галочки появится предупреждение о необходимости поставить дополнительные пакеты — кликаем по Добавить компоненты:

Откроется окно для настроек политик:

. нажимаем Далее.

Откроется окно роли IIS:

. также нажимаем Далее.

При выборе служб ролей веб-сервера ничего не меняем:

В последнем окне ставим галочку Автоматический перезапуск конечного сервера, если требуется:

Нажимаем Установить:

Дожидаемся окончания установки роли:

Сервер может уйти в перезагрузку.

Настройка RDG

Для настройки Microsoft Remote Desktop Gateway мы создадим группу компьютеров в Active Directory, настроим политику для RDG и создадим сертификат.

Создание групп для терминальных серверов

* в данном примере мы создаем группу All terminals в организационном юните Servers Group. Это группа безопасности (Security), локальная в домене (Domain local).

Добавим в нашу группу терминальные серверы:

* в данном примере у нас используются два сервера — Terminal-1 и Terminal-2.

Настройка политик

Для предоставления доступа к нашим терминальным серверам, создадим политики для подключений и ресурсов.

Устанавливаем переключатель в положении Создать политику авторизации подключений к удаленным рабочим столам и авторизации ресурсов удаленных рабочих столов (рекомендуется):

Даем название политике:

Задаем параметры авторизации:

* мы указали, что пользователи должны подтверждать право вводом пароля, также мы указали, что для применения политики они должны принадлежать группе Domain Users.

В следующем окне есть возможность настроить ограничения использования удаленного рабочего стола. При желании, можно их настроить:

* в нашем случае ограничений нет. При необходимости, устанавливаем переключатель в положение Отключить перенаправление для следующих типов клиентских устройств и оставляем галочки пункты для ограничений.

Далее настраиваем временные ограничения использования удаленного подключения. Если в этом есть необходимость, оставляем галочки в состоянии Включить и указываем количество минут, по прошествии которых сеанс будет отключен:

В следующем окне мы увидим вне введенные настройки:

Откроется страница создания политики для авторизации ресурса — задаем для нее название:

Указываем группу пользователей, для которой будет применяться политика:

* как и при создании первой политики, мы добавили группу Domain Users.

Теперь выбираем группу ресурсов, на которую будет разрешен доступ со шлюза терминалов:

* мы выбрали группу, созданную нами ранее в AD.

Указываем разрешенный для подключения порт или диапазон портов:

* в данном примере мы разрешим подключение по порту 3389, который используется по умолчанию для RDP.

Нажимаем Готово:

Политики будут созданы.

Настройка сертификата

Для работы системы нам необходим сертификат, который можно купить или получить бесплатно от Let’s Encrypt. Однако, с некоторыми неудобствами, будет работать и самоподписанный. Мы рассмотрим вариант настройки с ним.

Переходим на вкладку Сертификат SSL:

Выбираем вариант Создать сомозаверяющий сертификат и кликаем по Создать и импортировать сертификат:

Мы увидим информацию о создании сертификата:

Консоль диспетчера шлюза перестанет показывать ошибки и предупреждения:

Сервер готов к работе.

Подключение к серверу терминалов через шлюз

Выполним первое подключение с использованием шлюза. В качестве клиентской операционной системы могут использоваться Windows, Linux, Mac OS. Рассмотрим пример на Windows 10.

Запускаем «Подключение к удаленному рабочему столу» (приложение можно найти в Пуск или ввести команду mstsc). На вкладке Общие вводим локальное имя конечного сервера, к которому мы хотим подключиться:

* в нашем случае мы будем подключаться к серверу terminal-1.dmosk.local.

Переходим на вкладку Дополнительно и кликаем по Параметры:

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

* важно указать именно имя сервера, а не IP-адрес. В моем примере имя сервера rdp.dmosk.local (данное имя не является правильным внешним, но это только пример).

Кликаем Подключить:

Если мы используем самозаверенный сертификат, приложение выдаст ошибку. Кликаем по Просмотреть сертификат:

Переходим на вкладку Состав и кликаем Копировать в файл:

Указываем путь для выгрузки файла:

Открываем папку, куда сохранили сертификат. Кликаем по сохраненному файлу правой кнопкой и выбираем Установить сертификат:

В качестве размещения сертификата выбираем Доверенные корневые центры сертификации:

После снова пробуем подключиться к удаленному рабочему столу через шлюз:

Система запросит логин и пароль для подключения (возможно, дважды) — вводим данные для учетной записи с правами на подключение (на основе настройки политики RDG).

Настройка Remoteapp через Gateway

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

Несколько терминальных серверов и dns round robin

При наличие нескольких серверов терминалов, мы можем создать несколько записей в DNS, чтобы получать по round robin разные серверы:

Однако, при попытке подключиться к незарегистрированному серверу мы увидим ошибку:

Выбираем нужную группу компьютеров и нажимаем Свойства:

* в моем случае это была единственная группа, созданная по умолчанию.

На вкладке Сетевые ресурсы добавляем имя, созданное в DNS:

Теперь подключение будет выполняться без ошибок.

Возможные ошибки

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

1. Учетная запись пользователя не указана в списке разрешений шлюза удаленных рабочих столов.

Причиной является отсутствие пользователя, под которым идет подключение к шлюзу, в группе, которой разрешено использование политики. Для решения проблемы проверяем настройки политики — группы пользователей, которым разрешено использование политики и к каким ресурсам разрешено подключение. В итоге, наш пользователь должен быть в нужной группе, а терминальный сервер, к которому идет подключение должен быть указан в соответствующей группе ресурсов.

2. Возможно, удаленный компьютер указан в формате NetBIOS (например, computer1), но шлюз удаленных рабочих столов ожидает полное доменное имя или IP-адрес (например, computer1.fabrikam.com или 157.60.0.1).

Обращение к терминальному серверу выполняется по незарегистрированному имени. Необходимо проверить настройку в клиенте подключения или зарегистрировать ресурс, как мы это делали при настройке нескольких терминальных серверов.

3. Сертификат шлюза удаленных рабочих столов просрочен или отозван.

В данном случае нужно проверить, какой сертификат привязан к RDG. Также нужно убедиться, что привязанный сертификат, на самом деле, не просрочен или отозван. В крайнем случае, можно заново создать сертификат.

Источник

Для того чтобы повысить уровень безопасности Windows-сервера бывает недостаточно сменить TCP-порт RDP . Рассмотрим настройку шлюза  удаленных рабочих столов (Remote Desktop Gateway / Terminal Services Gateway) в домене Active Directory.

Remote Desktop Gateway, что это?

Remote Desktop Gateway — это роль Windows-сервера, обеспечивающая защищенное соединение, с помощью протокола SSL, с сервером по RDP. Главное преимущество этого решения в том, что не требуется развертывание VPN-сервера, для этого и используется шлюз.

Следует отметить, что начиная с Windows Server 2008 R2, были изменены названия всех служб удаленных рабочих столов. Именуемые ранее службы Terminal Services были переименованы в Remote Desktop Services.

Преимущества Remote Desktop Gateway в следующем:

• Используя зашифрованное соединение, шлюз позволяет подключаться к внутренним сетевым ресурсам без необходимости использования VPN-соединения удаленными пользователями;
• Шлюз дает возможность контроля доступа к определенным сетевым ресурсам, тем самым реализуя комплексную защиту;
• Шлюз разрешает подключение к сетевым ресурсам, которые размещены за межсетевыми экранами в частных сетях или NAT;
• С помощью консоли диспетчера шлюза появляется возможность настраивать политики авторизации для тех или иных условий, которые должны быть выполнены при подключении к сетевым ресурсам удаленными пользователями. В качестве примера, можно указать конкретных пользователей, которые могут подключаться к внутренним сетевым ресурсам, а также должен ли клиентский компьютер при этом быть членом группы безопасности AD, допустимо ли перенаправление устройства и диска;
• Консоль диспетчера шлюза содержит инструменты, предназначенные для отслеживания состояния шлюза. Используя их, вы можете назначить отслеживаемые события для аудита, например, неудачные попытки подключения к серверу шлюза служб терминалов.

Важно! Шлюз служб терминалов должен входить в домен Active Directory. Настройка шлюза выполняется только от имени администратора домена, на любом сервере в домене.

Установим роль.

Настройка политики авторизации подключения и ресурсов.



Установим SSL-сертификат.

В том же окне “Диспетчер шлюза удаленных рабочих столов”, в левой окна кликаем по значку сервера, в основной части окна — “Просмотр и изменение свойств сертификата”.

В открывшемся окне “Свойства <имя_сервера>” переходим на вкладку “Сертификат SSL”. Устанавливаем переключатель “Создать самозаверяющий сертификат” и кликаем по кнопке “Создать и импортировать сертификат…”.

Хотя возможны еще 2 варианта:

• импорт ранее загруженного сертификата (самоподписанного ранее или стороннего);
• загрузка стороннего сертификата (например, Comodo) и его импорт;

В окне “Создание самозаверяющего сертификата” проверяем параметры и нажимаем кнопку “OK”.

Система уведомит, что сертификат был создан успешно. также присутствует информация, где можно найти сам файл сертификата. Нажимаем кнопку “OK”.

В окне свойств сервера, нажимаем кнопку “Применить”.

Самозаверенный сертификат установлен на TCP-порт 443 (SSL-порт по умолчанию).

Мы рекомендуем, в целях безопасности, изменить порт SSL, используемый по-умолчанию. Для этого, в основном меню окна, выбираем “Действия” → “Свойства”.

Переходим на вкладку “Параметры транспорта” и устанавливаем желаемое значение поля “HTTPS-порт”. Сохраняем параметры нажимая кнопку “Применить”.

Система запросит подтверждение — отвечаем ”Да”.

Выполним подключение через шлюз.

Открываем RDP-клиент, переходим на вкладку “Дополнительно” и нажимаем кнопку “Параметры”.

В открывшемся окне выбираем “Использовать следующие параметры сервера шлюза удаленных рабочих столов”. Указываем доменное имя сервера и через двоеточие (:) указываем SSL-порт. Метод входа — “Запрашивать пароль”. Нажимаем “OK”

Переходим на вкладку “Общие”. Указываем адрес компьютера и пользователя под которым будет выполняться подключение. Нажимаем кнопку “Подключить”

Программа запросит пароль от учетной записи.

Результаты работы шлюза можно проверить трассировкой — команда tracert.

220140
Минск
ул. Домбровская, д. 9

+375 (173) 88-72-49

ООО «ИТГЛОБАЛКОМ БЕЛ»

220140
Минск
ул. Домбровская, д. 9

+375 (173) 88-72-49

ООО «ИТГЛОБАЛКОМ БЕЛ»

Хочу поделиться несколькими советами по настройке удаленного подключения к рабочим местам по RDP. Расскажу как проапгрейдить древний RPC-HTTP до UDP, похвалю и поругаю Windows 10 и AVC, разберу решение нескольких типичных проблем.

Считаем, что для подключения используется Remote Desktop Gateway (RDGW), а в качестве серверов выступают рабочие станции. Использовать RDGW очень удобно, потому что шлюз становится общей точкой входа для всех клиентов. Это дает возможность лучше контролировать доступ, вести учет подключений и их продолжительность. Даже если VPN позволяет подключиться к рабочим машинам напрямую — это не лучший вариант.

RDGW настраивается быстро, просто, а Let’s Encrypt и win-acme легко решают проблему с доверенным сертификатом.

Есть три транспортных протокола по которым клиент может подключиться с серверу:

RPC-HTTP (

плохо)
HTTP (лучше)
HTTP+UDP (отлично)

Под сервером будем понимать рабочую машину, под клиентом — домашнюю.
Первое, с чего стоит начать, это «плохо» превратить в «отлично».

Апгрейд RPC-HTTP до HTTP

Подключение в сессию с использованием RPC-HTTP легко определить по внешнему виду полоски подключения.

Здесь нет значка качества подключения (о нем ниже), а значит мы используем старый RPC, обернутый в TLS — это очень медленно. Дело, конечно, не только в обертке — сам протокол меняется с каждым релизом ОС, меняются кодеки, алгоритмы упаковки изображения. Чем свежее протокол, тем лучше.

Что делать?

Windows XP или Vista

В XP можно поднять протокол с 5.1 до 7. Хотфикс windowsxp-kb969084-x86.exe

В Vista — c 6 до 7. Хотфикс имеет тот же номер, файлы windows6.0-kb969084-x64.msu или Windows6.0-KB969084-x86.msu

Но RDP 7 не работает по HTTP и UDP. Поможет только апгрейд клиента и сервера до Windows 7 и новее.

Windows 7

Сначала надо обновить протокол до RDP 8.1, а затем включить его. Поддержка добавляется обновлениями, которые сгруппированы в один загрузочный пакет:

www.microsoft.com/en-US/download/details.aspx?id=40986
Windows6.1-KB2574819-v2-x64.msu
windows6.1-kb2592687-x64.msu
Windows6.1-KB2830477-x64.msu
Windows6.1-KB2857650-x64.msu

Windows6.1-KB2913751-x64.msu

(заменен kb2923545)

windows6.1-kb2923545-x64.msu

Так вы получите и свежий клиент mstsc.exe, и поддержку RDP 8.1 серверной части ОС.
Было:

Стало:

После этого протокол надо включить ключом реестра (для этого можно использовать adm шаблон в комплекте с Windows 7).

[HKEY_LOCAL_MACHINESOFTWAREPoliciesMicrosoftWindows NTTerminal Services]
"fServerEnableRDP8"=dword:00000001
 
[HKEY_LOCAL_MACHINESOFTWAREWow6432NodePoliciesMicrosoftWindows NTTerminal Services]
"fServerEnableRDP8"=dword:00000001

Включите поддержку транспорта UDP в групповой политике.

Перезагружаем сервер с Windows 7. Тот самый случай, когда может потребоваться перезагрузиться дважды — значение в реестре должно быть установлено до того, как включился RDP, а групповая политика применяется позже.

Если все получилось, то при подключении к серверу в полоске сессии появится иконка качества подключения (как в телефоне для мобильной сети):

Windows 8 и новее

Протокол работает «из коробки».

Апгрейд HTTP до HTTP+UDP

Если ваша сеть не склонна к потере пакетов, UDP существенно (для CAD — радикально) повышает отзывчивость сервера за счет использования FEC для сокращения ретрансмиссии, а также перехода подтверждения доставки пакетов с уровня системного стека TCP/IP на уровень протокола RDP-UDP.

От каждого клиента подключается одна основная управляющая сессия по HTTP (в этом канале также передается клавиатура/мышь), плюс одна или несколько сессий UDP для передачи картинки или других виртуальных каналов.

Мы коснемся только верхушки айсберга. Есть 3 различных версии протокола RDP-UDP. Кроме того, сам UDP может работать в двух режимах UDP-R (reliable) и UDP-L (lossy). С Microsoft ничего просто не бывает. Но поскольку от нас здесь ничего не зависит, просто имейте в виду — чем новее операционная система, теме более современный протокол используется.

Снаружи RDP-UDP оборачивается в Datagram Transport Layer Security (DTLS) RFC4347, в чем вы можете убедиться открыв Wireshark.

Подробнее в документах:
[MS-RDPEMT]: Remote Desktop Protocol: Multitransport Extension
[MS-RDPEUDP]: Remote Desktop Protocol: UDP Transport Extension
[MS-RDPEUDP2]: Remote Desktop Protocol: UDP Transport Extension Version 2
Где не прав — поправьте, пожалуйста.

Что же нужно для включения UDP?

RDP-UDP поддерживается начиная с RDP 8.

На клиенте должен быть открыт порт udp/3389. Если вы его закрыли локальным firewall, ACL на свитче или внешнем файрволле — порт надо открыть.

Для сервера Remote Desktop Gateway к порту tcp/443 надо открыть udp/3391.

Порт можно поменять, вот как он настраивается:

Для Windows 7 обязательно должен быть включен NLA (Network Level Authentication).

Можно включить в групповой политике

или через реестр

[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlTerminal ServerWinStationsRDP-Tcp]
"SecurityLayer"=dword:00000001

В чем связь непонятно. Но без NLA на 7-ке не работает, на более свежих релизах NLA для работы UDP не обязателен.

После установления сессии по HTTP, клиент и сервер пробуют согласовать подключение по UDP. Если есть выпадение пакетов или задержки, то сессия UDP не запустится. Точный алгоритм отказа согласования UDP до конца не понятен.

Если все настроено, то после подключения нажмите на кнопку качества связи. В окошке будет указано, что согласован UDP.

На шлюзе это выглядит так:

Windows 10

Если у вас Windows 10 и на сервере, и на клиенте, то это самый быстрый и беспроблемный вариант. В Microsoft активно дорабатывают RDP, и в свежих релизах 10 вы можете рассчитывать на неплохую скорость работы. Коллеги не смогли обнаружить разницу между Citrix и Windows 10 RDP по скорости работы в AutoCAD.

Про эволюцию кодеков RDP на базе AVC в Windows 10 есть хорошая статья
Remote Desktop Protocol (RDP) 10 AVC/H.264 improvements in Windows 10 and Windows Server 2016 Technical Preview

Согласование AVC с аппаратным кодированием можно увидеть в журнале событий (подробнее в статье выше):

Замечу только, что проблема искажений все же есть даже с h.264 4:4:4. Она сразу бросается в глаза если работать в PowerShell ISE — текст ошибок выводится с неприятным искажением. Причем на скриншоте и на фотографии все отлично. Волшебство.

Также косвенным признаком работы AVC являются время от времени появляющиеся зеленые квадраты по углам.

AVC и аппаратное кодирование в свежих билдах должно работать из коробки, но групповая политика никогда не бывает лишней:

С учетом того, что AVC кодируется аппаратно видеокартой, то обновить драйверы видео — хорошая идея.

О проблемах

XP и Vista

Если проблема возникает на Windows XP или Vista, попробуйте сначала обновить протокол до 7 версии (писал в начале статьи). Обязательно включите поддержку CredSSP. На сайте Microsoft статьи уже удалены, но Интернет помнит.

Если не помогло — «доктор говорит в морг, значит в морг». Что испытала на себе операционная система за последние 15 лет — лучше об этом даже и не думать.

NLA

Иногда помогает отключение NLA на сервере. Выяснить причину не получилось, домашние машины все разные.

NTLM

Некоторые клиенты пытаются авторизоваться с использованием NTLMv1. Причины разные, но исправить на клиенте можно так:

[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlLsa]
"LmCompatibilityLevel"=dword:00000003

Перезагрузка обязательна.

Если вы

молоды и дерзки

ничего не боитесь, то есть более радикальное решение — отключение Channel Binding на Remote Desktop Gateway

HKLMSoftwareMicrosoftWindows NTCurrentVersionTerminalServerGatewayConfigCore
Type: REG_DWORD
Name: EnforceChannelBinding
Value: 0 (Decimal)

Делать так не надо. Но мы делали. Для клиента, который настаивал (нет не так, НАСТАИВАЛ) что NTLMv1 на рабочих станциях ему необходим. Не знаю, может там серверы на NT4 без SP еще в работе.

Отключение RDP 8+ в Windows 10

Если ничего не помогает, а идеи кончились, можно воспользоваться недокументированным ключом для даунгрейда протокола RDP до 7 версии.

[HKEY_CURRENT_USERSoftwareMicrosoftTerminal Server Client]
"RDGClientTransport"=dword:00000001

Сам не делал, и вам не советую. Но кому-то, пишут, что помогает.

DrWeb

Компонент Dr.Web SpIDerGate может запретить подключение. В этом случае возвращается ошибка:

В статистике Dr.Web будет запись:

В комментариях к этой статье со мной связался сотрудник Dr.Web и наша проблема решилась в ближайшем обновлении антивирусных баз.
Если у вас такая же ошибка, лучше обратиться в поддержку.
Как временное решение, можно внести URL вашего RDGW в исключения:

И только если не помогло отключить компонент SpIDer Gate полностью.

Системный прокси

Встретился списанный компьютер из какой-то компании, где в качестве системного прокси был прописан местный TMG, и подключение к RDGW не работало. Это можно исправить так:

netsh winhttp show proxy && netsh winhttp reset proxy

Переключение раскладок клавиатуры

Иногда приезжают лишние раскладки. Можно отключить проброс раскладки с клиента

[HKLMSystemCurrentControlSetControlKeyboard Layout]
"IgnoreRemoteKeyboardLayout"=dword:00000001

Проблемы с DPI

Масштабирование приходит с клиентской машины, и если на домашнем ноутбуке стоит 125%, то и на рабочей машине будет так же. На серверах это можно отключить, а на рабочих станциях не нашел как. Но в магазине приложений Windows 10 есть «современный» клиент.

В нем можно настроить DPI:

Как мониторить шлюз с RDGW

Есть счетчик производительности «Шлюз служб терминаловТекущие подключения», который немного глючит, если нет подключений или сервер долго не перезагружался. Он показывает именно число подключений, но как мы помним, для HTTP+UDP их как минимум два, а может быть и больше. Поэтому это не совсем объективный показатель числа подключений сотрудников.

Есть класс WMI Win32_TSGatewayConnection. Его содержимое соответствует тому, что вы видите в разделе «Наблюдение» шлюза удаленных рабочих столов.

С ним число подключений можно посчитать поточнее:

Get-WmiObject -class "Win32_TSGatewayConnection" -namespace "rootcimv2TerminalServices" 
|?{$_.transportprotocol -ne 2}|select username,connectedresource|sort username|Get-Unique -AsString| measure|select -ExpandProperty count

Just for fun есть утилита Remote Display Analyzer. Бесплатная версия мне ничего полезного не показала, но вдруг кому-то пригодится.

А как же тонкий тюнинг, настройка нескольких десятков параметров сессии?

Здесь уместен принцип Парето: 20% усилий дают 80% результата. Если вы готовы инвестировать ваше время в оставшиеся 20% результата — отлично. Только имейте в виду, что когда вы читаете статью о настройке протокола в Windows 7, то не знаете про какой протокол писал автор — 7, 8 или 8.1. Когда читаете про Windows 10 без указания релиза — проблемы те же. Например, пишут что в свежих билдах Windows 10 кодек AVC/h.264 изменился на RDPGFX_CODECID_AVC444V2, а в Windows Server 2016 остался RDPGFX_CODECID_AVC444.

Из всех таких советов мы используем только две настройки:

1. 16 bit цвет, об этом можно почитать в статье MS RDP Performance / Bandwidth Usage
2. Отключение сглаживания шрифтов font smoothing:i:0 по статье выше или Performance Tuning Remote Desktop Session Hosts

Сомневаюсь, что они дают какой-то ощутимый результат.

Вот мы и подошли к концу статьи. Хотел покороче, а получилось как всегда. Рад, если кому-то эти советы помогут сэкономить время или улучшить настройку своей инфраструктуры.