Сервер шлюза удаленных рабочих столов: Инструкция по настройке шлюза удаленных рабочих столов

Содержание

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

Расскажем подробно, как настроить сервис Remote Desktop Gateway (RDG) на домене на платформах под управлением Windows Server.

Что такое RDG

Компания Microsoft предлагает использовать удаленный доступ к рабочим столам по протоколу RDP (Remote Desktop Protocol). Для создания защищенного соединения используется сервис RDG (Remote Desktop Gateway). Его особенность в том, что он использует подключение по протоколу HTTPS. При этом создается надежный канал связи, который гарантирует пользователю должный уровень защиты. Соответственно, нет нужды использовать сторонние сервисы по созданию VPN-туннеля.

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

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

Запускаем «Диспетчер серверов», переходим на правой стороне во вкладку «Добавить роль»:

Скриншот №1. Выбор опции

Для примера используем первый пункт:

Скриншот №2. Выбор инсталляции

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

Скриншот №3. Активируем роль

После нажатия кнопки «Next» на экране отобразится информация о выбранной роли. Соглашаемся и переходим к следующему шагу. Теперь в разделе Role Server появилась добавленная функция. Заходим в нее и отмечаем опции, которые необходимы администратору. Для примера, активируем RDG:

Скриншот №4. Выбор дополнительных функций

Мастер настройки проверяет выбранную роль и совместимость с серверной ОС. Если необходима установка дополнительных компонентов, то автоматически откроется рабочая область с отмеченными компонентами. Чтобы RDG работал, в операционной системы должны быть установлены сервисы web-администрирования с полным набором программных инструментов:

Скриншот №5. Выбор дополнительных компонентов

Рекомендуется оставить по умолчанию выбранные сервисы. Нажимаем «Next», подтверждаем установку.

Доступ к ресурсам

После установки выбранной роли переходим в главное окно «Диспетчера серверов». Выбираем раздел «Инструменты» и переходим к настройке RDG. Откроется новое рабочее окно (RD Gateway Manager). В нем переходим во вкладку с именем сервера, далее выбираем «Политики» и сконфигурируем авторизированные подключения. Нажимаем кнопку «Wizard», чтобы открыть мастер настройки:

Скриншот №6. Создание политики

Установщик предложит на выбор 3 пункта. Оставляем активным первую опцию:

Скриншот №7. Выбор конфигурации

Задаем имя новому шаблону, нажимаем «Next». Следующий этап — выбор метода аутентификации и списка пользователей, которые получат доступ к политике. Авторизация разрешена при помощи пароля либо смарт-карты, либо оба варианта. Оставляем только по паролю. Далее нажимаем кнопку «Добавить группу» и добавляем данные в поле:

Скриншот №8. Выбор авторизации и пользователей

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

Скриншот №9. Выбор ресурсов

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

Мастер настройки попросит указать политику авторизации для сетевых ресурсов. Для начала придумываем имя конфигурации. Потом добавляем группы пользователей, которые будут подключаться:

Скриншот №10. Выбор группы

Теперь выбираем группу ресурсов:

Скриншот №11. Выбор группы ресурсов

Мастер настройки попросит указать номер порта для подключения. Если специальных требований нет, оставляем по умолчанию — 3389. После нажатия «Next» на экране появится информация о созданной политики авторизации. Если все верно, завершаем конфигурирование.

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

Чтобы доступ через RDG был активен, также необходимо создать сертификат. В рабочем окне RDG Manager переходим к разделу «Имя сервера». Через контекстное меню открываем пункт «Просмотреть или изменить свойства сертификата». В открывшемся окне переключаемся на вкладку SSL. Доступно 3 варианта создания. Выбираем пункт, отмеченный красным на скриншоте:

Скриншот №12. Выбор метода

Теперь прописываем имя сертификата и путь, по которому он будет храниться:

Скриншот №13. Импорт

Нажимаем «ОК» для генерации. В итоге рабочая область менеджера выглядит следующим образом:

Скриншот №14. Общая информация

Для повышения уровня безопасности рекомендуется сменить порт по умолчанию для подключения через Remote Desktop Protocol. Открываем в RDG Manager раздел «Действия», пункт «Свойства». Переходим во вкладку «Свойства транспортировки». В поле, отмеченным красным, меняем значение:

Скриншот №15. Смена порта

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

Как подключиться

Теперь необходимо настроить подключение через RDP. Нажимаем сочетание клавиш Win+R, вводим команду mstsc.exe. В открывшемся окне нажимаем «Параметры»:

Скриншот №16. Настройка RDP

В поле, отмеченном красным, прописываем адрес сервера, а через двоеточие в конце отмечаем номер порта. Нажимаем «ОК».

Теперь переходим во вкладку «Общие». Прописываем имя домена и пользователя:

Скриншот №17. Домен и пользователь

Мастер настройки попросит указать пароль для учетного имени. Вводим его. Конфигурирование завершено.

Средняя оценка: 5.0
Оценили: 2

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

+375 (173) 88-72-49

700
300

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

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

+375 (173) 88-72-49

700
300

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

700
300

RDS на основе сеансов в Windows Server 2012 R2. Часть 5 — Использование роли шлюза подключений (RD Gateway) — bearded sysadmin

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

Шлюз удалённых рабочих столов представляет собой сервис посредника между клиентами из внешней сети и коллекцией сеансов, которая расположена во внутренней сети предприятия, и обеспечивающий безопасный обмен данными между ними.

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

Как работает шлюз удалённых рабочих столов?
Нововведения в службе RD Gateway в Windows Server 2012
Установка службы RD Gateway
Подключение к коллекции сеансов посредством сервера шлюза

Как работает шлюз удалённых рабочих столов?

Если описывать вкратце, то в случае, когда клиент инициирует подключение к шлюзу удалённых рабочих столов, шлюз первым делом устанавливает защищенное соединение между собой и клиентом. Затем, сервер шлюза проверяет учётную запись пользователя или компьютера на право доступа к службе шлюза и, в случае успеха, проводит авторизацию клиента. После того, как клиент авторизирован шлюз проверяет имеет ли клиент право на доступ к запрашиваемому ресурсу. И в том случае, если клиент имеет право на подключение, то шлюз устанавливает соединение между собой и внутренним ресурсом. Вся дальнейшая передача каких-либо данных между внешним клиентом и внутренним ресурсом осуществляется строго через шлюз.

Рис.1 — Работа шлюза удалённых рабочих столов

Нововведения в службе шлюза удалённых рабочих столов

Нововведений в службе RD Gateway по сравнению с предыдущей версией действительно много и вот самые значительные из них:

Добавлена поддержка транспортного протокола UDP
Введена возможность изменения стандартных номеров портов для протоколов HTTPS и UDP
Добавлена функция использования транспорта HTTP вместо RPC over HTTP

Что же нового приносят эти функции? Давайте разбираться.

Поддержка транспортного протокола UDP

Как известно, для оптимизации передачи трафика по протоколу RemoteFX используется транспортный протокол UDP. Поэтому его поддержка со стороны шлюза значительно улучшает работу с клиентами, использующими для работы именно протокол RemoteFX. В этом случае, кроме стандартных HTTPS создается дополнительный двусторонний UDP-туннель, защищенный протоколом DTLS (детальнее о нём можно почитать тут). Следует заметить, что созданный туннель обеспечивает не только максимальную производительность, но и определённую степень надёжности, что позволяет получать защищенное соединение с довольно приемлемым качеством отображения.

Поддержка изменения стандартных номеров портов для протоколов HTTPS и UDP

По умолчанию для соединения с сервером шлюза удалённых рабочих столов извне используется порт 443, а для связи с внутренними серверами фермы RDS порт 3389. В Windows Server 2012 появилась возможность изменить номера этих портов на нестандартные. Это бывает необходимо в целом ряде сценариев развёртывания.

Поддержка использования транспорта HTTP вместо RPC over HTTP

Для клиентов, которые используют для связи протокол RDP 8.0 предусмотрена возможность использовать транспорт HTTP вместо RPC over HTTP. Недостаток последнего метода транспортировки заключается в том, что процедуры RPC вызываются и при передаче данных от клиента и к нему, что приводит к увеличению излишней нагрузки на ЦП сервера. И как следствие, использование транспорта HTTP позволяет увеличить число одновременных подключений к шлюзу.

Больше об новшествах в службе RD Gateway можно узнать из официального блога разработчиков RDS.

Установка службы RD Gateway

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

Рис.2 — Добавление нового сервера в Диспетчер серверов

Запустить установку роли RD Gateway можно зайдя в Службы удалённых рабочих столов и там либо нажать на ссылку Шлюз удалённых рабочих столов в панели Обзор развёртывания либо в выпадающем меню Задачи на панели Серверы развёртывания выбрать пункт Добавить серверы шлюзов удалённых рабочих столов.

Рис.3 — Добавление шлюза удалённых рабочих столов к развёртыванию

Любое из описанных выше действий приведёт к вызову мастера установки роли шлюза удалённых рабочих столов. В первом окне выбираем сервер или несколько серверов на которые будет установлена роль RD Gateway.

Рис.4 — Выбор сервера для установки роли шлюза

После выбора серверов, роли шлюза необходимо присвоить самозаверяющий SSL-сертификат. В поле для ввода указываем полное внешнее имя к которому будут подключаться клиенты. В данном случае рассмотрен наипростейший вариант, в котором организация имеет зарегистрированное доменное имя domain.ext и к серверу шлюза можно обратиться по имени rdgw.domain.ext.

Рис.5 — Создание SSL-сертификата для роли шлюза

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

Рис.6 — Окно подтверждения выбора

После того, как сервер добавлен в развёртывание и на него установлены все необходимые службы, потребуется настроить сертификат подлинности. Сделать это можно прямо из окна развёртывания нажав на ссылку Настроить сертификат в уведомлении или позже зайдя в Свойства развёртывания (Диспетчер серверов > Службы удалённых рабочих столов > Общие сведения > Обзор развёртывания > Задачи).

Рис. 7 — Выполнение установки роли службы шлюза

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

Рис.8 — Окно управления сертификатами служб RDS

При создании нового сертификата указываем внешнее доменное имя, по которому будут подключаться пользователи, пароль и место хранения сертификата. Кроме всего этого, необходимо установить галочку Разрешить добавление сертификата в хранилище «Доверенные корневые центры сертификации» на конечных компьютерах. Это необходимо для того, чтобы на клиентских компьютерах сертификат можно было установить вручную.

Рис.9 — Создание нового сертификата

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

Рис.10 — Успешная установка сертификата для шлюза удалённых рабочих столов

Когда сертификат успешно создан и применен, из окна Ход выполнения (рис.7) можно перейти к свойствам шлюза удалённых рабочих столов. К этим же свойствам можно получить доступ и через Свойства развёртывания.

Окно свойств шлюза RDS позволяет настроить самые основные параметры, а именно: выполнить ли конфигурацию RD Gateway в автоматическом режиме, задать настройки вручную либо вовсе не использовать службу шлюза удалённых рабочих столов. Если выбрана опция Использовать следующие параметры сервера шлюза удалённых рабочих столов, то нижеследующие параметры потребуется указать вручную:

Имя сервера. Внешнее имя шлюза к которому обращаются пользователи.
Метод входа. Доступны варианты для настройки проверки подлинности пользователя используя пароль или используя смарт-карту.
Использовать ли учётные данные шлюза удалённых рабочих столов для удалённых компьютеров.
Не использовать сервер шлюза удалённых рабочих столов для локальных подключений. Этот параметр позволяет снизить нагрузку на RD Gateway, т.к. для локальных клиентов соединение с фермой RDS устанавливается минуя шлюз.

Рис.11 — Базовые параметры шлюза удалённых рабочих столов

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

Рис.12 — Службы удалённых рабочих столов после добавления сервера шлюза

Подключение пользователей к ресурсам фермы RDS с помощью шлюза

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

Рис.13 — Настройки Подключения к удалённому рабочему столу

Окно параметров содержит в себе ровно те же настройки, что и окно свойств шлюза в настройках развёртывания RDS (рис.11). Здесь указываем полное доменное имя сервера шлюза, метод проверки подлинности, необходимость использования шлюза при подключении в локальной сети и необходимость использования учётных данных шлюза для удалённого компьютера. После нажатия на кнопку Подключить будет выполнено подключение к ферме RDS с помощью шлюза удалённых рабочих столов.

Рис.14 — Параметры подключения к шлюзу удалённых рабочих столов

На Windows RT и Windows 8/8.1 можно осуществлять подключение с помощью приложения Удалённый рабочий стол. Для того, чтобы указать сервер шлюза, через который будет установлено подключение, необходимо зайти в настройки приложения. Сделать это можно в окне приложения, нажав комбинацию клавиш Win+I, или зайдя в пункт Параметры панели Charms. Из панели параметров необходимо перейти в Параметры соединения, где, среди прочих настроек, можно указать параметры шлюза удалённых рабочих столов.

Рис.15 — Параметры шлюза удалённых рабочих столов в приложении Удалённый рабочий стол

В случае когда развернуты приложения RemoteApp и они подключены средствами Панели управления, приложений Удалённый рабочий стол или GPO, достаточно сперва выполнить обновление приложений (как описано в статье RDS на основе сеансов в Windows Server 2012 R2. Часть 4 — Распространение приложений RemoteApp и удалённых рабочих столов) и затем можно подключаться из внешней сети. Настройки шлюза при этом будут подхватываться в автоматическом режиме.

Для того, чтобы убедиться, что защищенное соединение действительно работает, воспользуемся средствами утилиты netstat. Для этого в командной строке введем netstat -a. Как видим, среди прочих, присутствуют 2 установленных защищенных протоколом HTTPS соединения с узлом rdgw. Вот это и есть подключение к шлюзу удалённых рабочих столов.

Рис.16 — Соединения с шлюзом удалённых рабочих столов

Если пользователь получает доступ к полному удалённому рабочему столу, то в свойствах подключения можно посмотреть информацию касательно шлюза. Сделать это можно с помощью пункта Сведения о шлюзе контекстного меню окна соединения.

Рис.17 — Сведения о шлюзе

***

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

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

MS Remote Desktop Gateway, HAProxy и перебор пароля / Хабр

Друзья, привет!

Существует множество способов подключения из дома к рабочему месту в офисе. Один из них — это использовать Microsoft Remote Desktop Gateway. Это RDP поверх HTTP. Я не хочу здесь затрагивать настройку самого RDGW, не хочу рассуждать, почему он хорош или плох, давайте отнесёмся к нему, как к одному из инструментов удалённого доступа. Я хочу поговорить о защите вашего RDGW сервера от злого интернета. Когда я настроил RDGW сервера, я тут же озаботился защитой, особенно защитой от перебора пароля. Меня удивило, что я не нашёл в интернетах статей о том, как можно это сделать. Ну что ж, придётся делать самостоятельно.

Сам по себе RDGW не имеет никаких защит. Да, его можно выставить голой ж интерфейсом в белую сеть и будет прекрасно работать. Но правильному администратору или ИБ’шнику будет от этого неспокойно. К тому же позволит избежать ситуации блокирования учётной записи, когда нерадивый сотрудник запомнил пароль корпоративного аккаунта на домашнем компьютере, а затем сменил свой пароль.

Хороший способ защиты внутренних ресурсов от внешней среды — это различные прокси, системы публикации и прочие WAF. Вспомним, что RDGW это всё таки http, тогда прям напрашивается воткнуть специализированное решение между внутренними серверами и интернетом.

Я знаю, что есть крутые F5, A10, Netscaler(ADC). Как администратор одной из этих систем, скажу, что настроить защиту от перебора на этих системах тоже возможно. И да, эти системы попутно защитят вас от всякого syn флуда.

Но далеко не каждая компания может позволить себе приобрести подобное решение (и найти администратора такой системы :), а о безопасности, при этом, позаботиться может!

Вполне возможно установить бесплатную версию HAProxy на бесплатной операционной системе. Я тестировал на Debian 10, в стабильным репозитарии версия haproxy 1.8.19. Так же проверял на версии 2.0.хх из testing репозитария.

Настройку самого debian оставим за пределом статьи. Кратко: на белом интерфейсе закрыть всё, кроме 443 порта, на сером интерфейсе — согласно вашей политике, например тоже закрыть всё, кроме 22 порта. Открыть только то, что необходимо для работы (VRRP например, для плавающего ip).

Перво-наперво настроил haproxy на SSL bridging mode (он же mode http) и включил логирование, чтобы посмотреть, что же там внутри RDP ходит. Так сказать, влез посередине. Так вот, указанный во «всех» статьях по настройке RDGateway путь /RDWeb отсутствует. Всё, что там есть, это /rpc/rpcproxy.dll и /remoteDesktopGateway/. При этом не используются стандартные GET/POST запросы, используется свой тип запроса RDG_IN_DATA, RDG_OUT_DATA.

Не много, но хоть что-то.

Давайте тестировать.

Запускаю mstsc, иду на сервер, в логах вижу четыре ошибки 401 (unauthorized), затем ввожу логин/пароль и вижу ответ 200.

Отключаю, запускаю заново, в логах вижу те же четыре ошибки 401. Ввожу ошибочные логин/пароль и вижу снова четыре ошибки 401. То, что надо. Это и будем отлавливать.

Поскольку определить login url так и не удалось, и к тому же я не знаю, как в haproxy отлавливать именно ошибку 401, то буду отлавливать (на самом деле не отлавливать, а считать) все ошибки 4xx. Тоже устроит для решения задачи.

Суть защиты будет состоять в том, что мы будем считать кол-во ошибок 4xx (на backend) в единицу времени и если оно превысит указанный предел, то отклонять (на frontend) все дальнейшие соединения с этого ip в течении указанного времени.

Технически, это не будет защитой от перебора пароля, это будет защитой от ошибок 4xx. Например, если часто запрашивать несуществующий url (404), то защита так же сработает.

Самый простой и работающий способ — это на backend посчитать и отбить, если чего лишнего появилось:

frontend fe_rdp_tsc
    bind *:443 ssl crt /etc/haproxy/cert/desktop.example.com.pem
    mode http
    ...
    default_backend be_rdp_tsc


backend be_rdp_tsc
    ...
    mode http
    ...

    #создать таблицу, строковую, 1000 элементов, протухает через 15 сек, записать кол-во ошибок за последние 10 сек
    stick-table type string len 128 size 1k expire 15s store http_err_rate(10s)
    #запомнить ip
    http-request track-sc0 src
    #запретить с http ошибкой 429, если за последние 10 сек больше 4 ошибок
    http-request deny deny_status 429 if { sc_http_err_rate(0) gt 4 }
	
	...
    server rdgw01 192.168.1.33:443 maxconn 1000 weight 10 ssl check cookie rdgw01
    server rdgw02 192.168.2.33:443 maxconn 1000 weight 10 ssl check cookie rdgw02

Не самый хороший вариант, усложним. Считать будем на backend, а блокировать на frontend.

С атакующим поступим грубо, будем скидывать ему tcp соединение.

frontend fe_rdp_tsc
    bind *:443 ssl crt /etc/haproxy/cert/ertelecom_ru_2020_06_11.pem
    mode http
    ...
    #создать таблицу ip адресов, 1000 элементов, протухнет через 15 сек, сохрянять из глобального счётчика
    stick-table type ip size 1k expire 15s store gpc0
    #взять источник
    tcp-request connection track-sc0 src
    #отклонить tcp соединение, если глобальный счётчик >0
    tcp-request connection reject if { sc0_get_gpc0 gt 0 }
	
    ...
    default_backend be_rdp_tsc


backend be_rdp_tsc
    ...
    mode http
    ...
	
    #создать таблицу ip адресов, 1000 элементов, протухнет через 15 сек, сохранять кол-во ошибок за 10 сек
    stick-table type ip size 1k expire 15s store http_err_rate(10s)
    #много ошибок, если кол-во ошибок за 10 сек превысило 8
    acl errors_too_fast sc1_http_err_rate gt 8
    #пометить атаку в глобальном счётчике (увеличить счётчик)
    acl mark_as_abuser sc0_inc_gpc0(fe_rdp_tsc) gt 0
    #обнулить глобальный счётчик
    acl clear_as_abuser sc0_clr_gpc0(fe_rdp_tsc) ge 0
    #взять источник
    tcp-request content track-sc1 src
    #отклонить, пометить, что атака
    tcp-request content reject if errors_too_fast mark_as_abuser
    #разрешить, сбросить флажок атаки
    tcp-request content accept if !errors_too_fast clear_as_abuser
	
    ...
    server rdgw01 192.168.1.33:443 maxconn 1000 weight 10 ssl check cookie rdgw01
    server rdgw02 192.168.2.33:443 maxconn 1000 weight 10 ssl check cookie rdgw02

тоже же самое, но вежливо, будем возвращать ошибку http 429 (Too Many Requests)

frontend fe_rdp_tsc
    ...
    stick-table type ip size 1k expire 15s store gpc0
    http-request track-sc0 src
    http-request deny deny_status 429 if { sc0_get_gpc0 gt 0 }
    ...
    default_backend be_rdp_tsc

backend be_rdp_tsc
    ...
    stick-table type ip size 1k expire 15s store http_err_rate(10s)
    acl errors_too_fast sc1_http_err_rate gt 8
    acl mark_as_abuser sc0_inc_gpc0(fe_rdp_tsc) gt 0
    acl clear_as_abuser sc0_clr_gpc0(fe_rdp_tsc) ge 0
    http-request track-sc1 src
    http-request allow if !errors_too_fast clear_as_abuser
    http-request deny deny_status 429 if errors_too_fast mark_as_abuser
    ...

Проверяю: запускаю mstsc и начинаю беспорядочно вводить пароли. После третьей попытки за 10 сек меня отпинывает, а mstsc выдаёт ошибку. Что и видно в логах.

Пояснения. Я далеко не мастер haproxy. Я не понимаю, почему, например

http-request deny deny_status 429 if { sc_http_err_rate(0) gt 4 }

позволяет сделать около 10 ошибок, прежде чем сработает.

Я путаюсь в нумерации счётчиков. Мастера haproxy, буду рад, если дополните меня, поправите, сделаете лучше.

В комментариях можете накидать других способов защиты RD Gateway, будет интересно изучить.

Касательно клиент удалённого рабочего стола Windows (mstsc), стоит отметить, что он не поддерживает TLS1.2 (во всяком случае в Windows 7), поэтому пришлось оставить TLS1; не поддерживает актуальные cipher, поэтому так же пришлось оставить старые.

Для тех, кто ~~ничего не понял~~ только учится, и уже хочет сделать хорошо, приведу весь конфиг.

haproxy.conf

global
        log /dev/log    local0
        log /dev/log    local1 notice
        chroot /var/lib/haproxy
        stats socket /run/haproxy/admin.sock mode 660 level admin expose-fd listeners
        stats timeout 30s
        user haproxy
        group haproxy
        daemon

        # Default SSL material locations
        ca-base /etc/ssl/certs
        crt-base /etc/ssl/private

        # See: https://ssl-config.mozilla.org/#server=haproxy&server-version=2.0.3&config=intermediate
        #ssl-default-bind-ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE
-RSA-AES256-GCM-SHA384
        ssl-default-bind-ciphers ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:RSA+AESGCM:RSA+AES:!aNULL:!MD5:!DSS
        ssl-default-bind-ciphersuites TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256
        #ssl-default-bind-options ssl-min-ver TLSv1.2 no-tls-tickets
        ssl-default-bind-options no-sslv3
        ssl-server-verify none


defaults
        log     global
        mode    http
        option  httplog
        option  dontlognull
        timeout connect 5000
        timeout client  15m
        timeout server  15m
        errorfile 400 /etc/haproxy/errors/400.http
        errorfile 403 /etc/haproxy/errors/403.http
        errorfile 408 /etc/haproxy/errors/408.http
        errorfile 500 /etc/haproxy/errors/500.http
        errorfile 502 /etc/haproxy/errors/502.http
        errorfile 503 /etc/haproxy/errors/503.http
        errorfile 504 /etc/haproxy/errors/504.http


frontend fe_rdp_tsc
    bind *:443 ssl crt /etc/haproxy/cert/dektop.example.com.pem
    mode http
    capture request header Host len 32
    log global
    option httplog
    timeout client 300s
    maxconn 1000

    stick-table type ip size 1k expire 15s store gpc0
    tcp-request connection track-sc0 src
    tcp-request connection reject if { sc0_get_gpc0 gt 0 }

    acl rdweb_domain hdr(host) -i beg dektop.example.com
    http-request deny deny_status 400 if !rdweb_domain
    default_backend be_rdp_tsc


backend be_rdp_tsc
    balance source
    mode http
    log global

    stick-table type ip size 1k expire 15s store http_err_rate(10s)
    acl errors_too_fast sc1_http_err_rate gt 8
    acl mark_as_abuser sc0_inc_gpc0(fe_rdp_tsc) gt 0
    acl clear_as_abuser sc0_clr_gpc0(fe_rdp_tsc) ge 0
    tcp-request content track-sc1 src
    tcp-request content reject if errors_too_fast mark_as_abuser
    tcp-request content accept if !errors_too_fast clear_as_abuser

    option forwardfor
    http-request add-header X-CLIENT-IP %[src]

    option httpchk GET /
    cookie RDPWEB insert nocache
    default-server inter 3s    rise 2  fall 3
    server rdgw01 192.168.1.33:443 maxconn 1000 weight 10 ssl check cookie rdgw01
    server rdgw02 192.168.2.33:443 maxconn 1000 weight 10 ssl check cookie rdgw02


frontend fe_stats
    mode http
    bind *:8080
    acl ip_allow_admin src 192.168.66.66
    stats enable
    stats uri /stats
    stats refresh 30s
    #stats admin if LOCALHOST
    stats admin if ip_allow_admin

Почему два сервера на backend? Потомучто так можно сделать отказоустойчивость. Haproxy тоже можете сделать два с плавающим белым ip.

Вычислительные ресурсы: можно начать с «два гига, два ядра, игровой ПК». Согласно википедии этого будет достаточно с запасом.

Ссылки:

Настройка rdp-gateway от HAProxy
Единственная найденная мною статья, где озаботились перебором пароля

Реализация высокой доступности в веб-интерфейсе шлюза и веб-доступа к удаленным рабочим столам

11/08/2016

Чтение занимает 6 мин

В этой статье

Применяется к: Windows Server (Semi-Annual Channel), Windows Server 2019, Windows Server 2016Applies to: Windows Server (Semi-Annual Channel), Windows Server 2019, Windows Server 2016

Можно развернуть ферму с веб-доступом к удаленным рабочим столам и шлюзом удаленных рабочих столов, чтобы повысить доступность и масштаб развертывания служб удаленных рабочих столов (RDS) под управлением Windows Server.You can deploy a Remote Desktop Web Access (RD Web Access) and Remote Desktop Gateway (RD Gateway) farm to improve the availability and scale of a Windows Server Remote Desktop Services (RDS) deployment

Следуя инструкциям ниже, добавьте сервер веб-доступа к удаленным рабочим столам и сервер шлюза в существующее базовое развертывание RDS.Use the following steps to add an RD Web and Gateway server to an existing Remote Desktop Services basic deployment.

Предварительные требованияPre-requisites

Настройте сервер в качестве дополнительного сервера веб-доступа к удаленным рабочим столам и сервера шлюза удаленных рабочих столов. Это может быть физический сервер или виртуальная машина.Set up a server to act as an additional RD Web and RD Gateway — this can be either a physical server or VM. Необходимо также присоединить этот сервер к домену и включить удаленное управление.This includes joining the server to the domain and enabling remote management.

Шаг 1. Настройка нового сервера для добавления в среду RDSStep 1: Configure the new server to be part of the RDS environment

Подключитесь к серверу RDMS на портале Azure с помощью клиента подключения к удаленному рабочему столу.Connect to the RDMS server in the Azure portal, using Remote Desktop Connection client.
Добавьте новый сервер RDSH в диспетчер серверов.Add the new RD Web and Gateway server to Server Manager:
1. Запустите диспетчер серверов, щелкните Управление > Добавление серверов.Launch Server Manager, click Manage > Add Servers.
2. В диалоговом окне «Добавление серверов», нажмите кнопку Найти.In the Add Servers dialog, click Find Now.
3. Выберите только что созданный сервер веб-доступа к удаленным рабочим столам и шлюза (например, Contoso-WebGw2) и нажмите кнопку ОК.Select the newly created RD Web and Gateway server (for example, Contoso-WebGw2) and click OK.
Добавление сервера веб-доступа к удаленным рабочим столам и шлюза в развертываниеAdd RD Web and Gateway servers to the deployment
1. Запустите диспетчер серверов.Launch Server Manager .
2. Щелкните Службы удаленных рабочих столов > Обзор > Серверы развертывания > Задачи > Add RD Web Access Servers (Добавить серверы веб-доступа к удаленным рабочим столам).Click Remote Desktop Services > Overview > Deployment Servers > Tasks > Add RD Web Access Servers.
3. Выберите недавно созданный сервер (например, Contoso-WebGw2), а затем нажмите кнопку Далее.Select the newly created server (for example, Contoso-WebGw2), and then click Next.
4. На странице подтверждения выберите Перезапустить удаленные компьютеры при необходимости, а затем нажмите кнопку Добавить.On the Confirmation page, select Restart remote computers as needed, and then click Add.
5. Повторите эти шаги, чтобы добавить сервер шлюза удаленных рабочих столов, но выберите Серверы шлюза удаленных рабочих столов на шаге b.Repeat these steps to add the RD Gateway server, but choose RD Gateway Servers in step b.
Повторно установите сертификаты для серверов шлюза удаленных рабочих столов.Re-install certificates for the RD Gateway servers:
1. В диспетчере серверов на серверк RDMS щелкните Службы удаленных рабочих столов > Задачи > Изменить свойства развертывания.In Server Manager on the RDMS server, click Remote Desktop Services > Overview > Tasks > Edit Deployment Properties.
2. Разверните элемент Сертификаты.Expand Certificates.
3. Прокрутите его вниз до таблицы.Scroll down to the table. Щелкните Gateway Role Service (Служба роли шлюза) > Выбрать существующий сертификат.Click RD Gateway Role Service > Select existing certificate.
4. Щелкните Выбрать другой сертификат и найдите нужный сертификат.Click Choose a different certificate and then browse to the certificate location. Например, \Contoso-CB1\Certificates.For example, \Contoso-CB1\Certificates). Выберите файл сертификата для сервера веб-доступа к удаленным рабочим столам и сервера шлюза, созданный при выполнении предварительных требований (например, ContosoRdGwCert), и нажмите кнопку Открыть.Select the certificate file for the RD Web and Gateway server created during the prerequisites (e.g. ContosoRdGwCert), and then click Open.
5. Введите пароль для сертификата, установите флажок Разрешить добавление сертификата в хранилище «Доверенные корневые центры сертификации» на конечных компьютерах, а затем нажмите кнопку ОК.Enter the password for the certificate, select Allow the certificate to be added to the Trusted Root Certificate Authorities certificate store on the destination computers, and then click OK.
6. Щелкните Применить.Click Apply.
  Примечание
  Возможно, потребуется вручную перезапустить службу TSGateway, выполняемую на каждом сервере шлюза удаленных рабочих столов, воспользовавшись диспетчером серверов или диспетчером задач.You may need to manually restart the TSGateway service running on each RD Gateway server, either through Server Manager or Task Manager.
7. Повторите шаги a–f для службы роли веб-доступа к удаленным рабочим столам.Repeat steps a through f for the RD Web Access Role Service.

Шаг 2. Настройка свойств веб-доступа к удаленным рабочим столам и шлюза удаленных рабочих столов на новом сервереStep 2: Configure RD Web and RD Gateway properties on the new server

Настройте сервер для добавления в ферму шлюза удаленных рабочих столов.Configure the server to be part of an RD Gateway farm:
1. В диспетчере серверов на сервере RDMS и щелкните Все серверы.In Server Manager on the RDMS server, click All Servers. Щелкните правой кнопкой мыши один из серверов шлюза удаленных рабочих столов, а затем выберите Подключение к удаленному рабочему столу.Right-click one of the RD Gateway servers, and then click Remote Desktop Connection.
2. Войдите на сервер шлюза удаленных рабочих столов, используя учетную запись администратора домена.Sign into to the RD Gateway server using a domain admin account.
3. В диспетчере серверов на сервере шлюза удаленных рабочих столов щелкните Средства > Службы удаленных рабочих столов > Диспетчер шлюза удаленных рабочих столов.In Server Manager on the RD Gateway server, click Tools > Remote Desktop Services > RD Gateway Manager.
4. В области навигации выберите локальный компьютер (например, Contoso-WebGw1).In the navigation pane, click the local computer (e.g. Contoso-WebGw1).
5. Щелкните Добавление членов фермы серверов шлюзов удаленных рабочих столов.Click Add RD Gateway Server Farm members.
6. На вкладке Ферма серверов введите имя каждого сервера шлюза удаленных рабочих столов, а затем нажмите кнопки Добавить и Применить.On the Server Farm tab, enter the name of each RD Gateway server, then click Add and Apply.
7. Повторите шаги a–f на каждом сервере шлюза удаленных рабочих столов, чтобы они распознавали друг друга в качестве серверов шлюза удаленных рабочих столов в ферме.Repeat steps a through f on each RD Gateway server so that they recognize each other as RD Gateway servers in a farm. Не волнуйтесь, если появились предупреждения, так как для распространения параметров DNS может потребоваться время.Do not be alarmed if there are warnings, as it might take time for DNS settings to propagate.
Настройте сервер для добавления в ферму веб-доступа к удаленным рабочим столам.Configure the server to be part of an RD Web Access farm. Выполнив приведенные ниже действия, вы сможете настроить одинаковые ключи проверки и ключи расшифровки на компьютерах на обоих сайтах RDWeb.The steps below configure the Validation and Decryption Machine Keys to be the same on both RDWeb sites.
1. В диспетчере серверов на сервере RDMS и щелкните Все серверы.In Server Manager on the RDMS server, click All Servers. Щелкните правой кнопкой мыши первый сервер веб-доступа к удаленным рабочим столам (например, Contoso-WebGw1) и выберите Подключение к удаленному рабочему столу.Right-click the first RD Web Access server (e.g. Contoso-WebGw1) and then click Remote Desktop Connection.
2. Войдите на сервер веб-доступа к удаленным рабочим столам, используя учетную запись администратора домена.Sign into the RD Web Access server using a domain admin account.
3. В диспетчере серверов на сервере веб-доступа к удаленным рабочим столам щелкните Средства > Диспетчер Internet Information Services (IIS) .In Server Manager on the RD Web Access server, click Tools > Internet Information Services (IIS) Manager.
4. В левой области диспетчера служб IIS разверните сервер (например, Contoso-WebGw1) > Сайты > Веб-сайт по умолчанию, а затем щелкните RDWeb.In the left pane of IIS Manager, expand the Server (e.g. Contoso-WebGw1) > Sites > Default Web Site, and then click RDWeb.
5. Щелкните правой кнопкой мыши Ключ машины, а затем выберите Открытие функции.Right-click Machine Key, and then click Open Feature.
6. На странице «Ключ машины» в области Действия выберите Создание ключей, а затем нажмите кнопку Применить.On the Machine Key page, in the Actions pane, select Generate Keys, and then click Apply.
7. Скопируйте ключ проверки (можно щелкнуть его правой кнопкой мыши и выбрать Копировать).Copy the validation key (you can right-click the key and then click Copy.)
8. В диспетчере служб IIS в разделе Веб-сайт по умолчанию по очереди выберите Feed, FeedLogon и Pages.In IIS Manager, under Default Web Site, select Feed, FeedLogon and Pages in turn.
9. Для каждой страницы сделайте следующее.For each:
  1. Щелкните правой кнопкой мыши Ключ машины, а затем выберите Открытие функции.Right-click Machine Key, and then click Open Feature.
  2. Для ключа проверки: снимите флажок Автоматически формировать во время выполнения, а затем вставьте ключ, скопированный на шаге g.For the Validation Key, clear Automatically generate at runtime, and then paste the key you copied in step g.
10. Сверните окно подключения к удаленному рабочему столу этого сервера веб-доступа к удаленным рабочим столам.Minimize the RD Connection window to this RD Web server.
11. Повторите шаги b–e для второго сервера веб-доступа к удаленным рабочим столам, завершая просмотром функции Ключ машины.Repeat steps b through e for the second RD Web Access server, ending on the feature view of Machine Key.
12. Для ключа проверки: снимите флажок Автоматически формировать во время выполнения, а затем вставьте ключ, скопированный на шаге g.For the Validation Key, clear Automatically generate at runtime, and then paste the key you copied in step g.
13. Щелкните Применить.Click Apply.
14. Выполните этот процесс для страниц RDWeb, Feed, FeedLogon и Pages.Complete this process for the RDWeb, Feed, FeedLogon and Pages pages.
15. Сверните окно подключения к удаленному рабочему столу второго сервера веб-доступа к удаленным рабочим столам, а затем разверните окно подключения к удаленному рабочему столу первого сервера веб-доступа к удаленным рабочим столам.Minimize the RD Connection window to the second RD Web Access server, and then maximize the RD Connection window to the first RD Web Access server.
16. Повторите шаги g–n, чтобы скопировать ключ расшифровки.Repeat steps g through n to copy over the Decryption Key.
17. Когда ключи проверки и ключи расшифровки будут идентичны на обоих серверах веб-доступа к удаленным рабочим столам для страниц RDWeb, Feed, FeedLogon и Pages, выполните выход из всех окон подключения к удаленному рабочему столу.When validation keys and decryption keys are identical on both RD Web Access servers for the RDWeb, Feed, FeedLogon and Pages pages, sign out of all RD Connection windows.

Шаг 3. Настройка балансировки нагрузки для сервера веб-доступа к удаленным рабочим столам и сервера шлюза удаленных рабочих столовStep 3: Configure load balancing for the RD Web and RD Gateway servers

Если вы используете инфраструктуру Azure, то можете создать внешний Azure Load Balancer. Если нет, то вы можете настроить отдельную аппаратную или программную подсистему балансировки.If you are using Azure infrastructure, you can create an external Azure load balancer; if not, you can set up a separate hardware or software load balancer. Балансировка нагрузки имеет решающее значение, так как трафик долговременных подключений клиентов удаленного рабочего стола будет равномерно распределяться и передаваться через шлюз удаленных рабочих столов на серверы, на которых пользователи будут выполнять свои рабочие нагрузки.Load balancing is key so that traffic will be evenly distributed the long-lived connections from Remote Desktop clients, through the RD Gateway, to the servers that users will be running their workloads.

Примечание

Если ваш предыдущий сервер, используемый для веб-доступа к удаленным рабочим столам и шлюза удаленных рабочих столов, уже был установлен под управлением внешней подсистемы балансировки нагрузки, перейдите к шагу 4, выберите существующий внутренний пул и добавьте в него новый сервер.If your previous server running RD Web and RD Gateway was already set up behind an external load balancer, skip ahead to step 4, select the existing backend pool, and add the new server to the pool.

Создайте Azure Load Balancer.Create an Azure Load Balancer:
1. На портале Azure выберите Обзор > Балансировщики нагрузки > Добавить.In the Azure portal click Browse > Load balancers > Add.
2. Введите имя, например WebGwLB.Enter a name, for example WebGwLB.
3. Для параметра Схема выберите Общедоступный.Select Public for the Scheme.
4. В разделе Общедоступный IP -адрес щелкните Выберите общедоступный IP-адрес, а затем выберите существующий общедоступный IP-адрес или создайте новый.Under Public IP address, select Choose a public IP address, and then pick an existing public IP address or create a new one.
5. Выберите соответствующие подписку, группу ресурсов и расположение.Select the appropriate Subscription, Resource Group, and Location.
6. Нажмите кнопку Create (Создать).Click Create.
Создайте пробу для отслеживания активности серверов.Create a probe to monitor which servers are alive:
1. На портале Azure выберите Обзор > Подсистемы балансировки нагрузки, а затем выберите подсистему балансировки нагрузки, созданную на предыдущем шаге.In the Azure portal, select Browse > Load Balancers, and then choose the load balancer that you created in the previous step.
2. Выберите Все параметры > Пробы > Добавить.Select All settings > Probes > Add.
3. Введите имя пробы, например HTTPS.Enter a name, for example, HTTPS, for the probe. Выберите протокол TCP и введите номер порта 443, затем нажмите кнопку ОК.Select TCP as the Protocol, and enter 443 for the Port, then click OK.
Создайте правила балансировки нагрузки HTTPS и UDP.Create the HTTPS and UDP load balancing rules:
1. В разделе Параметры щелкните Правила балансировки нагрузки.In Settings, click Load balancing rules.
2. Щелкните Добавить для правила HTPPS.Select Add for the HTTPS rule.
3. Введите имя для правила (например, HTTPS) и выберите протокол TCP.Enter a name for the rule, for example, HTTPS, and select TCP for the Protocol. Введите номер 443 для порта и внутреннего порта, затем нажмите кнопку ОК.Enter 443 for both Port and Backend port, and click OK.
4. В разделе Правила балансировки нагрузки щелкните Добавить для правила UDP.In Load balancing rules, click Add for the UDP rule.
5. Введите имя для правила (например, UDP) и выберите протокол UDP.Enter a name for the rule, for example, UDP, and select UDP for the Protocol. Введите номер 3391 для порта и внутреннего порта, затем нажмите кнопку ОК.Enter 3391 for both Port and Backend port, and click OK.
Создайте внутренний пул для сервера веб-доступа к удаленным рабочим столам и сервера шлюза удаленных рабочих столов.Create the backend pool for the RD Web and RD Gateway servers:
1. В разделе Параметры щелкните Серверные пулы адресов > Добавить.In Settings, click Backend address pools > Add.
2. Введите имя (например, WebGwBackendPool), а затем щелкните Добавить виртуальную машину.Enter a name (for example, WebGwBackendPool), then click Add a virtual machine.
3. Выберите группу доступности (например, WebGwAvSet), а затем нажмите кнопку ОК.Choose an availability set (for example, WebGwAvSet), and then click OK.
4. Щелкните Выберите виртуальные машины, выберите все виртуальные машины и щелкните Выбрать > ОК > ОК.Click Choose the virtual machines, select each virtual machine, and then click Select > OK > OK.

Шлюзы удаленный рабочий стол настройки производительности

10/16/2017

Чтение занимает 2 мин

В этой статье

Примечание

В Windows 8 + и Windows Server 2012 R2 + шлюз удаленный рабочий стол (шлюз удаленных рабочих столов) поддерживает TCP, UDP и устаревшие транспорта RPC.In Windows 8+ and Windows Server 2012 R2+, Remote Desktop Gateway (RD Gateway) supports TCP, UDP, and the legacy RPC transports. Большая часть следующих данных касается устаревшего транспорта RPC.Most of the following data is regarding the legacy RPC transport. Если устаревший транспорт RPC не используется, этот раздел неприменим.If the legacy RPC transport is not being used, this section is not applicable.

В этом разделе описаны параметры, связанные с производительностью, которые помогают повысить производительность развертывания клиента и настройки, зависящие от особенностей использования сети клиентом.This topic describes the performance-related parameters that help improve the performance of a customer deployment and the tunings that rely on the customer’s network usage patterns.

По сути, шлюз удаленных рабочих столов выполняет множество операций пересылки пакетов между экземплярами подключение к удаленному рабочему столу и экземплярами сервера узла сеансов удаленных рабочих столов в сети клиента.At its core, RD Gateway performs many packet forwarding operations between Remote Desktop Connection instances and the RD Session Host server instances within the customer’s network.

Примечание

Следующие параметры применяются только к транспорту RPC.The following parameters apply to RPC transport only.

Службы IIS (IIS) и шлюз удаленных рабочих столов экспортируйте следующие параметры реестра, чтобы улучшить производительность системы в шлюзе удаленных рабочих столов.Internet Information Services (IIS) and RD Gateway export the following registry parameters to help improve system performance in the RD Gateway.

Настройка потоковThread tunings

MaxIOThreadsMaxiothreads
```
HKLM\Software\Microsoft\Terminal Server Gateway\Maxiothreads (REG_DWORD)
```
Этот пул потоков конкретного приложения определяет количество потоков, создаваемых шлюзом удаленных рабочих столов для обработки входящих запросов.This app-specific thread pool specifies the number of threads that RD Gateway creates to handle incoming requests. Если этот параметр реестра задан, он вступает в силу.If this registry setting is present, it takes effect. Число потоков равно числу логических процессов.The number of threads equals the number of logical processes. Если число логических процессоров меньше 5, по умолчанию используется 5 потоков.If the number of logical processors is less than 5, the default is 5 threads.
макспулсреадсMaxPoolThreads
```
HKLM\System\CurrentControlSet\Services\InetInfo\Parameters\MaxPoolThreads (REG_DWORD)
```
Этот параметр указывает количество потоков пула IIS, создаваемых для каждого логического процессора.This parameter specifies the number of IIS pool threads to create per logical processor. Потоки пула IIS пропускают сеть для запросов и обрабатывают все входящие запросы.The IIS pool threads watch the network for requests and process all incoming requests. Число макспулсреадс не включает потоки, потребляемые шлюзом удаленных рабочих столов.The MaxPoolThreads count does not include threads that RD Gateway consumes. Значение по умолчанию — 4.The default value is 4.

Настройка удаленного вызова процедур для шлюза удаленных рабочих столовRemote procedure call tunings for RD Gateway

Следующие параметры могут помочь в настройке удаленных вызовов процедур (RPC), полученных подключение к удаленному рабочему столу и компьютерами шлюза удаленных рабочих столов.The following parameters can help tune the remote procedure calls (RPC) that are received by Remote Desktop Connection and RD Gateway computers. Изменение окон помогает регулировать объем данных, передаваемых через каждое подключение, и может повысить производительность для сценариев RPC через HTTP v2.Changing the windows helps throttle how much data is flowing through each connection and can improve performance for RPC over HTTP v2 scenarios.

серверрецеивевиндовServerReceiveWindow
```
HKLM\Software\Microsoft\Rpc\ServerReceiveWindow (REG_DWORD)
```
Значение по умолчанию — 64 КБ.The default value is 64 KB. Это значение указывает окно, используемое сервером для данных, получаемых от прокси-сервера RPC.This value specifies the window that the server uses for data that is received from the RPC proxy. Минимальное значение равно 8 КБ, а максимальное значение равно 1 ГБ.The minimum value is set to 8 KB, and the maximum value is set at 1 GB. Если значение не указано, используется значение по умолчанию.If a value is not present, the default value is used. При внесении изменений в это значение необходимо перезапустить службы IIS, чтобы изменения вступили в силу.When changes are made to this value, IIS must be restarted for the change to take effect.
серверрецеивевиндовServerReceiveWindow
```
HKLM\Software\Microsoft\Rpc\ServerReceiveWindow (REG_DWORD)
```
Значение по умолчанию — 64 КБ.The default value is 64 KB. Это значение указывает окно, которое клиент использует для данных, получаемых от прокси-сервера RPC.This value specifies the window that the client uses for data that is received from the RPC proxy. Минимальное значение — 8 КБ, а максимальное значение — 1 ГБ.The minimum value is 8 KB, and the maximum value is 1 GB. Если значение не указано, используется значение по умолчанию.If a value is not present, the default value is used.

Мониторинг и сбор данныхMonitoring and data collection

Следующий список счетчиков производительности считается базовым набором счетчиков при мониторинге использования ресурсов на шлюзе удаленных рабочих столов.The following list of performance counters is considered a base set of counters when you monitor the resource usage on the RD Gateway:

\Шлюз службы терминалов\*\Terminal Service Gateway\*
\Прокси-сервер RPC/HTTP\*\RPC/HTTP Proxy\*
\Прокси-сервер RPC/HTTP для каждого сервера\*\RPC/HTTP Proxy Per Server\*
\Веб-служба\*\Web Service\*
\W3SVC _ w3wp\*\W3SVC_W3WP\*
\IPv4\*\IPv4\*
\Свободной\*\Memory\*
\Сетевой интерфейс ( * )\*\Network Interface(*)\*
\Процесс ( * )\*\Process(*)\*
\Сведения о процессоре ( * )\*\Processor Information(*)\*
\Синхронизация ( * )\*\Synchronization(*)\*
\Системой\*\System\*
\TCPv4\*\TCPv4\*

Следующие счетчики производительности применимы только для устаревшего транспорта RPC:The following performance counters are applicable only for legacy RPC transport:

\RPC RPC/HTTP \ прокси *\RPC/HTTP Proxy\* RPC
\RPC/HTTP-прокси для \ каждого сервера *\RPC/HTTP Proxy Per Server\* RPC
\RPC веб-службы \ *\Web Service\* RPC
\W3SVC _ w3wp \ * RPC\W3SVC_W3WP\* RPC

Примечание

Если применимо, добавьте \ \ * объекты IPv6 и \ TCPv6 \ * . ReplaceThisTextIf applicable, add the \IPv6\* and \TCPv6\* objects.ReplaceThisText

Настройка параметров шлюза удаленных рабочих столов

Чтобы определить, будут ли пользователи подключаться к серверу Узел сеансов удаленных рабочих столов через брандмауэр и Шлюз удаленных рабочих столов, можно настроить параметры развертывания Шлюз удаленных рабочих столов.

Для выполнения этой процедуры пользователь по меньшей мере должен быть членом локальной группы Администраторы или аналогичной группы на сервере узла сеансов удаленных рабочих столов, который планируется настроить. Подробные сведения об использовании соответствующих учетных записей и членства в группах см. на странице https://go.microsoft.com/fwlink/?LinkId=83477.

Настройка параметров шлюза удаленных рабочих столов

На сервере узла сеансов удаленных рабочих столов откройте диспетчер удаленных приложений RemoteApp. Чтобы открыть диспетчер удаленных приложений RemoteApp, нажмите кнопку Пуск, затем последовательно выберите пункты Администрирование, Службы удаленных рабочих столов и Диспетчер удаленных приложений RemoteApp.
В области Действия средства Диспетчер удаленных приложений RemoteApp выберите пункт Параметры шлюза удаленных рабочих столов. Либо в области Обзор рядом с пунктом Параметры шлюза удаленных рабочих столов нажмите кнопку Изменить.

На вкладке Шлюз удаленных рабочих столов настройте требуемые параметры Шлюз удаленных рабочих столов. Можно настроить автоматическое определение параметров сервера Шлюз удаленных рабочих столов, использование заданных пользователем параметров сервера Шлюз удаленных рабочих столов, а также вообще не использовать сервер Шлюз удаленных рабочих столов.

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

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

Настройте имя сервера Шлюз удаленных рабочих столов и метод входа.

Важно!

Имя сервера должно соответствовать указанному в SSL-сертификате для сервера Шлюз удаленных рабочих столов.

Если необходимо предпринимать попытки использовать в подключении одни и те же учетные данные пользователя для доступа как к серверу Шлюз удаленных рабочих столов, так и к серверу Узел сеансов удаленных рабочих столов, установите флажок Использовать одинаковые учетные данные для шлюза и хост-сервера сеансов удаленных рабочих столов. Однако пользователи все равно могут получать два запроса учетных данных, если в одном из источников, таком как параметры групповой политики, имеются конфликтующие учетные данные, и эти данные не работают. Также могут отображаться два запроса учетных данных, если для подключения используются учетные данные по умолчанию, и они не работают.
Если требуется, чтобы клиентский компьютер автоматически определял необходимость использования Шлюз удаленных рабочих столов, установите флажок Не использовать сервер шлюза удаленных рабочих столов для локальных адресов. (Установка этого параметра оптимизирует производительность клиента.)
Чтобы всегда использовать сервер Шлюз удаленных рабочих столов для клиентских подключений, снимите флажок Не использовать сервер шлюза удаленных рабочих столов для локальных адресов.

По завершении нажмите кнопку ОК.

Дополнительные сведения о шлюзе удаленных рабочих столов см. на странице «Службы удаленных рабочих столов» (может быть на английском языке) технического центра Windows Server 2008 R2 (https://go.microsoft.com/fwlink/?LinkId=140433).

Дополнительные сведения о параметрах групповой политики для служб удаленных рабочих столов см. в техническом справочнике по службам удаленных рабочих столов (может быть на английском языке) (https://go.microsoft.com/fwlink/?LinkId=138134).

Дополнительные источники информации

Создание терминальной фермы RDS с использованием технологии NLB и публикация RD Web Access на ISA Server 2006

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

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

Как мы видим, имя нашего домена – domain.local. Для доступа к терминальным службам снаружи будет использоваться доменное имя domain.ru. Таким образом, в нашем DNS домена domain.local нам необходимо будет создать дополнительную зону с именем domain.ru, где мы потом создадим запись RDS.domain.ru, которая будет ссылаться на IP адрес терминальной фермы.

1. Установка терминальных служб на сервер RDS1.

1.1 Добавляем роли «Службы удаленных рабочих столов» (Remote Desktop Services) и «Службы политики сети и доступа» (Network Policy and Access Services). Выбираем для установки следующие службы ролей:

— Узел сеансов удаленных рабочих столов (Remote Desktop Session Host)

— Шлюз удаленных рабочих столов (Remote Desktop Gateway)

— Веб-доступ к удаленным рабочим столам (Remote Desktop Web Access)

— Сервер политики сети (NPS)

При установке служб ставим галочку «Require NLA», остальные настройки сконфигурим позже. Перезагружаем сервер при первом же требовании.

1.2 Создадим в ДНС нашего домена запись RDFarm.domain.local, которой присвоим IP адрес 192.168.0.80. Это будет внутренний адрес нашей фермы, а также адрес кластера NLB.

1.3 Создадим в ДНС зоне domain.ru нашего домена запись RDS.domain.ru, которой присвоим тот же IP адрес, что и адрес кластера — 192.168.0.80. Это будет внешний адрес нашей фермы, через который будут заходить удаленные пользователи.

1.4 Заходим в оснастку Remote Desktop Services – RemoteApp Manager – RD Gateway и настраиваем параметры следующим образом:

На закладке Digital Signature указываем сертификат, который надо предварительно запросить. Для выполнения этого шага в вашем домене должен быть центр сертификации (CA). На сервере RDS1 запустите mmc и добавьте оснастку Certificates (computer account):

После получения сертификата экспортируйте его в pfx-файл – он нам понадобится для настройки второго сервера.

Теперь на закладке Digital Signature мы можем указать наш сертификат:

1.5 Заходим в оснастку Remote Desktop Services – RemoteApp Manager и в разделе RemoteApp Programs и добавим одно удаленное приложение. Пусть это будет калькулятор.

Нажмем кнопку «Properties» и добавим в список пользователей, которые смогут запускать наш Калькулятор, группу rd_users.

1.6 Заходим в оснастку Remote Desktop Services – RD Gateway Manager и настраиваем свойства RDS1 (Local). Но перед этим необходимо запросить еще один сертификат (см. пункт 1.4), но на сей раз с Common Name внешнего адреса – RDS.domain.ru.

На закладке Private Key не забудьте указать, что ключ может быть экспортирован.

После получения сертификата экспортируйте его в pfx-файл – он нам понадобится для настройки второго сервера.

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

Переходим на закладку Server Farm, где добавим наш сервер RDS1 в ферму шлюзов:

Обратите внимание, что на данном этапе поле статус не обязательно должно иметь состояние «ОК».

1.7 Заходим в оснастку Remote Desktop Services – RD Gateway Manager — RDS1 (Local) – Policies – Connection Authorization Policies и создаем политику авторизации подключений при помощи мастера:

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

1.8 Заходим в оснастку Remote Desktop Services – RD Gateway Manager — RDS1 (Local) – Policies – Resource Authorization Policies и создаем политику авторизации приложений минуя мастер (Create New Policy – Custom):

1.9 Заходим в оснастку Remote Desktop Services – RD Session Host Configuration и настраиваем свойства подключения RDP-Tcp следующим образом:

Нажимаем на кнопку «Select» и указываем сертификат с Common Name нашей фермы – RDFarm.domain.local (он уже был установлен на сервер в пункте 1.4).

Остальные параметры не настраиваем.

Здесь же, в RD Session Host Configuration, настраиваем параметры лицензирования.

1.10 Для проверки правильности настройки приложения RemoteApp заходим на адрес localhost/RDWeb

2. Установка терминальных служб на сервер RDS2.

2.1 Добавляем роли «Службы удаленных рабочих столов» (Remote Desktop Services) и «Службы политики сети и доступа» (Network Policy and Access Services). Выбираем для установки следующие службы ролей:

— Узел сеансов удаленных рабочих столов (Remote Desktop Session Host)

— Шлюз удаленных рабочих столов (Remote Desktop Gateway)

— Веб-доступ к удаленным рабочим столам (Remote Desktop Web Access)

— Сервер политики сети (NPS)

2.2 Настраиваем второй сервер RDS2 точно таким же образом, как и настроен наш первый сервер за исключением того, что сертификаты уже запрашивать не нужно – их надо импортировать с сервера RDS1. Для импортирования сертификатов запустите mmc и добавьте оснастку Certificates (computer account):

Укажите путь к pfx файлам, содержащим сертификаты, и импортируйте их в личные сертификаты компьютера RDS2.

3. Создание и конфигурирование терминальной фермы.

3.1 Устанавливаем роль RD Connection Broker на сервер BROKER.

3.2 Добавляем сервера RDS1 и RDS2 в локальную группу Session Broker Computers на сервере BROKER.

3.3 Добавляем все наши три сервера в локальную группу TS Web Access Computers на серверах RDS1 и RDS2

3.4 На сервере BROKER добавляем наши сервера RDS1 и RDS2 в группу RD Web Access (Admin Tools > Remote Desktop Services > Remote Desktop Connection Manager > Add RD Web Access Server).

3.5 Сперва на сервере RDS1, а затем и на RDS2, заходим в Remote Desktop Services > Remote Desktop Session Host Configuration и меняем настройки RD Connection Broker:

3.6 Настраиваем удаленные приложения RemoteApp на работу с нашей фермой. Для этого на серверах RDS1 и RDS2 заходим в Remote Desktop Services > RemoteApp Manager и меняем параметр Server Name:

3.7 На сервере BROKER идем в Remote Desktop Services > Remote Desktop Connection Manager > RemoteApp Sources и жмем кнопку «Add RemoteApp Source…»:

Добавляем все наши возможные ресурсы RemoteApp: RDFarm.domain.local, RDS1.domain.local, RDS2.domain.local и RDS.domain.ru.

3.8 Создаем кластер NLB.

3.8.1 Устанавливаем компонент Network Load Balancing на сервера RDS1 и RDS2. Далее открываем оснастку Network Load Balancing Manager на сервере RDS1 и создаем кластер:

Включаем в балансировку только 443 и 3389 TCP порты.

3.8.2 Добавляем второй компьютер (RDS2) в NLB кластер

3.9 Удостоверяемся, что на серверах RDS1 и RDS2, в свойствах сервера RD Gateway Manager на закладке Server Farm указаны оба наших сервера:

3.10 На серверах RDS1 и RDS2 заходим в оснастку IIS Manager, далее Sites – Default Web Site – RDWeb – Pages и справа жмем Application Settings, где присваиваем параметру DefaultTSGateway значение RDS.domain.ru:

4. Публикация фермы RemoteApp приложений на ISA Server.

Вначале необходимо установить наш сертификат с Common Name «RDS.domain.ru» на ISA сервер (сделать это можно так же, как в случае с сервером RDS2, когда мы переносили на него сертификат с RDS1).

Этот раздел я не буду рассматривать слишком подробно, а обойдусь лишь наиболее важными скриншотами с настройками правила публикации и созданием WEB-прослушивателя:

Спасибо за внимание.

Службы удаленных рабочих столов — доступ из любого места

03.11.2016
2 минуты на чтение

В этой статье

Применимо к: Windows Server (полугодовой канал), Windows Server 2019, Windows Server 2016

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

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

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

Установите зашифрованный туннель SSL между устройством конечного пользователя и сервером шлюза удаленных рабочих столов. : для подключения через любой сервер шлюза удаленных рабочих столов на сервере шлюза удаленных рабочих столов должен быть установлен сертификат, который распознает устройство конечного пользователя. При тестировании и проверке концепций можно использовать самозаверяющие сертификаты, но в любой производственной среде следует использовать только публично доверенные сертификаты от центра сертификации.
Проверка подлинности пользователя в среде : шлюз удаленных рабочих столов использует службу IIS для входящей почты для выполнения проверки подлинности и даже может использовать протокол RADIUS для использования решений многофакторной проверки подлинности, таких как Azure MFA. Помимо созданных политик по умолчанию, вы можете создать дополнительные политики авторизации ресурсов удаленных рабочих столов (RD RAP) и политики авторизации подключений к удаленным рабочим столам (RD CAP), чтобы более конкретно определить, какие пользователи должны иметь доступ к каким ресурсам в безопасной среде.
Передавать трафик между устройством конечного пользователя и указанным ресурсом. : Шлюз удаленных рабочих столов продолжает выполнять эту задачу, пока установлено соединение. Вы можете указать различные свойства тайм-аута на серверах шлюза удаленных рабочих столов, чтобы поддерживать безопасность среды на случай, если пользователь уйдет от устройства.

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

Добавьте высокую доступность к веб-интерфейсу RD Web и Gateway

08.11.2016
6 минут на чтение

В этой статье

Применимо к: Windows Server (полугодовой канал), Windows Server 2019, Windows Server 2016

Вы можете развернуть ферму веб-доступа к удаленным рабочим столам (веб-доступ к удаленным рабочим столам) и шлюза удаленных рабочих столов (шлюз удаленных рабочих столов), чтобы повысить доступность и масштабирование развертывания служб удаленных рабочих столов Windows Server (RDS).

Выполните следующие действия, чтобы добавить веб-сервер удаленных рабочих столов и сервер шлюза в существующее базовое развертывание служб удаленных рабочих столов.

Предварительные требования

Настройте сервер для работы в качестве дополнительного веб-узла удаленных рабочих столов и шлюза удаленных рабочих столов — это может быть физический сервер или виртуальная машина. Это включает в себя присоединение сервера к домену и включение удаленного управления.

Шаг 1. Настройте новый сервер как часть среды RDS

Подключитесь к серверу RDMS на портале Azure с помощью клиента подключения к удаленному рабочему столу.
Добавьте новый веб-сервер удаленных рабочих столов и сервер шлюза в диспетчер серверов:
1. Запустите Диспетчер серверов, щелкните Управление> Добавить серверы .
2. В диалоговом окне «Добавить серверы» нажмите Найти сейчас .
3. Выберите только что созданный веб-сервер удаленных рабочих столов и сервер шлюза (например, Contoso-WebGw2) и нажмите ОК .
Добавление веб-серверов удаленных рабочих столов и серверов шлюза в развертывание
1. Запустить диспетчер сервера.
2. Щелкните Службы удаленных рабочих столов> Обзор> Серверы развертывания> Задачи> Добавить серверы веб-доступа к удаленным рабочим столам .
3. Выберите только что созданный сервер (например, Contoso-WebGw2), а затем щелкните Далее .
4. На странице подтверждения выберите Перезагрузить удаленные компьютеры по мере необходимости , а затем щелкните Добавить .
5. Повторите эти шаги, чтобы добавить сервер шлюза удаленных рабочих столов, но выберите Серверы шлюза удаленных рабочих столов на этапе b.
Переустановите сертификаты для серверов шлюза удаленных рабочих столов:
1. В диспетчере серверов на сервере RDMS щелкните Службы удаленных рабочих столов> Обзор> Задачи> Изменить свойства развертывания .
2. Развернуть Сертификаты .
3. Прокрутите вниз до таблицы. Щелкните Служба роли шлюза RD > Выбрать существующий сертификат.
4. Щелкните Выберите другой сертификат , а затем перейдите в расположение сертификата. Например, \ Contoso-CB1 \ Certificates). Выберите файл сертификата для веб-сервера удаленных рабочих столов и сервера шлюза, созданного при выполнении предварительных требований (например, ContosoRdGwCert), а затем щелкните Открыть .
5. Введите пароль для сертификата, выберите Разрешить добавление сертификата в хранилище сертификатов доверенных корневых центров сертификации на конечных компьютерах , а затем нажмите ОК .
6. Щелкните Применить .
  Примечание
  Вам может потребоваться вручную перезапустить службу TSGateway, работающую на каждом сервере шлюза удаленных рабочих столов, с помощью диспетчера серверов или диспетчера задач.
7. Повторите шаги с a по f для службы роли веб-доступа к удаленным рабочим столам.

Шаг 2. Настройте свойства Веб-удаленных рабочих столов и Шлюз удаленных рабочих столов на новом сервере

Настройте сервер как часть фермы шлюза удаленных рабочих столов:
1. В диспетчере серверов на сервере RDMS щелкните Все серверы .Щелкните правой кнопкой мыши один из серверов шлюза удаленных рабочих столов и выберите Подключение к удаленному рабочему столу .
2. Войдите на сервер шлюза удаленных рабочих столов, используя учетную запись администратора домена.
3. В диспетчере серверов на сервере шлюза удаленных рабочих столов щелкните Инструменты > Службы удаленных рабочих столов> Диспетчер шлюза удаленных рабочих столов .
4. В области навигации щелкните локальный компьютер (например, Contoso-WebGw1).
5. Щелкните Добавить участников фермы серверов шлюза удаленных рабочих столов .
6. На вкладке Server Farm введите имя каждого сервера шлюза удаленных рабочих столов, затем нажмите Добавить и Применить .
7. Повторите шаги с a по f на каждом сервере шлюза удаленных рабочих столов, чтобы они распознавали друг друга как серверы шлюза удаленных рабочих столов в ферме. Не беспокойтесь, если появятся предупреждения, поскольку для распространения настроек DNS может потребоваться время.
Настройте сервер как часть фермы веб-доступа к удаленным рабочим столам. Приведенные ниже шаги настраивают ключи машины проверки и дешифрования так, чтобы они были одинаковыми на обоих сайтах RDWeb.
1. В диспетчере серверов на сервере RDMS щелкните Все серверы .Щелкните правой кнопкой мыши первый сервер веб-доступа к удаленным рабочим столам (например, Contoso-WebGw1), а затем щелкните Подключение к удаленному рабочему столу .
2. Войдите на сервер веб-доступа к удаленным рабочим столам, используя учетную запись администратора домена.
3. В диспетчере серверов на сервере веб-доступа к удаленным рабочим столам щелкните Инструменты > Диспетчер информационных служб Интернета (IIS) .
4. На левой панели диспетчера IIS разверните сервер (например, Contoso-WebGw1)> Сайты> Веб-сайт по умолчанию , а затем щелкните RDWeb .
5. Щелкните правой кнопкой мыши Машинный ключ , а затем щелкните Открыть элемент .
6. На странице Machine Key на панели Actions выберите Generate Keys , а затем щелкните Apply .
7. Скопируйте ключ проверки (щелкните ключ правой кнопкой мыши и выберите Копировать ).
8. В диспетчере IIS в разделе Веб-сайт по умолчанию выберите по очереди Feed , FeedLogon и Pages .
9. Для каждого:
  1. Щелкните правой кнопкой мыши Машинный ключ , а затем щелкните Открыть элемент .
  2. Для ключа проверки снимите флажок Автоматически создавать во время выполнения , а затем вставьте ключ, скопированный на шаге g.
10. Сверните окно подключения удаленного рабочего стола к этому веб-серверу удаленного рабочего стола.
11. Повторите шаги с b по e для второго сервера веб-доступа к удаленным рабочим столам, закончив на представлении функций Machine Key .
12. Для ключа проверки снимите флажок Автоматически создавать во время выполнения , а затем вставьте ключ, скопированный на шаге g.
13. Щелкните Применить .
14. Завершите этот процесс для RDWeb , Feed , FeedLogon и Pages страниц.
15. Сверните окно подключения к удаленному рабочему столу ко второму серверу веб-доступа к удаленным рабочим столам, а затем разверните окно подключения к удаленному рабочему столу к первому серверу веб-доступа к удаленным рабочим столам.
16. Повторите шаги с g по n, чтобы скопировать ключ дешифрования.
17. Если ключи проверки и ключи дешифрования идентичны на обоих серверах веб-доступа к удаленным рабочим столам для страниц RDWeb , Feed , FeedLogon и Pages , выйдите из всех окон подключения к удаленному рабочему столу.

Шаг 3. Настройте балансировку нагрузки для серверов RD Web и RD Gateway

Если вы используете инфраструктуру Azure, вы можете создать внешний балансировщик нагрузки Azure; если нет, вы можете настроить отдельный аппаратный или программный балансировщик нагрузки. Балансировка нагрузки является ключевым моментом, так как трафик будет равномерно распределяться между долгоживущими подключениями от клиентов удаленного рабочего стола через шлюз удаленных рабочих столов к серверам, на которых пользователи будут выполнять свои рабочие нагрузки.

Примечание

Если ваш предыдущий сервер, на котором запущен RD Web и RD Gateway, уже был настроен за внешним балансировщиком нагрузки, перейдите к шагу 4, выберите существующий внутренний пул и добавьте новый сервер в пул.

Создайте балансировщик нагрузки Azure:
1. На портале Azure щелкните Обзор> Балансировщики нагрузки> Добавить .
2. Введите имя, например WebGwLB .
3. Выберите Public для схемы .
4. Под общедоступным IP-адресом выберите Выберите общедоступный IP-адрес , а затем выберите существующий общедоступный IP-адрес или создайте новый.
5. Выберите соответствующую подписку , Группа ресурсов и Расположение .
6. Щелкните Создать .
Создайте зонд для отслеживания активных серверов:
1. На портале Azure выберите Обзор > Балансировщики нагрузки , а затем выберите балансировщик нагрузки, созданный на предыдущем шаге.
2. Выбрать Все настройки > Зонды > Добавить .
3. Введите имя, например HTTPS , для зонда. Выберите TCP в качестве протокола и введите 443 для порта , затем нажмите OK .
Создайте правила балансировки нагрузки HTTPS и UDP:
1. В Настройки щелкните Правила балансировки нагрузки .
2. Выберите Добавьте для правила HTTPS .
3. Введите имя правила, например HTTPS, и выберите TCP для протокола . Введите 443 для порта и для внутреннего порта и нажмите ОК .
4. В правилах балансировки нагрузки щелкните Добавить для правила UDP .
5. Введите имя правила, например UDP , и выберите UDP для протокола . Введите 3391 для порта и для внутреннего порта и нажмите ОК .
Создайте внутренний пул для серверов RD Web и RD Gateway:
1. В настройках щелкните Пулы внутренних адресов> Добавить .
2. Введите имя (например, WebGwBackendPool ), затем щелкните Добавить виртуальную машину .
3. Выберите группу доступности (например, WebGwAvSet), а затем нажмите ОК .
4. Щелкните Выберите виртуальные машины , выберите каждую виртуальную машину, а затем щелкните Выберите> ОК> ОК .

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

16.10.2017
2 минуты на чтение

В этой статье

Примечание

В Windows 8+ и Windows Server 2012 R2 + шлюз удаленных рабочих столов (шлюз удаленных рабочих столов) поддерживает TCP, UDP и устаревший транспорт RPC. Большая часть следующих данных относится к устаревшему транспорту RPC.Если прежний транспорт RPC не используется, этот раздел не применим.

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

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

Примечание

Следующие параметры применяются только к транспорту RPC.

Internet Information Services (IIS) и шлюз удаленных рабочих столов экспортируют следующие параметры реестра, чтобы повысить производительность системы в шлюзе удаленных рабочих столов.

Настройка резьбы

Максионить
```
  HKLM \ Software \ Microsoft \ Шлюз терминального сервера \ Maxiothreads (REG_DWORD)
  
```
Этот специфичный для приложения пул потоков определяет количество потоков, создаваемых шлюзом удаленных рабочих столов для обработки входящих запросов. Если этот параметр реестра присутствует, он вступает в силу.Количество потоков равно количеству логических процессов. Если количество логических процессоров меньше 5, по умолчанию используется 5 потоков.
MaxPoolThreads
```
  HKLM \ System \ CurrentControlSet \ Services \ InetInfo \ Parameters \ MaxPoolThreads (REG_DWORD)
  
```
Этот параметр указывает количество потоков пула IIS, создаваемых на логический процессор. Потоки пула IIS следят за сетью на предмет запросов и обрабатывают все входящие запросы.Счетчик MaxPoolThreads не включает потоки, которые использует шлюз удаленных рабочих столов. Значение по умолчанию — 4.

Настройка удаленного вызова процедур для шлюза удаленных рабочих столов

Следующие параметры могут помочь в настройке вызовов удаленных процедур (RPC), получаемых компьютерами с подключением к удаленному рабочему столу и шлюзом удаленных рабочих столов. Изменение окон помогает регулировать объем данных, проходящих через каждое соединение, и может повысить производительность для сценариев RPC через HTTP v2.

ServerReceiveWindow
```
  HKLM \ Software \ Microsoft \ Rpc \ ServerReceiveWindow (REG_DWORD)
  
```
Значение по умолчанию — 64 КБ. Это значение указывает окно, которое сервер использует для данных, полученных от прокси-сервера RPC. Минимальное значение установлено на 8 КБ, а максимальное значение установлено на 1 ГБ. Если значение отсутствует, используется значение по умолчанию. Когда в это значение вносятся изменения, необходимо перезапустить IIS, чтобы изменение вступило в силу.
ServerReceiveWindow
```
  HKLM \ Software \ Microsoft \ Rpc \ ServerReceiveWindow (REG_DWORD)
  
```
Значение по умолчанию — 64 КБ. Это значение указывает окно, которое клиент использует для данных, полученных от прокси-сервера RPC. Минимальное значение — 8 КБ, максимальное — 1 ГБ. Если значение отсутствует, используется значение по умолчанию.

Мониторинг и сбор данных

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

\ Шлюз служб терминалов \ *
\ RPC / HTTP-прокси \ *
\ RPC / HTTP-прокси на сервер \ *
\ Веб-сервис \ *
\ W3SVC_W3WP \ *
\ IPv4 \ *
\ Память \ *
\ Сетевой интерфейс (*) \ *
\ Процесс (*) \ *
\ Информация о процессоре (*) \ *
\ Синхронизация (*) \ *
\ Система \ *
\ TCPv4 \ *

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

Примечание

Если возможно, добавьте объекты \ IPv6 \ * и \ TCPv6 \ *.ReplaceThisText

классов шлюза удаленных рабочих столов — приложения Win32

31.05.2018
2 минуты на чтение

В этой статье

Поставщик WMI шлюза удаленных рабочих столов (RD Gateway) предоставляет следующие классы.

В этом разделе

Win32_TSGatewayConnection: Представляет подключение клиентского компьютера к серверу шлюза удаленных рабочих столов.
Win32_TSGatewayConnectionAuthorizationPolicy: Описывает политику авторизации подключения к удаленному рабочему столу (RD CAP). RD CAP используются для определения, разрешено ли пользователю подключаться к серверу шлюза удаленных рабочих столов.
Win32_TSGatewayLoadBalancer: Описывает набор серверов балансировки нагрузки шлюза удаленных рабочих столов. Они используются для балансировки нагрузки подключений к шлюзу удаленных рабочих столов на нескольких серверах.
Win32_TSGatewayRADIUSServer: Описывает сервер службы удаленной аутентификации пользователей с телефонным подключением (RADIUS), который имеет набор политик авторизации подключения к службам удаленных рабочих столов (RD CAP).
Win32_TSGatewayResourceAuthorizationPolicy: Описывает политику авторизации ресурсов удаленного рабочего стола (RD RAP). RD RAP используется, чтобы решить, авторизован ли пользователь для подключения к указанному ресурсу через шлюз удаленных рабочих столов.
Win32_TSGatewayResourceGroup: Описывает группу ресурсов, которая отображает набор ресурсов (имена компьютеров) на одну сущность.
Win32_TSGatewayServer: Используется для операций, связанных с сервером шлюза удаленных рабочих столов.
Win32_TSGatewayServerSettings: Предоставляет методы и свойства для просмотра и настройки параметров сервера шлюза удаленных рабочих столов.

Ноябрь 2024
Пн	Вт	Ср	Чт	Пт	Сб	Вс
				1	2	3
4	5	6	7	8	9	10
11	12	13	14	15	16	17
18	19	20	21	22	23	24
25	26	27	28	29	30

Сервер шлюза удаленных рабочих столов: Инструкция по настройке шлюза удаленных рабочих столов

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

Что такое RDG

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

Доступ к ресурсам

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

Как подключиться

RDS на основе сеансов в Windows Server 2012 R2. Часть 5 — Использование роли шлюза подключений (RD Gateway) — bearded sysadmin

Как работает шлюз удалённых рабочих столов?

Поддержка транспортного протокола UDP

Поддержка изменения стандартных номеров портов для протоколов HTTPS и UDP

Поддержка использования транспорта HTTP вместо RPC over HTTP

Установка службы RD Gateway

Подключение пользователей к ресурсам фермы RDS с помощью шлюза

***

MS Remote Desktop Gateway, HAProxy и перебор пароля / Хабр

Реализация высокой доступности в веб-интерфейсе шлюза и веб-доступа к удаленным рабочим столам

В этой статье

Предварительные требованияPre-requisites

Шаг 1. Настройка нового сервера для добавления в среду RDSStep 1: Configure the new server to be part of the RDS environment

Шаг 2. Настройка свойств веб-доступа к удаленным рабочим столам и шлюза удаленных рабочих столов на новом сервереStep 2: Configure RD Web and RD Gateway properties on the new server

Шлюзы удаленный рабочий стол настройки производительности

В этой статье

Мониторинг и сбор данныхMonitoring and data collection

Настройка параметров шлюза удаленных рабочих столов

Дополнительные источники информации

Создание терминальной фермы RDS с использованием технологии NLB и публикация RD Web Access на ISA Server 2006

1. Установка терминальных служб на сервер RDS1.

1.2 Создадим в ДНС нашего домена запись RDFarm.domain.local, которой присвоим IP адрес 192.168.0.80. Это будет внутренний адрес нашей фермы, а также адрес кластера NLB.

1.4 Заходим в оснастку Remote Desktop Services – RemoteApp Manager – RD Gateway и настраиваем параметры следующим образом:

1.5 Заходим в оснастку Remote Desktop Services – RemoteApp Manager и в разделе RemoteApp Programs и добавим одно удаленное приложение. Пусть это будет калькулятор.

1.7 Заходим в оснастку Remote Desktop Services – RD Gateway Manager — RDS1 (Local) – Policies – Connection Authorization Policies и создаем политику авторизации подключений при помощи мастера:

1.8 Заходим в оснастку Remote Desktop Services – RD Gateway Manager — RDS1 (Local) – Policies – Resource Authorization Policies и создаем политику авторизации приложений минуя мастер (Create New Policy – Custom):

1.9 Заходим в оснастку Remote Desktop Services – RD Session Host Configuration и настраиваем свойства подключения RDP-Tcp следующим образом:

1.10 Для проверки правильности настройки приложения RemoteApp заходим на адрес localhost/RDWeb

2. Установка терминальных служб на сервер RDS2.

3. Создание и конфигурирование терминальной фермы.

3.1 Устанавливаем роль RD Connection Broker на сервер BROKER.

3.6 Настраиваем удаленные приложения RemoteApp на работу с нашей фермой. Для этого на серверах RDS1 и RDS2 заходим в Remote Desktop Services > RemoteApp Manager и меняем параметр Server Name:

3.7 На сервере BROKER идем в Remote Desktop Services > Remote Desktop Connection Manager > RemoteApp Sources и жмем кнопку «Add RemoteApp Source…»:

3.8 Создаем кластер NLB.

3.8.1 Устанавливаем компонент Network Load Balancing на сервера RDS1 и RDS2. Далее открываем оснастку Network Load Balancing Manager на сервере RDS1 и создаем кластер:

3.8.2 Добавляем второй компьютер (RDS2) в NLB кластер

3.10 На серверах RDS1 и RDS2 заходим в оснастку IIS Manager, далее Sites – Default Web Site – RDWeb – Pages и справа жмем Application Settings, где присваиваем параметру DefaultTSGateway значение RDS.domain.ru:

4. Публикация фермы RemoteApp приложений на ISA Server.

Службы удаленных рабочих столов — доступ из любого места

В этой статье

Добавьте высокую доступность к веб-интерфейсу RD Web и Gateway

В этой статье

Предварительные требования

Шаг 1. Настройте новый сервер как часть среды RDS

Шаг 2. Настройте свойства Веб-удаленных рабочих столов и Шлюз удаленных рабочих столов на новом сервере

Шаг 3. Настройте балансировку нагрузки для серверов RD Web и RD Gateway

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

В этой статье

Мониторинг и сбор данных

классов шлюза удаленных рабочих столов — приложения Win32

В этой статье

В этом разделе

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