Les connexions à Azure Virtual Desktop utilisent le protocole TCP (Transmission Control Protocol) ou UDP (User Datagram Protocol). RDP Shortpath est une fonctionnalité d’Azure Virtual Desktop qui établit un transport UDP direct entre un client Bureau à distance Windows pris en charge et un hôte de session. Par défaut, le protocole Remote Desktop Protocol (RDP) utilise un transport de connexion inversée basé sur TCP, car il offre la meilleure compatibilité avec diverses configurations réseau et présente un taux de réussite élevé pour établir des connexions RDP. RDP Shortpath peut néanmoins être utilisé à la place, car ce transport UDP offre une meilleure fiabilité de connexion et une latence plus homogène.
RDP Shortpath peut être utilisé de deux manières :
Réseaux managés, où une connectivité directe est établie entre le client et l’hôte de session lors de l’utilisation d’une connexion privée, par exemple un réseau privé virtuel (VPN).
Réseaux publics, où la connectivité directe est établie entre le client et l’hôte de session via une passerelle NAT, fournie dans le cadre du service Azure Desktop, lors de l’utilisation d’une connexion publique.
Le transport utilisé pour RDP Shortpath est basé sur le protocole URCP (Universal Rate Control Protocol). Le protocole URCP améliore le protocole UDP avec la surveillance active des conditions du réseau, et assure une utilisation de liens équitable et complète. Le protocole URCP opère à des niveaux faibles de retard et de perte en fonction des besoins.
Principaux avantages
L’utilisation de RDP Shortpath présente les principaux avantages suivants :
URCP améliore les performances UDP en apprenant de manière dynamique des paramètres réseau et en fournissant un mécanisme de contrôle de débit.
La suppression de points de relais supplémentaires réduit le temps aller-retour, ce qui améliore la fiabilité de la connexion et l’expérience des utilisateurs avec des applications et des méthodes d’entrée sensibles à la latence.
En outre, pour les réseaux managés :
RDP Shortpath introduit la prise en charge d’une priorité en matière de configuration de la qualité de service (QoS) pour les connexions RDP par le biais de 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.
Fonctionnement de RDP Shortpath
Pour savoir comment RDP Shortpath fonctionne avec les réseaux managés et les réseaux publics, sélectionnez chacun des onglets suivants.
Vous pouvez obtenir la connectivité avec ligne de vue directe requise pour utiliser RDP Shortpath avec des réseaux managés à l’aide des méthodes suivantes. Le fait de disposer d’une connectivité avec ligne de vue directe signifie que le client peut se connecter directement à l’hôte de session sans être bloqué par les pare-feu.
Si vous utilisez d’autres types de VPN pour vous connecter à Azure, nous vous recommandons d’utiliser un VPN basé sur le protocole UDP. Bien que la plupart des solutions VPN basées sur le protocole TCP prennent en charge le protocole UDP imbriqué, elles ajoutent une surcharge héritée du contrôle de congestion TCP, ce qui ralentit les performances de RDP.
Pour utiliser RDP Shortpath avec des réseaux managés, vous devez activer un écouteur UDP sur vos hôtes de session. Par défaut, le port 3390 est utilisé, mais vous pouvez en utiliser un autre.
Le diagramme suivant fournit une vue d’ensemble des connexions réseau lors de l’utilisation de RDP Shortpath pour les réseaux managés et les hôtes de session joints à un domaine Active Directory.
Séquence de connexion
Toutes les connexions commencent par établir un transport de connexion inverse TCP sur la passerelle Azure Virtual Desktop. Le client et l’hôte de session établissent ensuite 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 la 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 éviter tout retard dans la connexion utilisateur.
Si le client dispose d’une connexion directe vers l’hôte de la session, le client établit une connexion TLS sécurisée.
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 des appareils, sont déplacés vers le nouveau transport. Mais si un pare-feu ou une topologie de réseau empêche le client d’établir une connexion UDP directe, le protocole RDP continue avec un transport de connexion inverse.
Si vos utilisateurs disposent de RDP Shortpath pour les réseaux managés et les réseaux publics, le premier algorithme trouvé sera utilisé. L’utilisateur utilisera la première connexion établie pour cette session.
Lors de la connexion à Azure Virtual Desktop à l’aide d’un réseau public, RDP Shortpath utilise un ensemble standardisé de méthodes pour parcourir les passerelles NAT. Par conséquent, les sessions utilisateur établissent directement un flux UDP entre le client et l’hôte de la session. Plus précisément, RDP Shortpath utilise le protocole Simple Traversal Underneath NAT (STUN) pour découvrir l’adresse IP externe du routeur NAT.
Chaque session RDP utilise un port UDP attribué dynamiquement à partir d’une plage éphémère de ports (49152-65535 par défaut) qui accepte le trafic RDP Shortpath. 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.
Il existe quatre composants principaux utilisés pour établir le flux de données RDP Shortpath pour les réseaux publics :
Client Bureau à distance
Hôte de session
Passerelle Azure Virtual Desktop
Serveur STUN Azure Virtual Desktop
Conseil
RDP Shortpath pour les réseaux publics fonctionnera automatiquement sans aucune configuration supplémentaire, à condition que les réseaux et pare-feu autorisent le trafic via 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 fournit une vue d’ensemble des connexions réseau lors de l’utilisation de RDP Shortpath pour les réseaux publics et les hôtes de session joints à Azure Active Directory (Azure AD).
Traduction d’adresses réseau et pare-feu
La plupart des clients Azure Virtual Desktop s’exécutent sur des ordinateurs sur le réseau privé. L’accès à Internet est fourni via un appareil de passerelle NAT (Network Address Translation). Par conséquent, la passerelle NAT modifie toutes les requêtes réseau du réseau privé et destinées à Internet. Cette modification vise à partager une seule adresse IP publique 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, il prend soin de le transférer au destinataire prévu sans connaître l’expéditeur. Dans la plupart des scénarios, les appareils masqués derrière un tel NAT ne sont pas conscients de la traduction qui se produit 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’adresses. Pour plus d’informations sur les différents types de traduction d’adresses réseau sources, consultez Utiliser SNAT (Source Network Address Translation) 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 leur pare-feu pour empêcher les connexions entrantes (autrement dit, les paquets non sollicités provenant d’Internet envoyés sans demande). Les pare-feu utilisent différentes techniques pour suivre le flux de données afin de faire la distinction entre le trafic sollicité et le trafic non sollicité. Dans le contexte de TCP, le pare-feu effectue le suivi des paquets SYN et ACK, et le processus est simple. Les pare-feu UDP utilisent généralement des heuristiques basées sur des adresses de paquets pour associer le trafic aux flux UDP et autoriser ou bloquer le trafic.
Il existe de nombreuses implémentations NAT différentes disponibles. Dans la plupart des cas, la passerelle NAT et le pare-feu sont les fonctions du même appareil physique ou virtuel.
Séquence de connexion
Toutes les connexions commencent par établir un transport de connexion inverse TCP sur la passerelle Azure Virtual Desktop. Le client et l’hôte de session établissent ensuite 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 un processus appelé rassemblement candidat :
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.
Le service Windows Bureau à distance (TermService) alloue le socket UDP sur chaque interface et stocke la paire IP:Port dans la table candidate en tant que candidat local.
Le service Bureau à distance utilise chaque socket UDP alloué à l’étape précédente pour essayer d’atteindre le serveur STUN Azure Virtual Desktop sur le réseau Internet public. La communication est effectuée en envoyant un petit paquet UDP au port 3478.
Si le paquet atteint le serveur STUN, le serveur STUN répond avec l’adresse IP publique (spécifiée par vous ou fournie par Azure) et le port. Ces informations sont stockées dans la table candidate en tant que candidat réflexif.
Une fois que l’hôte de session rassemble tous les candidats, l’hôte de session utilise le transport de connexion inversée é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, le client effectue également la collecte des candidats de son côté. Ensuite, le client envoie sa liste candidate à l’hôte de session.
Une fois que l’hôte de session et le client échangent leurs listes de candidats, les deux parties tentent de se connecter les unes avec les autres à l’aide de tous les candidats rassemblés. Cette tentative de connexion est simultanée des deux côtés. La plupart des 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.
Après l’échange de paquets initial, le client et l’hôte de session peuvent établir un ou plusieurs flux de données. À partir de ces flux de données, RDP choisit le chemin d’accès réseau le plus rapide. Le client établit ensuite une connexion TLS sécurisée 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 des appareils, sont déplacés vers le nouveau transport.
Si vos utilisateurs disposent de RDP Shortpath pour les réseaux managés et les réseaux publics, le premier algorithme trouvé sera utilisé. L’utilisateur utilisera la première connexion établie pour cette session.
Important
Lorsque vous utilisez un transport TCP, le trafic sortant de l’hôte de session vers le client s’effectue via la passerelle Azure Virtual Desktop. Avec RDP Shortpath, le trafic sortant est établi directement entre l’hôte de session et le client via Internet. Cela supprime un tronçon, améliorant ainsi la latence et l’expérience de l’utilisateur final. Toutefois, en raison des modifications apportées au flux de données entre l’hôte de session et le client où la passerelle n’est plus utilisée, d’autres frais réseau de sortie Azure standard seront facturés par abonnement pour la bande passante Internet consommée. Pour en savoir plus sur l’estimation de la bande passante utilisée par RDP, consultez Exigences en bande passante de RDP.
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 de session et le client découvrent automatiquement le flux de données direct s’il est possible dans votre configuration réseau. Toutefois, chaque environnement est unique et certaines configurations réseau peuvent affecter négativement le taux de réussite de la connexion directe. Suivez les recommandations ci-dessous pour augmenter la probabilité d’un flux de données direct.
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 TCP. Azure Virtual Desktop utilise des serveurs STUN fournis par Azure Communication Services et Microsoft Teams. Par nature de la fonctionnalité, la connectivité sortante des hôtes de session au client est requise. 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 entre vos hôtes la session et 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 pour référence lors de la configuration des pare-feu pour RDP Shortpath.
Si vos utilisateurs se trouvent dans un scénario où RDP Shortpath pour les réseaux managés et les réseaux publics sont disponibles, le premier algorithme trouvé est utilisé. L’utilisateur utilisera la première connexion établie pour cette session.
Notes
RDP Shortpath ne prend pas en charge les NAT symétriques, qui correspondant au mappage d’une seule adresse IP:Port source privée à une adresse IP:Port de destination publique unique. Cela est dû au fait que RDP Shortpath doit réutiliser le même port externe (ou liaison NAT) dans la connexion initiale. Lorsque plusieurs chemins d’accès sont utilisés, par exemple une paire de pare-feu hautement disponibles, la réutilisation du port externe ne peut pas être garantie. Le Pare-feu Azure et la passerelle NAT Azure utilisent une NAT symétrique et ne sont donc pas pris en charge. Pour plus d’informations sur NAT avec des réseaux virtuels Azure, consultez Traduction d’adresses réseau source avec des réseaux virtuels.
Bien qu’il ne soit pas nécessaire 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 de session et les clients, consultez Prise en charge de Teredo.
Prise en charge UPnP
Pour améliorer les chances d’une connexion directe, sur le 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 la Xbox, 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 est souvent désactivé sur la mise en réseau d’entreprise.
Recommandations générales
Voici quelques recommandations générales lors de 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 que vous n’utilisez pas de configurations 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 cloud.
Évitez d’utiliser des solutions VPN basées sur le TCP.
Activez la connectivité IPv6 ou Teredo.
Sécurité de la connexion
RDP Shortpath étend les fonctionnalités multitransport du protocole RDP. Il ne remplace pas le transport de connexion inverse mais le complète. La répartition de session initiale est gérée 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. RDP Shortpath est établi après authentification, et si l’opération réussit, le transport de connexion inverse est supprimé et tout le trafic s’effectue via RDP Shortpath.
Le port utilisé pour chaque session RDP varie selon que RDP Shortpath est utilisé pour les réseaux managés ou les réseaux publics :
Réseaux managés : seul le port UDP spécifié (3390 par défaut) sera utilisé pour le trafic RDP Shortpath entrant.
Réseaux publics : chaque session RDP utilise un port UDP attribué dynamiquement à partir d’une plage éphémère de ports (49152-65535 par défaut) qui accepte le trafic RDP Shortpath. 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.
RDP Shortpath utilise une connexion TLS entre le client et l’hôte de session à l’aide des certificats de l’hôte de la 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. RDP Shortpath utilise une connexion TLS entre le client et l’hôte de session à l’aide des certificats de l’hôte de la 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. Vous pouvez également déployer des certificats gérés de manière centralisée émis par une autorité de certification d’entreprise. Pour plus d’informations sur les configurations de certificat, consultez Configurations de certificat de l’écouteur Bureau à distance.
Notes
La sécurité offerte par RDP Shortpath est identique à celle offerte par le transport de connexion inverse.
Exemples de scénarios
Voici quelques exemples de scénarios montrant comment les connexions sont évaluées afin de déterminer si RDP Shortpath est utilisé sur différentes topologies réseau.
Scénario 1
Une connexion UDP ne peut être établie qu’entre l’appareil client et l’hôte de session via un réseau public (Internet). Une connexion directe, telle qu’un VPN, n’est pas disponible.
Scénario 2
Une connexion UDP peut être établie entre l’appareil client et l’hôte de session sur un réseau public ou via une connexion VPN directe, mais RDP Shortpath pour les réseaux managés n’est pas activé. Lorsque le client lance la connexion, le protocole ICE/STUN peut voir plusieurs itinéraires et va évaluer chaque itinéraire afin de choisir celui ayant la latence la plus faible.
Dans cet exemple, une connexion UDP utilisant RDP Shortpath pour les réseaux publics via la connexion VPN directe sera établie, car elle présente la latence la plus faible, comme indiqué par la ligne verte.
Scénario 3
RDP Shortpath pour les réseaux publics et les réseaux managés sont activés. Une connexion UDP peut être établie entre l’appareil client et l’hôte de session via un réseau public ou une connexion VPN directe. Lorsque le client lance la connexion, des tentatives simultanées de connexion sont effectuées via RDP Shortpath pour les réseaux managés via le port 3390 (par défaut) et 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’utilisation d’un réseau public comporte des étapes supplémentaires, par exemple un appareil NAT, un équilibreur de charge ou un serveur STUN, il est probable que le premier algorithme trouvé sélectionne la connexion utilisant RDP Shortpath pour les réseaux managés et établie en premier.
Scénario 4
Une connexion UDP peut être établie entre l’appareil client et l’hôte de session sur un réseau public ou via une connexion VPN directe, mais RDP Shortpath pour les réseaux managés n’est pas activé. Pour empêcher ICE/STUN d’utiliser un itinéraire particulier, un administrateur peut bloquer l’un des itinéraires pour le trafic UDP. Le blocage d’un itinéraire garantit que le chemin d’accès 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 5
RDP Shortpath pour les réseaux publics et les réseaux managés sont configurés, mais une connexion UDP n’a pas pu être établie. Dans cette instance, RDP Shortpath échoue et la connexion revient au transport de connexion inverse TCP.
