Поделиться через


Устранение неполадок RDP Shortpath для общедоступных сетей

Важно!

Использование RDP Shortpath для общедоступных сетей с TURN для Виртуального рабочего стола Azure в настоящее время находится в предварительной версии. Юридические условия, применимые к функциям Azure, которые находятся в состоянии бета-версии, предварительной версии или иным образом еще не выпущены в общедоступной версии, см. на странице Дополнительные условия использования предварительных версий в Microsoft Azure.

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

Проверка подключения сервера STUN/TURN и типа NAT

Вы можете проверить подключение к конечным точкам STUN/TURN и убедиться, что базовые функции UDP работают, запустив исполняемый файл avdnettest.exe. Ниже приведена ссылка для скачивания последней версии avdnettest.exe.

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

Checking DNS service ... OK
Checking TURN support ... OK
Checking ACS server 20.202.68.109:3478 ... OK
Checking ACS server 20.202.21.66:3478 ... OK

You have access to TURN servers and your NAT type appears to be 'cone shaped'.
Shortpath for public networks is very likely to work on this host.

Важно!

В предварительной версии функция TURN доступна только для подключений к узлам сеансов в пуле узлов проверки. Сведения о настройке пула узлов в качестве среды проверки см. в статье Определение пула узлов в качестве среды проверки.

Сведения об ошибках, зарегистрированные в Log Analytics

Ниже приведены некоторые заголовки ошибок, которые вы можете увидеть в журнале Log Analytics, и их значение.

ShortpathTransportNetworkDrop

Для TCP мы различаем два разных пути : узел сеансов к шлюзу и шлюз к клиенту, но это не имеет смысла для UDP, так как шлюза нет. Другое отличие tcp заключается в том, что во многих случаях одна из конечных точек или, возможно, какая-либо инфраструктура в середине, создает пакет сброса TCP (бит управления RST), что приводит к жесткому завершению TCP-подключения. Это работает, так как TCP RST (а также TCP FIN для корректного завершения работы) обрабатывается операционной системой и некоторыми маршрутизаторами, но не приложением. Это означает, что в случае сбоя приложения Windows уведомит одноранговый узел о том, что TCP-подключение отсутствует, но такого механизма для UDP не существует.

Большинство ошибок подключения, таких как ConnectionFailedClientDisconnect и ConnectionFailedServerDisconnect, вызваны пакетами сброса TCP, а не истечением времени ожидания. Операционная система или маршрутизатор не могут сообщить что-либо с помощью UDP, поэтому единственный способ узнать, что одноранговый узел исчез, — это сообщение об истечении времени ожидания.

ShortpathTransportReliabilityThresholdFailure

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

  1. Соединение было очень быстрым и стабильным, прежде чем оно вдруг перестало работать. Время ожидания, необходимое до объявления потерянного пакета, зависит от времени кругового пути (RTT) между клиентом и узлом сеансов. Если rtt очень низкий, одна из сторон может попытаться отправить пакет повторно очень часто, поэтому время, необходимое для достижения 50 попыток, может быть меньше, чем обычное время ожидания 17 секунд.

  2. Пакет очень большой. Максимальный размер передаваемого пакета ограничен. Размер пакета проверяется, но он может меняться, а иногда и уменьшаться. Если это произойдет, возможно, что отправляемый пакет будет слишком большим и будет постоянно завершаться ошибкой.

ConnectionBrokenMissedHeartbeatThresholdExceededed

Это время ожидания на уровне RDP. Из-за неправильной настройки время ожидания на уровне RDP иногда активируется до истечения времени ожидания уровня UDP.