RDP Shortpath для Виртуального рабочего стола Azure
Статья
RDP Shortpath устанавливает прямой транспорт на основе UDP между локальным приложением Windows или приложением удаленного рабочего стола на поддерживаемых платформах и узле сеансов в Виртуальном рабочем столе Azure.
По умолчанию протокол удаленного рабочего стола (RDP) пытается установить удаленный сеанс с помощью UDP и использует транспорт обратного подключения на основе TCP в качестве резервного механизма подключения. Транспорт на основе UDP обеспечивает более высокую надежность подключения и более согласованную задержку. Транспорт обратного подключения на основе TCP обеспечивает лучшую совместимость с различными конфигурациями сети и имеет высокую скорость успешного установления подключений RDP.
RDP Shortpath можно использовать двумя способами:
Управляемые сети, в которых прямое соединение между клиентом и узлом сеансов устанавливается с использованием частного подключения, например, виртуальной частной сети (VPN). Подключение с помощью управляемой сети устанавливается одним из следующих способов:
Прямое подключение UDP между клиентским устройством и узлом сеанса, где необходимо включить прослушиватель RDP Shortpath и разрешить входящий порт на каждом узле сеанса принимать подключения.
Прямое подключение UDP между клиентским устройством и узлом сеанса с помощью протокола Simple Traversal Underneath NAT (STUN) между клиентом и узлом сеанса. Входящие порты на узле сеанса не требуются.
Общедоступные сети, где устанавливается прямое подключение между клиентом и узлом сеанса при использовании общедоступного подключения. При использовании общедоступного подключения существует два типа подключения, перечисленные здесь в порядке предпочтения:
Прямое подключение UDP с помощью протокола Simple Traversal Underneath NAT (STUN) между клиентом и узлом сеанса.
Непрямое подключение UDP с помощью протокола NAT ретрансляции (TURN) с ретранслятором между клиентом и узлом сеанса.
В основе транспорта RDP Shortpath лежит протокол URCP. Протокол URCP расширяет возможности протокола UDP за счет активного мониторинга состояния сети и обеспечивает надлежащее и полное использование ссылок. URCP обеспечивает низкую задержку и низкий уровень потерь в соответствии с требованиями.
Внимание
RDP Shortpath для общедоступных сетей с TURN доступен только в общедоступном облаке Azure.
Ключевые преимущества
Использование RDP Shortpath имеет следующие ключевые преимущества:
Использование протокола URCP для улучшения характеристик протокола UDP обеспечивает наилучшую производительность за счет динамического определения параметров сети и предоставления механизма управления скоростью.
Отказ от использования дополнительных точек ретрансляции сокращает время кругового пути, что повышает надежность подключения и удобство работы пользователей с приложениями и методами ввода, чувствительными к задержкам.
Кроме того, RDP Shortpath предоставляет следующие преимущества для управляемых сетей:
RDP Shortpath обеспечивает поддержку приоритета настройки качества обслуживания (QoS) для подключений RDP с помощью меток DSCP.
Транспорт RDP Shortpath позволяет ограничивать исходящий сетевой трафик путем указания частоты регулирования для каждого сеанса.
Как работает RDP Shortpath
Чтобы получить сведения о том, как RDP Shortpath работает в случае управляемых сетей и общедоступных сетей, перейдите на соответствующую вкладку.
VPN типа "сеть — сеть" или "точка — сеть" (IPsec), например, VPN-шлюз Azure.
Прямое соединение означает, что клиент может подключаться непосредственно к узлу сеансов и не блокируется брандмауэром.
Примечание.
Если для подключения к Azure задействуются другие типы VPN-подключений, рекомендуется использовать VPN-подключение на основе UDP. Большинство VPN-решений на основе протокола TCP поддерживает вложенные протоколы UDP, однако они используют дополнительные наследуемые служебные операции для управления перегрузкой TCP, что снижает производительность RDP.
Чтобы использовать RDP Shortpath для управляемых сетей, необходимо включить прослушиватель UDP на узлах сеансов. По умолчанию используется порт 3390, но можно использовать и другой порт.
На следующей схеме представлен общий обзор сетевых подключений при использовании RDP Shortpath для управляемых сетей и узлов сеансов, присоединенных к домену Active Directory.
Последовательность подключений
Все подключения начинаются с установки транспорт с обратным подключением на основе TCP через шлюз Виртуального рабочего стола Azure. Затем клиент и узел сеансов устанавливают начальный транспорт RDP и начинают обмениваться своими возможностями. Эти возможности согласовываются с помощью следующего процесса:
Узел сеанса отправляет клиенту список IPv4- и IPv6-адресов.
Клиент запускает фоновый поток для установки параллельного транспортного подключения основе UDP напрямую на один из IP-адресов узла сеансов.
Пока клиент выполняет проверку предоставленных IP-адресов, он продолжает устанавливать начальное подключение через транспорт с обратным подключением, чтобы не допустить задержки в подключении пользователя.
Если клиент имеет прямое подключение к узлу сеанса, клиент устанавливает безопасное подключение с помощью TLS через надежный UDP.
После установки транспорта RDP Shortpath все динамические виртуальные каналы (DVC), включая удаленную графику, входные данные и перенаправление устройств, перемещаются в новый транспорт. Однако если брандмауэр или топология сети не позволяют клиенту устанавливать прямое соединение по протоколу UDP, RDP продолжит работать с транспортом с обратным подключением.
Если у пользователей есть RDP Shortpath для управляемой сети и общедоступных сетей, то будет использоваться первый найденный алгоритм. Пользователь будет использовать любое соединение, установленное первым для этого сеанса.
Чтобы обеспечить лучший шанс успешного подключения UDP при использовании общедоступного подключения, существуют типы прямых и косвенных подключений:
Прямое подключение: STUN используется для установления прямого подключения UDP между клиентом и узлом сеанса. Чтобы установить это подключение, узел клиента и сеанса должен иметь возможность подключаться друг к другу через общедоступный IP-адрес и согласованный порт. Однако большинство клиентов не знают собственный общедоступный IP-адрес, так как они сидят за устройством шлюза преобразования сетевых адресов (NAT ). STUN — это протокол для самостоятельного обнаружения общедоступного IP-адреса за устройством шлюза NAT и клиентом, чтобы определить собственный общедоступный IP-адрес.
Для использования STUN клиент должен разрешить трафик UDP. При условии, что узел клиента и сеанса может направляться непосредственно на обнаруженный IP-адрес и порт другого, обмен данными устанавливается с прямым UDP через протокол WebSocket. Если брандмауэры или другие сетевые устройства блокируют прямые подключения, будет предпринята попытка непрямого подключения UDP.
Косвенное подключение: TURN используется для установления косвенного подключения, ретрансляция трафика через промежуточный сервер между клиентом и узлом сеанса, если прямое подключение невозможно. TURN — это расширение STUN. Использование TURN означает, что общедоступный IP-адрес и порт известны заранее, что может быть разрешено через брандмауэры и другие сетевые устройства.
TURN обычно разрешает доступ к серверу с помощью имени пользователя или пароля, а его предпочтительный режим работы — использовать сокеты UDP. Если брандмауэры или другие сетевые устройства блокируют трафик UDP, подключение вернется к транспорту обратного подключения на основе TCP.
При установке подключения интерактивное создание подключений (ICE) координирует управление STUN и TURN для оптимизации вероятности установки подключения и гарантирует, что приоритет предоставляется предпочтительному сетевому протоколу связи.
Каждый сеанс RDP использует динамически назначенный UDP-порт из временного диапазона портов (49152 до 6535 по умолчанию), который принимает трафик RDP Shortpath. Порт 65330 игнорируется из этого диапазона, так как он зарезервирован для внутреннего использования в Azure. Также можно использовать меньший, лучше прогнозируемый диапазон портов. Дополнительные сведения см. в разделе Ограничение диапазона портов, используемого клиентами для общедоступных сетей.
Совет
RDP Shortpath для общедоступных сетей будет работать автоматически без дополнительной настройки, если сети и брандмауэры разрешают прохождение трафика, а для параметров транспорта RDP в операционной системе Windows для узлов сеансов и клиентов используются значения по умолчанию.
На следующей схеме представлен общий обзор сетевых подключений при использовании RDP Shortpath для общедоступных сетей, где узлы сеансов присоединены к идентификатору Microsoft Entra.
Преобразование сетевых адресов и брандмауэры
Большинство клиентов Виртуального рабочего стола Azure работают на компьютерах в частной сети. Доступ к Интернету предоставляется через устройство шлюза преобразования сетевых адресов (NAT). Таким образом, шлюз NAT изменяет все сетевые запросы из частной сети и предназначен для Интернета. Такое изменение намеренно для совместного использования одного общедоступного IP-адреса на всех компьютерах в частной сети.
Из-за изменения IP-пакета получатель трафика увидит общедоступный IP-адрес шлюза NAT вместо фактического отправителя. Когда трафик возвращается к шлюзу NAT, последний позаботится о переадресации его предполагаемому получателю без знания отправителя. В большинстве случаев устройства, скрытые за таким NAT, не знают, что имеет место преобразование и не знают сетевой адрес шлюза NAT.
Преобразование NAT может быть применено к виртуальным сетям Azure, в которых находятся все узлы сеансов. Когда узел сеанса пытается связаться с сетевым адресом в Интернете, шлюз NAT (ваш собственный или предоставленный Azure по умолчанию) или подсистема балансировки нагрузки Azure выполняют преобразование адресов. Дополнительные сведения о различных типах преобразования исходных сетевых адресов см. в разделе Использование преобразования исходных сетевых адресов (SNAT) для исходящих подключений.
Большинство сетей обычно включают брандмауэры, которые проверяют трафик и блокируют его на основе правил. Большинство клиентов настраивают брандмауэры для предотвращения входящих подключений (то есть незапрошенных пакетов из Интернета, отправленных без запроса). Брандмауэры используют различные методы отслеживания потока данных для различения запрашиваемого и незапрошенного трафика. В контексте TCP брандмауэр отслеживает пакеты SYN и ACK, а процесс довольно прост. Брандмауэры UDP обычно используют эвристику на основе адресов пакетов для связывания трафика с потоками UDP и соответственного разрешения или блокировки.
Существует множество различных реализаций преобразования NAT. В большинстве случаев шлюз NAT и брандмауэр являются функциями одного физического или виртуального устройства.
Последовательность подключений
Все подключения начинаются с установки транспорт с обратным подключением на основе TCP через шлюз Виртуального рабочего стола Azure. Затем клиент и узел сеансов устанавливают начальный транспорт RDP и начинают обмениваться своими возможностями. Если RDP Shortpath для общедоступных сетей включен на узле сеансов, узел сеансов инициирует процесс, который называется сбор кандидатов.
Узел сеансов перечисляет все сетевые интерфейсы, назначенные узлу сеансов, включая виртуальные интерфейсы, такие как VPN и Teredo.
Служба удаленных рабочих столов Windows (TermService) выделяет сокеты UDP для каждого интерфейса и сохраняет пару IP-адрес:порт в таблице кандидатов в качестве локального кандидата.
Служба удаленных рабочих столов использует каждый сокет UDP, выделенный на предыдущем шаге, чтобы попытаться достичь STUN-сервера Виртуального рабочего стола Azure в общедоступном Интернете. Обмен данными осуществляется путем отправки небольшого пакета UDP на порт 3478.
Если пакет достигает STUN-сервера, сервер STUN отвечает с общедоступным IP-адресом и портом. Эти сведения хранятся в таблице кандидатов в качестве рефлексивного кандидата.
После того, как узел сеанса собирает всех кандидатов, узел сеансов использует установленный транспорт с обратным подключением для передачи списка кандидатов клиенту.
Когда клиент получает список кандидатов от узла сеансов, клиент также выполняет сбор кандидатов на своей стороне. Затем клиент отправляет список кандидатов на узел сеанса.
После обмена списками кандидатов между узлом сеансов и клиентом обе стороны пытаются связаться друг с другом, используя все собранные кандидаты. Эта попытка подключения выполняется одновременно с обеих сторон. Многие шлюзы NAT настроены так, чтобы разрешить входящий трафик к сокету сразу после его инициализации исходящей передачей данных. Такое поведение шлюзов NAT является причиной необходимости одновременного подключения. Если STUN завершается ошибкой, так как она заблокирована, с помощью TURN выполняется непрямая попытка подключения.
После первоначального обмена пакетами клиент и узел сеансов могут установить один или несколько потоков данных. В этих потоках данных RDP выбирает самый быстрый сетевой путь. Затем клиент устанавливает безопасное подключение с помощью TLS через надежный UDP с узлом сеанса и инициирует транспорт RDP Shortpath.
После того, как RDP устанавливает транспорт RDP Shortpath, все динамические виртуальные каналы (DVC), включая удаленную графику, входные данные и перенаправление устройств, перемещаются в новый транспорт.
Если у ваших пользователей есть RDP Shortpath для управляемой сети и общедоступных сетей, то будет использоваться первый найденный алгоритм, то есть пользователь будет использовать любое подключение, установленное первым для этого сеанса. Дополнительные сведения см . в примере сценария 4.
Внимание
При использовании транспорта на основе TCP исходящий трафик от узла сеансов к клиенту направляется через шлюз Виртуального рабочего стола Azure. При использовании RDP Shortpath для общедоступных сетей с помощью STUN исходящий трафик устанавливается непосредственно между узлом сеансов и клиентом через Интернет. При этом исключается прыжок, что уменьшает задержку и улучшает взаимодействие с конечным пользователем. Однако из-за изменений в потоке данных между узлом сеансов и клиентом, в результате которых шлюз перестает использоваться, в дополнение к плате за подписку для используемой пропускной способности Интернета будет взиматься стандартная плата за исходящий сетевой трафик Azure. Дополнительные сведения об оценке пропускной способности, используемой RDP, см. в разделе Требования к пропускной способности RDP.
Сетевая конфигурация
Для поддержки RDP Shortpath для общедоступных сетей обычно не требуется определенная конфигурация. Узел сеансов и клиент автоматически обнаруживают прямой поток данных, если он возможен в конфигурации сети. Однако каждая среда уникальна, а некоторые конфигурации сети могут негативно повлиять на скорость успешного прямого подключения. Следуйте рекомендациям, чтобы увеличить вероятность прямого потока данных.
Так как RDP Shortpath использует UDP для установления потока данных, то в случае блокировки трафика UDP брандмауэром в сети работа RDP Shortpath завершится сбоем и подключение перейдет к транспорту с обратным подключением на основе TCP. Виртуальный рабочий стол Azure использует серверы STUN, предоставляемые Службами коммуникации Azure и Microsoft Teams. По сути функции требуется исходящее подключение между узлами сеансов и клиентом. К сожалению, в большинстве случаев невозможно предсказать, где находятся пользователи. Поэтому рекомендуется разрешить исходящее подключение UDP от узлов сеансов к Интернету. Чтобы уменьшить необходимое количество портов, можно ограничить диапазон портов, используемый клиентами для потока UDP. При настройке брандмауэров для RDP Shortpath используйте следующую таблицу в качестве справки.
Если в вашей среде используется симметричный NAT, который является сопоставлением одного частного исходного IP-адреса:Port с уникальным общедоступным IP-адресом назначения:Port, можно использовать косвенное соединение с TURN. Это будет так, если вы используете Брандмауэр Azure и шлюз Azure NAT. Дополнительные сведения о NAT с виртуальными сетями Azure см. в разделе Преобразование исходных сетевых адресов с помощью виртуальных сетей.
Где пользователи имеют RDP Shortpath для управляемой сети и общедоступных сетей, доступны для них, то будет использоваться первый алгоритм. Пользователь будет использовать любое соединение, установленное первым для этого сеанса. Дополнительные сведения см. в примерах сценариев.
Хотя протокол Teredo не обязателен для RDP Shortpath, он добавляет дополнительные обходные кандидаты NAT и повышает вероятность успешного подключения RDP Shortpath в сетях, где используется только IPv4. Сведения о включении Teredo на узлах сеансов и клиентах см. в статье "Включение поддержки Teredo".
Поддержка UPnP
Чтобы повысить вероятность прямого подключения, на стороне клиента удаленного рабочего стола RDP Shortpath может использовать UPnP для настройки сопоставления портов на маршрутизаторе NAT. UPnP — это стандартная технология, используемая различными приложениями, такими как Xbox, оптимизация доставки и Teredo. Протокол UPnP обычно доступен на маршрутизаторах, которые находятся в домашней сети. UPnP включен по умолчанию для большинства домашних маршрутизаторов и точек доступа, но часто отключен в корпоративной сети.
Общие рекомендации
Ниже приведены некоторые общие рекомендации при использовании RDP Shortpath для общедоступных сетей:
Избегайте использования конфигураций принудительного туннелирования, если пользователи получают доступ к Виртуальному рабочему столу Azure через Интернет.
Убедитесь, что вы не используете конфигурации двойного NAT или Carrier-Grade-NAT (CGN).
Порекомендуйте пользователям не отключать UPnP на домашних маршрутизаторах.
Избегайте использования облачных служб проверки пакетов.
Избегайте использования решений VPN на основе TCP.
Включите соединение IPv6 или Teredo.
Безопасность подключения
RDP Shortpath расширяет возможности мультитранспортных подключений по протоколу RDP. Он не заменяет транспорт с обратным подключением, а дополняет его. Управление всеми функциями первоначального посредничества в сеансах осуществляется с помощью службы Виртуального рабочего стола Azure и транспорта с обратным подключением. Все попытки подключения будут проигнорированы, если они не соответствуют сеансу с обратным подключением. Транспорт RDP Shortpath устанавливается после проверки подлинности и, если он установлен успешно, то транспорт с обратным подключением удаляется и весь трафик направляется через RDP Shortpath.
RDP Shortpath использует безопасное подключение с помощью TLS через надежный UDP между клиентом и узлом сеанса с помощью сертификатов узла сеанса. По умолчанию сертификат, используемый для шифрования RDP, автоматически создается операционной системой во время развертывания. Вы также можете развертывать централизованно управляемые сертификаты, выданные центром сертификации предприятия. Дополнительные сведения о конфигурациях сертификатов см. в разделе Конфигурации сертификатов прослушивателя удаленных рабочих столов.
Ниже приведены некоторые примеры сценариев, в которых показано, как оцениваются подключения, чтобы определить, используется ли RDP Shortpath в разных топологиях сети.
Сценарий 1
Подключение UDP можно установить только между клиентским устройством и узлом сеанса через общедоступную сеть (Интернет). Прямое подключение, например VPN, недоступно. UDP разрешен через брандмауэр или устройство NAT.
Сценарий 2
Брандмауэр или устройство NAT блокирует прямое подключение UDP, но непрямое подключение UDP можно ретранслировать с помощью TURN между клиентским устройством и узлом сеанса через общедоступную сеть (Интернет). Другое прямое подключение, например VPN, недоступно.
Сценарий 3
Подключение UDP можно установить между клиентским устройством и узлом сеанса через общедоступную сеть или через прямое VPN-подключение, но RDP Shortpath для управляемых сетей не включен. Когда клиент инициирует подключение, протокол ICE/STUN может видеть несколько маршрутов и будет оценивать каждый маршрут и выбирать его с наименьшей задержкой.
В этом примере подключение UDP с помощью RDP Shortpath для общедоступных сетей через прямое VPN-подключение будет выполнено, так как оно имеет наименьшую задержку, как показано зеленой строкой.
Сценарий 4
Включены RDP Shortpath для общедоступных сетей и управляемых сетей. Подключение UDP можно установить между клиентским устройством и узлом сеанса через общедоступную сеть или через прямое VPN-подключение. Когда клиент инициирует подключение, существуют одновременные попытки подключения с помощью RDP Shortpath для управляемых сетей через порт 3390 (по умолчанию) и RDP Shortpath для общедоступных сетей через протокол ICE/STUN. Будет использоваться первый найденный алгоритм, и пользователь будет использовать любое соединение, установленное первым для этого сеанса.
Так как переход по общедоступной сети имеет больше шагов, например устройство NAT, подсистема балансировки нагрузки или сервер STUN, скорее всего, первый найденный алгоритм выберет подключение с помощью RDP Shortpath для управляемых сетей и сначала будет установлен.
Сценарий 5
Подключение UDP можно установить между клиентским устройством и узлом сеанса через общедоступную сеть или через прямое VPN-подключение, но RDP Shortpath для управляемых сетей не включен. Чтобы предотвратить использование определенного маршрута ICE/STUN, администратор может заблокировать один из маршрутов для трафика UDP. Блокировка маршрута гарантирует, что оставшийся путь всегда используется.
В этом примере UDP блокируется на прямом VPN-подключении, а протокол ICE/STUN устанавливает подключение через общедоступную сеть.
Сценарий 6.
RDP Shortpath для общедоступных сетей и управляемых сетей настроены, однако не удалось установить подключение UDP с помощью прямого VPN-подключения. Брандмауэр или устройство NAT также блокирует прямое подключение UDP с помощью общедоступной сети (Интернет), но косвенное подключение UDP можно ретранслировать с помощью TURN между клиентским устройством и узлом сеанса через общедоступную сеть (Интернет).
Сценарий 7.
RDP Shortpath для общедоступных сетей и управляемых сетей настроены, однако не удалось установить подключение UDP. В этом экземпляре RDP Shortpath завершится ошибкой, и подключение вернется к транспорту обратного подключения на основе TCP.