RDP Shortpath établit un transport basé sur UDP entre un appareil local, l’application application Windows ou l’application Bureau à distance sur les plateformes et l’hôte de session pris en charge dans Azure Virtual Desktop. Par défaut, le protocole RDP (Bureau à distance Protocol) commence un transport de connexion inverse basé sur TCP, puis tente d’établir une session à distance à l’aide de UDP. Si la connexion UDP réussit, la connexion TCP tombe. Sinon, la connexion TCP est utilisée comme mécanisme de connexion de secours.
Le transport basé sur UDP offre une meilleure fiabilité de connexion et une latence plus constante. Le port de connexion inverse basé sur TCP offre la meilleure compatibilité avec diverses configurations réseau et a un taux de réussite élevé pour l’établissement de connexions RDP.
RDP Shortpath peut être utilisé de deux manières :
Les réseaux managés, dans lesquels une connectivité directe est établie entre le client et l’hôte de session lorsque vous utilisez une connexion privée, telle qu’Azure ExpressRoute ou un réseau privé virtuel (VPN) site à site. Une connexion à l’aide d’un réseau managé est établie de l’une des manières suivantes :
Connexion UDP directe entre l’appareil client et l’hôte de session, où vous devez activer l’écouteur RDP Shortpath et autoriser un port entrant sur chaque hôte de session à accepter les connexions.
Connexion UDP directe entre l’appareil client et l’hôte de session, à l’aide du protocole STUN (Simple Traversal Underneath NAT) entre un client et un hôte de session. Les ports entrants sur l’hôte de session ne doivent pas être autorisés.
Réseaux publics, où une connectivité directe est établie entre le client et l’hôte de session lors de l’utilisation d’une connexion publique. Il existe deux types de connexion lorsque vous utilisez une connexion publique, qui sont répertoriés ici par ordre de préférence :
Connexion UDP directe utilisant le protocole STUN (Simple Traversal Below NAT) entre un client et un hôte de session.
Connexion UDP relayée utilisant le protocole TURN (Traversal Using Relay NAT) entre un client et un hôte de session.
Le transport utilisé pour RDP Shortpath est basé sur le protocole URCP (Universal Rate Control Protocol). L’URCP améliore l’UDP grâce à une surveillance active des conditions du réseau et fournit une utilisation équitable et complète de la liaison. L’URCP fonctionne à de faibles niveaux de retard et de perte selon les besoins.
Importante
-
Cloud Azure : RDP Shortpath pour les réseaux publics via STUN et TURN est généralement disponible.
-
Cloud Azure pour le secteur public : RDP Shortpath via STUN et TURN est disponible en préversion publique avec des serveurs dédiés avec une plage d’adresses IP **20.140.236.0/22. Les clients peuvent essayer la fonctionnalité pour l’hôte de session dans l’anneau de validation.
Avantages clés
L’utilisation de RDP Shortpath présente les principaux avantages suivants :
L’utilisation d’URCP pour améliorer UDP permet d’obtenir les meilleures performances en apprenant dynamiquement les paramètres réseau et en fournissant au protocole un mécanisme de contrôle du débit.
Débit plus élevé.
Lors de l’utilisation de STUN, la suppression de points de relais supplémentaires réduit le temps d’aller-retour, améliore la fiabilité de la connexion et l’expérience utilisateur avec les applications et les méthodes d’entrée sensibles à la latence.
En outre, pour les réseaux gérés :
RDP Shortpath prend en charge la configuration de la priorité de qualité de service (QoS) pour les connexions RDP via des marques DSCP (Differentiated Services Code Point).
Le transport RDP Shortpath permet de limiter le trafic réseau sortant en spécifiant un taux de limitation pour chaque session.
Comment fonctionne RDP Shortpath
Pour savoir comment fonctionne RDP Shortpath pour les réseaux gérés et les réseaux publics, sélectionnez chacun des onglets suivants.
Vous pouvez obtenir la connectivité de ligne de visée directe requise pour utiliser RDP Shortpath avec des réseaux gérés à l’aide des méthodes suivantes.
Une connectivité directe en ligne de visée signifie que le client peut se connecter directement à l’hôte de session sans être bloqué par des pare-feu.
Remarque
Si vous utilisez d’autres types de VPN pour vous connecter à Azure, nous vous recommandons d’utiliser un VPN basé sur UDP. Bien que la plupart des solutions VPN basées sur TCP prennent en charge les UDP imbriqués, elles ajoutent une surcharge héritée du contrôle de congestion TCP, ce qui ralentit les performances RDP.
Pour utiliser RDP Shortpath pour les réseaux gérés, vous devez activer un écouteur UDP sur vos hôtes de session. Par défaut, le port 3390 est utilisé, bien que vous puissiez utiliser un autre port.
Le diagramme suivant donne une vue d’ensemble générale des connexions réseau lors de l’utilisation de RDP Shortpath pour les réseaux gérés et les hôtes de session joints à un domaine Active Directory.
Séquence de connexion
Toutes les connexions commencent par l’établissement d’un transport de connexion inverse basé sur TCP sur la passerelle Azure Virtual Desktop. Ensuite, le client et l’hôte de session établissent le transport RDP initial et commencent à échanger leurs fonctionnalités. Ces fonctionnalités sont négociées à l’aide du processus suivant :
L’hôte de session envoie la liste de ses adresses IPv4 et IPv6 au client.
Le client démarre le thread d’arrière-plan pour établir un transport UDP parallèle directement vers l’une des adresses IP de l’hôte de session.
Pendant que le client sonde les adresses IP fournies, il continue d’établir la connexion initiale sur le transport de connexion inverse pour s’assurer qu’il n’y a pas de retard dans la connexion utilisateur.
Si le client a une connexion directe à l’hôte de session, il établit une connexion sécurisée à l’aide de TLS sur UDP fiable.
Après avoir établi le transport RDP Shortpath, tous les canaux virtuels dynamiques (DVC), y compris les graphiques distants, les entrées et la redirection de périphériques, sont déplacés vers le nouveau transport. Toutefois, si un pare-feu ou une topologie de réseau empêche le client d’établir une connectivité UDP directe, RDP continue avec un transport de connexion inversée.
Si vos utilisateurs disposent à la fois de RDP Shortpath pour le réseau géré et des réseaux publics, l’algorithme trouvé en premier est utilisé. L’utilisateur utilisera la connexion établie en premier pour cette session.
Pour offrir les meilleures chances de réussite d’une connexion UDP lors de l’utilisation d’une connexion publique, il existe les types de connexion directe et relayée :
Connexion directe : STUN est utilisé pour établir une connexion UDP directe entre un client et un hôte de session. Pour établir cette connexion, le client et l’hôte de session doivent pouvoir se connecter l’un à l’autre via une adresse IP publique et un port négocié. Toutefois, la plupart des clients ne connaissent pas leur propre adresse IP publique, car ils se trouvent derrière un périphérique de passerelle de traduction d’adresses réseau (NAT). STUN est un protocole pour l’auto-découverte d’une adresse IP publique derrière un périphérique de passerelle NAT et le client pour déterminer sa propre adresse IP publique.
Pour qu’un client utilise STUN, son réseau doit autoriser le trafic UDP. En supposant que le client et l’hôte de session peuvent acheminer directement vers l’adresse IP et le port découverts de l’autre, la communication est établie avec UDP direct sur le protocole WebSocket. Si des pare-feu ou d’autres périphériques réseau bloquent les connexions directes, une connexion UDP relayée est tentée.
Connexion relayée : TURN est utilisé pour établir une connexion, relayant le trafic via un serveur intermédiaire entre un client et un hôte de session lorsqu’une connexion directe n’est pas possible. TURN est une extension de STUN. L’utilisation de TURN signifie que l’adresse IP publique et le port sont connus à l’avance, ce qui peut être autorisé par le biais de pare-feu et d’autres périphériques réseau.
Si des pare-feu ou d’autres périphériques réseau bloquent le trafic UDP, la connexion revient à un transport de connexion inverse basé sur TCP.
Lorsqu’une connexion est établie, l’Établissement de connectivité interactive (ICE) coordonne la gestion de STUN et TURN afin d’optimiser la probabilité d’établissement d’une connexion et de s’assurer que la priorité est donnée aux protocoles de communication réseau préférés.
Chaque session RDP utilise un port UDP attribué dynamiquement à partir d’une plage de ports éphémère (49152 à 65535 par défaut) qui accepte le trafic RDP Shortpath. Le port 65330 est ignoré de cette plage, car il est réservé à une utilisation interne par Azure. Vous pouvez également utiliser une plage de ports plus petite et prévisible. Pour plus d’informations, consultez Limiter la plage de ports utilisée par les clients pour les réseaux publics.
Conseil
RDP Shortpath pour les réseaux publics fonctionnera automatiquement sans configuration supplémentaire, à condition que les réseaux et les pare-feu autorisent le trafic et que les paramètres de transport RDP dans le système d’exploitation Windows pour les hôtes de session et les clients utilisent leurs valeurs par défaut.
Le diagramme suivant donne une vue d’ensemble générale des connexions réseau lors de l’utilisation de RDP Shortpath pour les réseaux publics où les hôtes de session sont joints à Microsoft Entra ID.
Disponibilité du relais TURN
Le relais TURN est disponible dans les régions Azure suivantes avec le relais ACS TURN (51.5.0.0/16) :
- Centre de l’Australie
- Australie Est
- Australie Sud-Est
- Sud du Brésil
- Canada Centre
- Canada Est
- Centre de l’Inde
- USA Centre
- USA Est
- USA Est 2
- France Centre
- Centre Ouest de l’Allemagne
- Israël Centre
- Japon Est
- Japon Ouest
- Corée du Sud
- Corée Sud
- Mexique Centre
- USA Centre Nord
- Europe Nord
- Norvège Ouest
- Nord de l’Afrique du Sud
- Ouest de l’Afrique du Sud
- USA Centre Sud
- Asie Sud-Est
- Inde Sud
- Espagne Centre
- Suisse Nord
- Tawain Nord
- Tawain Nord-Est
- UAE Centre
- UAE Nord
- Sud du Royaume-Uni
- Ouest du Royaume-Uni
- USA Centre Ouest
- Europe Ouest
- USA Ouest
- USA Ouest 2
- USA Ouest 3
Un relais TURN est sélectionné en fonction de l’emplacement physique de l’appareil client. Par exemple, si un appareil client se trouve au Royaume-Uni, le relais TURN dans la région Royaume-Uni Sud ou Royaume-Uni Ouest est sélectionné. Si un périphérique client est éloigné d’un relais TURN, la connexion UDP peut revenir sur TCP.
Traduction d’adresses réseau et pare-feux
La plupart des clients Azure Virtual Desktop s’exécutent sur des ordinateurs du réseau privé. L’accès à Internet est fourni par le biais d’un périphérique de passerelle de traduction d’adresses réseau (NAT). Par conséquent, la passerelle NAT modifie toutes les requêtes réseau provenant du réseau privé et destinées à Internet. Cette modification vise à partager une adresse IP publique unique sur tous les ordinateurs du réseau privé.
En raison de la modification du paquet IP, le destinataire du trafic verra l’adresse IP publique de la passerelle NAT au lieu de l’expéditeur réel. Lorsque le trafic revient à la passerelle NAT, celle-ci prendra soin de la transférer au destinataire prévu à l’insu de l’expéditeur. Dans la plupart des scénarios, les périphériques cachés derrière un tel NAT ne savent pas que la traduction est en cours et ne connaissent pas l’adresse réseau de la passerelle NAT.
NAT s’applique aux réseaux virtuels Azure où résident tous les hôtes de session. Lorsqu’un hôte de session tente d’atteindre l’adresse réseau sur Internet, la passerelle NAT (la vôtre ou celle fournie par défaut par Azure) ou Azure Load Balancer effectue la traduction d’adresse. Pour plus d’informations sur les différents types de traduction d’adresses réseau source, voir Utiliser la traduction d’adresses réseau source (SNAT) pour les connexions sortantes.
La plupart des réseaux incluent généralement des pare-feu qui inspectent le trafic et le bloquent en fonction de règles. La plupart des clients configurent leurs pare-feu pour empêcher les connexions entrantes (c’est-à-dire les paquets non sollicités provenant d’Internet envoyés sans requête). Les pare-feu utilisent différentes techniques pour suivre le flux de données et faire la distinction entre le trafic sollicité et non sollicité. Dans le contexte du protocole TCP, le pare-feu suit les paquets SYN et ACK, et le processus est simple. Les pare-feu UDP utilisent généralement une heuristique basée sur les adresses de paquets pour associer le trafic aux flux UDP et l’autoriser ou le bloquer. Il existe de nombreuses implémentations de NAT différentes.
Séquence de connexion
Toutes les connexions commencent par l’établissement d’un transport de connexion inverse basé sur TCP sur la passerelle Azure Virtual Desktop. Ensuite, le client et l’hôte de session établissent le transport RDP initial et commencent à échanger leurs fonctionnalités. Si RDP Shortpath pour les réseaux publics est activé sur l’hôte de session, l’hôte de session lance alors un processus appelé « rassemblement de candidats » :
L’hôte de session énumère toutes les interfaces réseau affectées à un hôte de session, y compris les interfaces virtuelles telles que VPN et Teredo.
Les services Bureau à distance du service Windows (TermService) allouent des sockets UDP sur chaque interface et stockent la paire IP :Port dans la table candidate en tant que candidate locale.
Le service Services Bureau à distance utilise chaque socket UDP alloué à l’étape précédente pour tenter d’atteindre le serveur Azure Virtual Desktop STUN sur l’Internet public. La communication se fait en envoyant un petit paquet UDP au port 3478.
Si le paquet atteint le serveur STAN, le serveur STUN répond avec l’adresse IP et le port publics. Cette information est stockée dans la table du candidat en tant que candidate réflexive.
Une fois que l’hôte de session a rassemblé tous les candidats, il utilise le transport de connexion inverse établi pour transmettre la liste des candidats au client.
Lorsque le client reçoit la liste des candidats de l’hôte de la session, il effectue également la collecte des candidats de son côté. Le client envoie ensuite sa liste de candidats à l’hôte de la session.
Une fois que l’hôte et le client de la session ont échangé leurs listes de candidats, les deux parties tentent de se connecter l’une à l’autre en utilisant tous les candidats recueillis. Cette tentative de connexion est simultanée des deux côtés. De nombreuses passerelles NAT sont configurées pour autoriser le trafic entrant vers le socket dès que le transfert de données sortant l’initialise. Ce comportement des passerelles NAT est la raison pour laquelle la connexion simultanée est essentielle. Si STUN échoue parce qu’il est bloqué, une tentative de connexion relayée est effectuée à l’aide de TURN.
Après l’échange de paquets initial, le client et l’hôte de session peuvent établir un ou plusieurs flux de données. Parmi ces flux de données, RDP choisit le chemin réseau le plus rapide. Le client établit ensuite une connexion sécurisée à l’aide de TLS sur un UDP fiable avec l’hôte de session et lance le transport RDP Shortpath.
Une fois que RDP a établi le transport RDP Shortpath, tous les canaux virtuels dynamiques (DVC), y compris les graphiques distants, les entrées et la redirection de périphériques, sont déplacés vers le nouveau transport.
Si vos utilisateurs disposent à la fois de RDP Shortpath pour le réseau géré et des réseaux publics, l’algorithme trouvé en premier est utilisé, ce qui signifie que l’utilisateur utilisera la connexion établie en premier pour cette session. Pour plus d’informations, reportez-vous à l’exemple de scénario 4.
Configuration réseau
Pour prendre en charge RDP Shortpath pour les réseaux publics, vous n’avez généralement pas besoin d’une configuration particulière. L’hôte et le client de la session découvriront automatiquement le flux de données direct si cela est possible dans votre configuration réseau. Toutefois, chaque environnement est unique et certaines configurations réseau peuvent avoir un impact négatif sur le taux de réussite de la connexion directe. Suivez les recommandations pour augmenter la probabilité d’un flux direct de données.
Comme RDP Shortpath utilise UDP pour établir un flux de données, si un pare-feu sur votre réseau bloque le trafic UDP, RDP Shortpath échoue et la connexion revient au transport de connexion inverse basé sur TCP. Azure Virtual Desktop utilise les serveurs STUN fournis par Azure Communication Services et Microsoft Teams. De par la nature de la fonctionnalité, une connectivité sortante des hôtes de session vers le client est nécessaire. Malheureusement, vous ne pouvez pas prédire où se trouvent vos utilisateurs dans la plupart des cas. Par conséquent, nous vous recommandons d’autoriser la connectivité UDP sortante des hôtes de session vers Internet. Pour réduire le nombre de ports requis, vous pouvez limiter la plage de ports utilisée par les clients pour le flux UDP. Utilisez les tableaux suivants comme référence lors de la configuration des pare-feu pour RDP Shortpath.
Si votre environnement utilise NAT symétrique, qui est le mappage d’une seule source privée IP :Port à une destination publique unique, IP :Port, vous pouvez utiliser une connexion relayée avec TURN. C’est le cas si vous utilisez Pare-feu Azure et Azure passerelle NAT. Pour plus d’informations sur le NAT avec les réseaux virtuels Azure, consultez Traduction d’adresses réseau sources avec des réseaux virtuels.
Nous avons quelques recommandations générales pour des connexions réussies à l’aide de RDP Shortpath pour les réseaux publics. Pour plus d’informations, consultez Recommandations générales.
Lorsque les utilisateurs disposent de RDP Shortpath pour le réseau géré et les réseaux publics, le premier algorithme trouvé sera utilisé. L’utilisateur utilisera la connexion établie en premier pour cette session. Pour plus d’informations, consultez Exemples de scénarios.
Les sections suivantes contiennent les exigences de source, de destination et de protocole pour vos hôtes de session et appareils clients qui doivent être autorisés pour que le protocole RDP Shortpath fonctionne.
Remarque
Microsoft a terminé la transition du sous-réseau 20.202.0.0/16 précédemment partagé vers la nouvelle plage d’adresses IP de relais TURN 51.5.0.0/16 dans 39 régions Azure. Cette nouvelle gamme est dédiée exclusivement à Azure Virtual Desktop et à Windows 365, la séparant ainsi de l’infrastructure Azure Communication Services. La mise à niveau est conçue pour améliorer RDP Shortpath pour les réseaux publics (via TURN/Relay), offrant une connectivité plus rapide et plus fiable et une expérience utilisateur améliorée.
Remarque
Les connexions TURN sont sensibles aux pertes de connexion pendant les mises à jour du relais TURN. Ces mises à jour se produisent généralement pendant les fenêtres de maintenance planifiées, mais peuvent parfois se produire en dehors de la fenêtre planifiée en raison de correctifs d’infrastructure Azure urgents.
Dans tous les scénarios ci-dessus, le client se reconnecte automatiquement en quelques secondes.
Session Hôte Réseau virtuel
Le tableau suivant détaille les exigences de source, de destination et de protocole pour RDP Shortpath pour votre réseau virtuel hôte de session.
| Nom |
Source |
Port source |
Destination |
Port de destination |
Protocole |
Action |
| Connexion directe STUN |
Sous-réseau de machine virtuelle |
N’importe lequel |
N’importe lequel |
1024-65535
(par défaut : 49152-65535) |
UDP |
Autoriser |
| Relais STUN/TURN |
Sous-réseau de machine virtuelle |
N’importe lequel |
51.5.0.0/16 |
3478 |
UDP |
Autoriser |
Réseau client
Le tableau suivant détaille les exigences de source, de destination et de protocole pour vos appareils clients.
| Nom |
Source |
Port source |
Destination |
Port de destination |
Protocole |
Action |
| Connexion directe STUN |
Réseau client |
N’importe lequel |
Adresses IP publiques attribuées à la passerelle NAT ou au pare-feu Azure (fournies par le point de terminaison STUN) |
1024-65535
(par défaut : 49152-65535) |
UDP |
Autoriser |
| Relais STUN/TURN |
Réseau client |
N’importe lequel |
51.5.0.0/16 |
3478 |
UDP |
Autoriser |
Importante
La plage d’adresses IP de relais TURN dédiées pour Azure Government est 20.140.236.0/22. RDP Shortpath via TURN est actuellement en préversion publique dans Azure Government. Les clients peuvent essayer la fonctionnalité à l’aide de l’anneau de validation.
Session Hôte Réseau virtuel
Le tableau suivant détaille les exigences de source, de destination et de protocole pour RDP Shortpath pour votre réseau virtuel hôte de session.
| Nom |
Source |
Port source |
Destination |
Port de destination |
Protocole |
Action |
| Connexion directe STUN |
Sous-réseau de machine virtuelle |
N’importe lequel |
N’importe lequel |
1024-65535
(par défaut : 49152-65535) |
UDP |
Autoriser |
| Relais STUN/TURN |
Sous-réseau de machine virtuelle |
N’importe lequel |
20.140.236.0/22 |
3478 |
UDP |
Autoriser |
Réseau client
Le tableau suivant détaille les exigences de source, de destination et de protocole pour vos appareils clients.
| Nom |
Source |
Port source |
Destination |
Port de destination |
Protocole |
Action |
| Connexion directe STUN |
Réseau client |
N’importe lequel |
Adresses IP publiques attribuées à la passerelle NAT ou au pare-feu Azure (fournies par le point de terminaison STUN) |
1024-65535
(par défaut : 49152-65535) |
UDP |
Autoriser |
| Relais STUN/TURN |
Réseau client |
N’importe lequel |
20.140.236.0/22 |
3478 |
UDP |
Autoriser |
Prise en charge de Teredo
Bien qu’il ne soit pas requis pour RDP Shortpath, Teredo ajoute des candidats de traversée NAT supplémentaires et augmente les chances de réussite de la connexion RDP Shortpath dans les réseaux IPv4 uniquement. Pour savoir comment activer Teredo sur les hôtes et les clients de session, voir Activer la prise en charge de Teredo.
Prise en charge UPnP
Pour améliorer les chances d’une connexion directe, du côté du client Bureau à distance, RDP Shortpath peut utiliser UPnP pour configurer un mappage de port sur le routeur NAT. UPnP est une technologie standard utilisée par diverses applications, telles que Xbox, l’optimisation de la distribution et Teredo. UPnP est généralement disponible sur les routeurs généralement trouvés sur un réseau domestique. UPnP est activé par défaut sur la plupart des routeurs et points d’accès domestiques, mais il est souvent désactivé sur les réseaux d’entreprise.
Recommandations générales
Voici quelques recommandations générales pour l’utilisation de RDP Shortpath pour les réseaux publics :
Évitez d’utiliser des configurations de tunneling forcé si vos utilisateurs accèdent à Azure Virtual Desktop via Internet.
Assurez-vous de ne pas utiliser de configurations à double NAT ou CGN (Carrier-Grade-NAT).
Recommandez à vos utilisateurs de ne pas désactiver UPnP sur leurs routeurs domestiques.
Évitez d’utiliser les services d’inspection des paquets dans le cloud.
Évitez d’utiliser des solutions VPN basées sur TCP.
Activez la connectivité IPv6 ou Teredo.
Sécurité de la connexion
RDP Shortpath étend les fonctionnalités de multi-transport RDP. Il ne remplace pas le transport de connexion inversée, mais le complète. La répartiteur de session initiale est géré via le service Azure Virtual Desktop et le transport de connexion inverse. Toutes les tentatives de connexion sont ignorées, sauf si elles correspondent d’abord à la session de connexion inverse. Le protocole RDP Shortpath est établi après l’authentification, et si cela est correctement établi, le transport de connexion inverse est abandonné et tout le trafic circule sur le chemin RDP Shortpath.
RDP Shortpath utilise une connexion sécurisée à l’aide de TLS sur un UDP fiable entre le client et l’hôte de session à l’aide des certificats de l’hôte de session. Par défaut, le certificat utilisé pour le chiffrement RDP est généré automatiquement par le système d’exploitation pendant le déploiement. Azure Virtual Desktop ne prend pas en charge l’utilisation d’un certificat émis par une autorité de certification pour le moment.
Exemples de scénarios
Voici quelques exemples de scénarios pour montrer comment les connexions sont évaluées pour déterminer si RDP Shortpath est utilisé sur différentes topologies de réseau.
Scénario 1
Une connexion UDP ne peut être établie entre l’appareil client et l’hôte de session que sur un réseau public (Internet). Une connexion directe, telle qu’un VPN, n’est pas disponible. UDP est autorisé via le pare-feu ou le périphérique NAT.
Scénario 2
Un pare-feu ou un périphérique NAT bloque une connexion UDP directe, mais une connexion UDP relayée peut être relayée à l’aide de TURN entre le périphérique client et l’hôte de session sur un réseau public (Internet). Une autre connexion directe, telle qu’un VPN, n’est pas disponible.
Scénario 3
Une connexion UDP peut être établie entre l’appareil client et l’hôte de session sur un réseau public ou sur une connexion VPN directe, mais RDP Shortpath pour les réseaux gérés n’est pas activé. Lorsque le client initie la connexion, le protocole ICE/STUN peut voir plusieurs itinéraires et évalue chaque itinéraire et choisit celui avec la latence la plus faible.
Dans cet exemple, une connexion UDP utilisant RDP Shortpath pour les réseaux publics sur la connexion VPN directe sera établie car elle a la latence la plus faible, comme indiqué par la ligne verte.
Scénario 4
RDP Shortpath pour les réseaux publics et les réseaux gérés est activé. Une connexion UDP peut être établie entre l’appareil client et l’hôte de session sur un réseau public ou sur une connexion VPN directe. Lorsque le client initie la connexion, il y a des tentatives simultanées de connexion à l’aide de RDP Shortpath pour les réseaux gérés via le port 3390 (par défaut) et de RDP Shortpath pour les réseaux publics via le protocole ICE/STUN. Le premier algorithme trouvé sera utilisé et l’utilisateur utilisera la connexion établie en premier pour cette session.
Étant donné que l’exploration d’un réseau public comporte plus d’étapes, par exemple un périphérique NAT, un équilibreur de charge ou un serveur STUN, il est probable que l’algorithme trouvé en premier sélectionne la connexion à l’aide de RDP Shortpath pour les réseaux gérés et soit établi en premier.
Scénario 5
Une connexion UDP peut être établie entre l’appareil client et l’hôte de session sur un réseau public ou sur une connexion VPN directe, mais RDP Shortpath pour les réseaux gérés n’est pas activé. Pour empêcher ICE/STUN d’utiliser une route particulière, un administrateur peut bloquer l’une des routes pour le trafic UDP. Le blocage d’un itinéraire garantit que le chemin restant est toujours utilisé.
Dans cet exemple, UDP est bloqué sur la connexion VPN directe et le protocole ICE/STUN établit une connexion sur le réseau public.
Scénario 6
Les réseaux RDP Shortpath pour les réseaux publics et les réseaux gérés sont configurés, mais une connexion UDP n’a pas pu être établie à l’aide d’une connexion VPN directe. Un pare-feu ou un périphérique NAT bloque également une connexion UDP directe en utilisant le réseau public (Internet), mais une connexion UDP relayée peut être relayée à l’aide de la fonction TURN entre le périphérique client et l’hôte de session sur un réseau public (Internet).
Scénario 7
RDP Shortpath pour les réseaux publics et les réseaux gérés sont tous deux configurés, mais une connexion UDP n’a pas pu être établie. Dans cette instance, le protocole RDP Shortpath échoue et la connexion revient au transport de connexion inverse basé sur TCP.
Étapes suivantes
