Résoudre des problèmes RDP Shortpath pour les réseaux publics
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.
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 :
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.
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.