Résoudre des problèmes RDP Shortpath pour les réseaux publics

Important

Pour l’instant, l’utilisation de la fonctionnalité RDP Shortpath pour les réseaux publics avec TURN pour Azure Virtual Desktop est en PRÉVERSION. Pour connaître les conditions juridiques qui s’appliquent aux fonctionnalités Azure en version bêta, en préversion ou plus généralement non encore en disponibilité générale, consultez l’Avenant aux conditions d’utilisation des préversions de Microsoft Azure.

Si vous rencontrez des problèmes lors de l’utilisation de RDP Shortpath pour les réseaux publics, utilisez les informations de cet article pour vous aider à résoudre les problèmes.

Vérification de la connectivité du serveur STUN/TURN et du type NAT

Vous pouvez valider la connectivité aux points de terminaison STUN/TURN et vérifier que la fonctionnalité UDP de base fonctionne en utilisant l’exécutable avdnettest.exe. Voici un lien de téléchargement vers la dernière version de avdnettest.exe.

Vous pouvez exécuter avdnettest.exe double-cliquant sur le fichier ou en l’exécutant à partir de la ligne de commande. La sortie ressemble à ceci lorsque la connectivité réussit :

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.

Important

Pendant la préversion, TURN est disponible uniquement pour les connexions aux hôtes de session dans un pool d’hôtes de validation. Pour configurer votre pool d’hôtes en tant qu’environnement de validation, consultez Définir votre pool d’hôtes en tant qu’environnement de validation.

Informations sur les erreurs journalisées dans Log Analytics

Voici quelques titres d’erreur que vous pouvez voir journalisés dans Log Analytics et ce qu’ils signifient.

ShortpathTransportNetworkDrop

Pour TCP, nous distinguons deux chemins différents : l’hôte de session vers la passerelle et la passerelle vers le client, mais cela n’a pas de sens pour UDP car il n’existe pas de passerelle. L’autre distinction pour TCP est que, dans de nombreux cas, l’un des points de terminaison, ou peut-être une infrastructure au milieu, génère un paquet de réinitialisation TCP (bit de contrôle RST), ce qui provoque un arrêt forcé de la connexion TCP. Cela fonctionne parce que TCP RST (et également TCP FIN pour un arrêt approprié) est géré par le système d’exploitation et certains routeurs, mais pas par l’application. Cela signifie que lorsqu’une application se bloque, Windows informe l’homologue que la connexion TCP a disparu, mais qu’il n’existe aucun mécanisme de ce type pour UDP.

La plupart des erreurs de connexion, telles que ConnectionFailedClientDisconnect et ConnectionFailedServerDisconnect sont dues à des paquets de réinitialisation TCP, et non à un délai d’expiration. Il n’y a aucun moyen pour le système d’exploitation ou un routeur de signaler quoi que ce soit avec UDP. La seule façon de savoir que l’homologue a disparu est donc via un message de délai d’expiration.

ShortpathTransportReliabilityThresholdFailure

Cette erreur est déclenchée si un paquet spécifique ne passe pas, même si la connexion n’est pas morte. Le paquet étant renvoyé jusqu’à 50 fois, il est peu probable, mais peut se produire, dans les scénarios suivants :

  1. La connexion était très rapide et stable avant qu’elle cesse soudainement de fonctionner. Le délai d’expiration requis jusqu’à ce qu’un paquet soit déclaré perdu dépend du temps d’aller-retour (RTT) entre le client et l’hôte de session. Si le RTT est très faible, un côté peut essayer de renvoyer un paquet de manière très fréquente, de sorte que le temps nécessaire pour atteindre 50 tentatives peut être inférieur à la valeur de délai d’expiration habituelle de 17 secondes.

  2. Le paquet est très volumineux. La taille maximale des paquets pouvant être transmis est limitée. La taille du paquet est sondée, mais elle peut varier et parfois diminuer. Si cela se produit, il est possible que le paquet envoyé soit trop volumineux et échoue constamment.

ConnectionBrokenMissedHeartbeatThresholdExceeded

Il s’agit d’un délai d’expiration de niveau RDP. En raison d’une configuration incorrecte, le délai d’expiration du niveau RDP se déclenche parfois avant le délai d’expiration au niveau UDP.