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

Article
01/22/2025

Cet article vous aide à résoudre les problèmes liés à l’utilisation de RDP (Remote Desktop Protocol) Shortpath pour les réseaux publics.

Vérifier la connectivité du serveur STUN, TURN et le type NAT

Vous pouvez valider la connectivité aux points de terminaison STUN et TURN, et vérifier que la fonctionnalité UDP (User Datagram Protocol) de base fonctionne en exécutant le avdnettest.exe exécutable. Voici un lien de téléchargement vers la dernière version de avdnettest.exe.

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

Checking DNS service ... OK
Checking TURN support ... OK
Checking ACS server <IP Address:Port Number> ... OK
Checking ACS server <IP Address:Port Number> ... 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.

Informations sur les erreurs journalisées dans Log Analytics

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

ShortpathTransportNetworkDrop

Pour les connexions TCP (Transmission Control Protocol), il existe deux chemins d’accès différents :

De l’hôte de session à la passerelle
De la passerelle au client

Toutefois, pour les connexions UDP, cette différence n’est pas applicable, car aucune passerelle n’est impliquée. 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 si une application se bloque, Windows avertit l’homologue que la connexion TCP est supprimée, mais aucun mécanisme de ce type n’existe pour UDP.

La plupart des erreurs de connexion, telles que ConnectionFailedClientDisconnect et ConnectionFailedServerDisconnect, sont provoquées par des paquets de réinitialisation TCP, et non par un délai d’attente. Il n’existe 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 est parti est passée par un message de délai d’attente.

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 :

La connexion est rapide et stable avant qu’elle cesse soudainement de fonctionner. Le délai d’attente nécessaire jusqu’à ce qu’un paquet soit déclaré perdu dépend de l’heure d’aller-retour (RTT) entre le client et l’hôte de session. Si le RTT est faible, un côté peut essayer de renvoyer un paquet fréquemment, de sorte que le temps nécessaire pour atteindre 50 tentatives peut être inférieur à la valeur de délai d’attente habituelle de 17 secondes.
Le paquet est 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’attente au niveau RDP. En raison d’une configuration incorrecte, le délai d’expiration au niveau RDP se déclenche parfois avant le délai d’expiration au niveau UDP.

Partage via