Настройка шлюза удаленного рабочего стола в Windows Server 2019

Обновлено: 21.11.2024

Когда речь идет о поддерживаемых конфигурациях для сред служб удаленных рабочих столов, наибольшей проблемой, как правило, является совместимость версий. Большинство сред включают в себя несколько версий Windows Server. Например, у вас может быть существующее развертывание Windows Server 2012 R2 RDS, но вы хотите выполнить обновление до Windows Server 2016, чтобы воспользоваться преимуществами новых функций (таких как поддержка OpenGL\OpenCL, назначение дискретных устройств, или Storage Spaces Direct). Возникает вопрос, какие компоненты RDS могут работать с разными версиями, а какие должны быть одинаковыми?

Помня об этом, ниже приведены основные рекомендации по поддерживаемым конфигурациям служб удаленных рабочих столов в Windows Server.

Рекомендации

Используйте Windows Server 2019 для инфраструктуры удаленного рабочего стола (веб-доступ, шлюз, посредник подключений и сервер лицензий). Windows Server 2019 обратно совместим с этими компонентами, что означает, что узел сеансов удаленного рабочего стола Windows Server 2016 или Windows Server 2012 R2 может подключаться к посреднику подключений к удаленному рабочему столу 2019, но не наоборот.

Для узлов сеансов удаленных рабочих столов: все узлы сеансов в коллекции должны быть одного уровня, но у вас может быть несколько коллекций. У вас может быть коллекция с узлами сеансов Windows Server 2016 и одна с узлами сеансов Windows Server 2019.

Если вы обновляете узел сеансов удаленных рабочих столов до Windows Server 2019, также обновите сервер лицензий. Помните, что сервер лицензий 2019 года может обрабатывать клиентские лицензии всех предыдущих версий Windows Server, вплоть до Windows Server 2003.

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

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

В Windows Server 2016 снято ограничение на количество посредников подключений, которые вы можете иметь в развертывании при использовании узлов сеансов удаленных рабочих столов (RDSH) и узлов виртуализации удаленных рабочих столов (RDVH), которые также работают под управлением Windows Server 2016. В следующей таблице показано, какие версии компонентов RDS работают в высокодоступном развертывании с тремя или более посредниками подключений.

Поддержка ускорения графического процессора (GPU)

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

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

Поставщики графических процессоров могут иметь отдельную схему лицензирования для сценариев RDSH или ограничивать использование графических процессоров в серверной ОС. Уточните требования у вашего предпочтительного поставщика.

Графические процессоры, представленные гипервизором или облачной платформой, отличной от Microsoft, должны иметь драйверы с цифровой подписью WHQL и предоставленные поставщиком графического процессора.

Поддержка узла сеансов удаленных рабочих столов для графических процессоров

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

3+ посредника подключения в высокой доступности RDSH или RDVH 2022 RDSH или RDVH 2019 RDSH или RDVH 2016 RDSH или RDVH 2012 R2
Посредник соединений Windows Server 2022 Поддерживается Поддерживается Поддерживается Поддерживается
Посредник соединений Windows Server 2019 Н/Д Поддерживается Поддерживается Поддерживается
Посредник соединений Windows Server 2016 Н/Д Н/Д Поддерживается Поддерживается
Посредник соединений Windows Server 2012 R2< /td> Н/Д Н/Д Н/Д Не поддерживается
< th>Windows Server 2019
Функция Windows Server 2008 R2 Windows Server 2012 R2 Windows Server 2016 Windows Server 2022
Использование аппаратного графического процессора для всех сеансов RDP Нет Да Да Да Да
H. 264/AVC аппаратное кодирование (если поддерживается графическим процессором) Нет Нет Да Да Да
Балансировка нагрузки между несколькими графическими процессорами, представленными ОС Нет Нет Нет< /td> Да Да
Оптимизация кодирования H.264/AVC для минимизации использования полосы пропускания Нет Нет Нет Да Да
Поддержка H.264/AVC для разрешения 4K Нет Нет Нет Да Да

Поддержка VDI для графических процессоров

В следующей таблице показана поддержка сценариев графического процессора в клиентской ОС.

< /th>
Функция Windows 7 SP1 Windows 8.1 Windows 10
Использование аппаратного графического процессора для всех сеансов RDP Нет Да Да
Аппаратное кодирование H.264/AVC (если поддерживается графическим процессором) Нет Нет Windows 10 1703 или новее
Балансировка нагрузки между несколькими графическими процессорами, представленными в ОС Нет Нет Windows 10 1803 или позже
Оптимизация кодирования H.264/AVC для минимизации использования полосы пропускания Нет Нет Windows 10 1803 или новее
Поддержка H.264/AVC для разрешения 4K Нет Нет Windows 10 1803 или более поздней версии

Поддержка 3D-видеоадаптера RemoteFX (vGPU)

Из соображений безопасности RemoteFX vGPU по умолчанию отключен во всех версиях Windows, начиная с обновления безопасности от 14 июля 2020 г., и удаляется, начиная с обновления безопасности от 13 апреля 2021 г. Дополнительные сведения см. в статье 4570006 базы знаний.

Службы удаленных рабочих столов поддерживают виртуальные графические процессоры RemoteFX, когда виртуальная машина работает в качестве гостя Hyper-V на Windows Server 2012 R2 или Windows Server 2016. Следующие гостевые операционные системы поддерживают виртуальные графические процессоры RemoteFX:

  • Windows 7 с пакетом обновления 1 (SP1)
  • Windows 8.1
  • Windows 10 1703 или более поздней версии
  • Windows Server 2016 только в развертывании с одним сеансом

Поддержка дискретного назначения устройств

Службы удаленных рабочих столов поддерживают физические графические процессоры, представленные с назначением дискретных устройств с хостов Hyper-V под управлением Windows Server 2016 или более поздней версии. Дополнительные сведения см. в разделе План развертывания назначения дискретных устройств.

Развертывание VDI — поддерживаемые гостевые ОС

Узел-серверы виртуализации удаленных рабочих столов под управлением Windows Server 2016 или более поздней версии поддерживают следующие гостевые ОС:

  • Windows 10 Корпоративная
  • Windows 8.1 Корпоративная
  • Windows 7 Корпоративная с пакетом обновления 1 (SP1)
  • Службы удаленных рабочих столов не поддерживают гетерогенные наборы сеансов. Операционные системы всех ВМ в коллекции должны быть одной версии.
  • Вы можете иметь отдельные однородные коллекции с разными версиями гостевых ОС на одном хосте.
  • Хост Hyper-V, используемый для запуска ВМ, должен иметь ту же версию, что и хост Hyper-V, используемый для создания исходных шаблонов ВМ.

Единый вход

RDS в Windows Server 2016 или более поздней версии поддерживает два основных способа единого входа:

  • В приложении (приложение для удаленного рабочего стола в Windows, iOS, Android и Mac)
  • Система единого входа в Интернете

Используя приложение удаленного рабочего стола, вы можете безопасно хранить учетные данные либо как часть информации о подключении (Mac), либо как часть управляемых учетных записей (iOS, Android, Windows) с помощью механизмов, уникальных для каждой ОС.

Для подключения к рабочим столам и приложениям RemoteApp с единым входом через входящий клиент подключения к удаленному рабочему столу в Windows необходимо подключиться к веб-странице удаленного рабочего стола через Internet Explorer. На стороне сервера требуются следующие параметры конфигурации. Никакие другие конфигурации для веб-системы единого входа не поддерживаются:

  • Для RD Web выбрана аутентификация на основе форм (по умолчанию)
  • Шлюз удаленных рабочих столов настроен на аутентификацию по паролю (по умолчанию)
  • Развертывание RDS настроено на «Использовать учетные данные шлюза удаленных рабочих столов для удаленных компьютеров» (по умолчанию) в свойствах шлюза удаленных рабочих столов.

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

Дополнительную информацию о развертывании VDI для служб удаленных рабочих столов см. в разделе Поддерживаемые конфигурации безопасности Windows 10 для VDI служб удаленных рабочих столов.

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

Вы можете использовать службы удаленных рабочих столов с прокси приложения Azure AD. Службы удаленных рабочих столов не поддерживают использование прокси-службы веб-приложения, которая включена в Windows Server 2016 и более ранние версии.

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

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

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

  1. В диспетчере серверов нажмите «Управление» > «Добавить серверы».
  2. Нажмите "Найти сейчас".
  3. Выберите каждый сервер в развертывании (например, Contoso-Cb1, Contoso-WebGw1 и Contoso-Sh1) и нажмите кнопку ОК.

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

  1. В диспетчере серверов нажмите «Управление» > «Добавить роли и компоненты».
  2. Нажмите «Установка служб удаленных рабочих столов», «Стандартное развертывание» и «Развертывание рабочего стола на основе сеанса».
  3. Выберите соответствующие серверы для сервера посредника подключений к удаленному рабочему столу, сервера веб-доступа к удаленному рабочему столу и сервера узла сеансов удаленных рабочих столов (например, Contoso-Cb1, Contoso-WebGw1 и Contoso-SH1 соответственно).
  4. Выберите Автоматический перезапуск целевого сервера, если требуется, а затем нажмите Развернуть.
  5. Дождитесь успешного завершения развертывания.

Добавить сервер лицензий удаленных рабочих столов:

  1. В диспетчере серверов выберите Службы удаленных рабочих столов > Обзор > Лицензирование +RD.
  2. Выберите виртуальную машину, на которой будет установлен сервер лицензий удаленных рабочих столов (например, Contoso-Cb1).
  3. Нажмите "Далее", а затем "Добавить".

Активируйте сервер лицензий удаленных рабочих столов и добавьте его в группу серверов лицензий:

  1. В диспетчере серверов щелкните Службы удаленных рабочих столов > Серверы. Щелкните правой кнопкой мыши сервер с установленной ролью лицензирования удаленных рабочих столов и выберите Диспетчер лицензирования удаленных рабочих столов.
  2. В диспетчере лицензирования удаленных рабочих столов выберите сервер и нажмите «Действие» > «Активировать сервер».
  3. Примите значения по умолчанию в мастере активации сервера. Продолжайте принимать значения по умолчанию, пока не дойдете до страницы информации о компании. Затем введите информацию о своей компании.
  4. Примите значения по умолчанию для остальных страниц до последней страницы. Снимите флажок «Начать установку лицензий» и нажмите «Готово».
  5. Нажмите «Действие» > «Просмотреть конфигурацию» > «Добавить в группу» > «ОК». Введите учетные данные пользователя в группе администраторов контроллера домена AAD и зарегистрируйтесь как SCP. Этот шаг может не работать, если вы используете доменные службы Azure AD, но вы можете игнорировать любые предупреждения или ошибки.

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

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

Если вы предоставляете и устанавливаете сертификаты из доверенного центра сертификации, выполните процедуры с шага h по шаг k для каждой роли. Вам потребуется файл .pfx для каждого из этих сертификатов.

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

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

  1. В диспетчере серверов выберите Службы удаленных рабочих столов > Обзор > Задачи > Изменить свойства развертывания.
  2. Разверните узел Шлюз удаленных рабочих столов и снимите флажок Обходить сервер шлюза удаленных рабочих столов для локальных адресов.
  3. Разверните раздел "Лицензирование удаленных рабочих столов" и выберите "На пользователя".
  4. Нажмите "ОК".

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

  1. В диспетчере серверов выберите Службы удаленных рабочих столов > Коллекции > Задачи > Создать коллекцию сеансов.
  2. Введите имя коллекции (например, ContosoDesktop).
  3. Выберите сервер узла сеансов удаленных рабочих столов (Contoso-Sh1), примите группы пользователей по умолчанию (Contoso\Domain Users) и введите путь универсального соглашения об именах (UNC) к созданным ранее дискам профилей пользователей (\Contoso-Cb1\ Пользовательские диски).
  4. Задайте максимальный размер и нажмите "Создать".

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

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

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

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

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

В этом примере мы уже установили на сервере роли узла сеансов удаленных рабочих столов (RDSH) и сервера лицензий удаленных рабочих столов. Этот сервер находится в режиме рабочей группы и не присоединен к домену. Приведенные ниже шаги используются для установки роли RDGW на один сервер (при установке RDGW также устанавливаются IIS), поэтому все три роли (RDSH, RDlic, RDGW) устанавливаются на один и тот же сервер. Если вы уже лицензируете RDS с помощью пользовательских лицензий RDS, установка роли шлюза удаленных рабочих столов не требует дополнительных затрат (кроме приобретения доверенного сертификата SSL).

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

    2. <р>2. Затем перейдите в «Диспетчер серверов», «Службы удаленных рабочих столов», «Серверы», щелкните имя сервера и щелкните правой кнопкой мыши свойства и «Диспетчер шлюза удаленных рабочих столов». (примечание: в обзоре RDS вы увидите сообщение о необходимости войти в систему как пользователь домена для управления серверами и коллекциями — для использования этой функции вам необходимо подключиться к домену, а не в режиме рабочей группы, мы продолжаем режим рабочей группы только ниже).

    <р>3. В диспетчере шлюза удаленных рабочих столов разверните дерево и перейдите к политикам. Создайте «Политику авторизации подключения» (CAP), для которой пользователи могут входить в шлюз, и «Политику авторизации ресурсов» (RAP) для того, какие ресурсы могут быть доступны. Например, мы создали политики с именами CAP1 и RAP1 и почти везде использовали значения по умолчанию. Для CAP1 вы, вероятно, захотите добавить пользователей и администраторов удаленного рабочего стола в «членство в группе пользователей». Для RAP1 в разделе «Сетевой ресурс» следует изменить выбор на «разрешить пользователям подключаться к любому ресурсу», поскольку это настройка одного сервера. Вы можете изменить эти политики позже, чтобы сделать их более конкретными и ограничительными.

    <р>4. Для сертификата SSL (вернитесь в Диспетчер шлюза удаленных рабочих столов, Свойства), создайте самозаверяющий сертификат, перейдя в свойства, вкладку SSL, создайте самозаверяющий сертификат, нажмите «Создать и импортировать сертификат», измените имя сертификата на IP-адрес. «xxx.xx.xxx.xx» сервера в поле имени сертификата. Скопируйте самоподписанный сертификат на свой локальный компьютер, потому что он понадобится вам для входа в систему через шлюз (он понадобится всем пользователям). Если вы используете доверенный сертификат SSL от CA, вам не нужно будет устанавливать самозаверяющий сертификат на каждый локальный ПК/клиент, как при использовании самозаверяющего сертификата. Обратите внимание на дату истечения срока действия самозаверяющего сертификата, который должен быть через 6 месяцев. Если вы решите продолжать использовать самозаверяющий сертификат, вам потребуется создать новый сертификат до истечения срока действия.

    Примечание. При использовании самозаверяющего сертификата вам потребуется установить сертификат на каждое клиентское устройство. Рекомендуется использовать доверенный сертификат (вместо самоподписанного сертификата), где вам потребуется приобрести сертификат SSL у такой компании, как GoDaddy, и он будет на имя URL/домена вместо IP-адреса.

    <р>5. На этом этапе все элементы в статусе диспетчера шлюза удаленных рабочих столов должны отображаться в виде зеленых/зеленых флажков.

    <р>6. Перейдите в раздел «Службы» и измените службу шлюза удаленных рабочих столов (имя службы — TSGateway) на тип запуска «автоматический» вместо «автоматический (отложенный)» и убедитесь, что она запущена/работает. Это позволит службе шлюза запускаться быстрее после перезагрузки сервера, иначе вы можете получить сообщение о том, что служба шлюза недоступна при попытке входа в систему, пока вы не подождите несколько минут, пока служба не запустится.

    Подключение к RDGW с локального ПК

    1. 7Откройте клиент подключения к удаленному рабочему столу на локальном ПК и разверните все поле, щелкнув параметры показа.
    2. На вкладке "Общие" убедитесь, что в поле имени компьютера указан IP-адрес сервера. Вы будете вводить IP-адрес как на вкладке «Общие», так и на вкладке «Дополнительно», используя один и тот же IP-адрес, поскольку в этом примере сервер RDSH и сервер RDGW — это один и тот же сервер.
    3. Перед подключением перейдите на вкладку "Дополнительно".
    4. Нажмите на поле "Настройки" в разделе "Подключение откуда угодно".
    5. Выберите «использовать эти настройки шлюза».
    6. Введите IP-адрес сервера в качестве имени сервера
    7. Снимите флажок "Обходить сервер шлюза удаленных рабочих столов для локальных адресов"
    8. Установите флажок, чтобы использовать те же учетные данные для сервера шлюза удаленных рабочих столов и удаленного компьютера, что и в этом примере.
    9. Нажмите «ОК», вернитесь на вкладку «Локальные ресурсы» и выберите, какие локальные устройства следует перенаправить (обычно принтеры и буфер обмена должны быть перенаправлены, но не локальные диски под кнопкой «Дополнительно» — перенаправление локальных дисков использует пропускную способность/ресурсы, поэтому делайте это только тогда, когда нужно)
    10. Перейдите на вкладку "Общие", решите, хотите ли вы разрешить сохранение учетных данных, и сохраните настроенный файл rdp в виде ярлыка на рабочем столе, нажав "Сохранить как" и дав ему подходящее имя.
    11. При подключении вы можете сначала получить предупреждающее сообщение, в котором говорится: "Не удается определить издателя этого удаленного подключения. Вы все равно хотите подключиться? ИЛИ «Идентификация удаленного компьютера не может быть проверена. Вы все равно хотите подключиться?» Вы можете установить флажок «Больше не спрашивать меня о подключениях к этому компьютеру», если вы не хотите видеть это сообщение каждый раз, и продолжить. Это сообщение обычно появляется из-за того, что вы используете ярлык RDP на локальном рабочем столе, который вы настроили, или потому что вы используете самозаверяющий сертификат.
    12. Подключитесь, и вы получите сообщение о необходимости ввести свои учетные данные, которые будут использоваться как для RDSH, так и для RDGW, выберите, следует ли запоминать учетные данные или нет.
    13. Если при попытке подключения появляется сообщение "Этому компьютеру не удается проверить подлинность шлюза удаленных рабочих столов XXXXX..." и он не будет подключаться, это потому, что вы используете самозаверяющий сертификат и не поместили копию сертификата в доверенные корневые центры сертификации на вашем локальном ПК. Итак, вернитесь на сервер и скопируйте сертификат из папки users\username\documents\certname.cer сервера на локальный ПК/рабочий стол, затем дважды щелкните его на локальном ПК, выберите «установить сертификат» и выберите «Локальный компьютер». ” сохранить местоположение и выберите это конкретное местоположение «Доверенные корневые центры сертификации» (не выполняйте автоматическое определение местоположения). ЭТО НЕОБХОДИМО СДЕЛАТЬ НА ВСЕХ ЛОКАЛЬНЫХ ПК, ЧТОБЫ ПОДКЛЮЧИТЬСЯ ПРИ ИСПОЛЬЗОВАНИИ САМОПОДПИСАННЫХ СЕРТИФИКАТОВ.
    14. Если у вас возникли проблемы со входом в систему, попробуйте ввести имя пользователя в виде имя_сервера\имя_пользователя, то есть WIN-XXXXXX\Administrator или ServerX\Dan и т. д.

      15. Отключите порт 3389 для подключения к Интернету, чтобы заставить трафик использовать порт 443/RDGW

      1. Затем отключите четыре входящих правила брандмауэра Windows для удаленного рабочего стола для порта 3389 ДЛЯ ОБЩЕСТВЕННОГО ПРОФИЛЯ (удаленный рабочий стол — режим пользователя (TCP-In) и (UDP-In) и службы удаленных рабочих столов — режим пользователя (TCP-In). ) и (UDP-In). Нажмите на правило брандмауэра, перейдите на вкладку "Дополнительно" и снимите флажок "Общий", чтобы правило не применялось к общедоступному профилю.
      2. Трафик RDP затем должен проходить через порт 443 извне на сервер, а затем через порт 3389 внутрь сервера. Вы можете проверить это, попробовав войти через RDP без настроек шлюза.
      3. При необходимости вы также можете изменить/отключить другие правила брандмауэра для входящих подключений к удаленному рабочему столу.

        4. Читайте также: