RDP Shortpath pour Azure Virtual Desktop

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.

• Peering privé ExpressRoute

• VPN de site à site ou de point à site (IPsec), par exemple Azure passerelle VPN

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.

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 :

1. L’hôte de la session envoie la liste de ses adresses IPv4 et IPv6 au client.

2. 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.

3. 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.

4. Si le client dispose d’une connexion directe vers l’hôte de la session, le client établit une connexion sécurisée utilisant TLS sur un protocole UDP fiable.

5. 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.

Pour offrir les meilleures chances qu’une connexion UDP réussisse 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 être en mesure de 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 appareil de passerelle NAT (Network Address Translation). STUN est un protocole permettant de découvrir automatiquement une adresse IP publique derrière un appareil de passerelle NAT ; le client peut ainsi 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 puissent router directement vers l’adresse IP et le port découverts de l’autre, la communication est établie en mode UDP direct via le protocole WebSocket. Si des pare-feux ou d’autres appareils réseau bloquent les connexions directes, une connexion UDP relayée est tentée.

• Connexion relayée : TURN est utilisé pour établir une connexion indirecte, en relayant le trafic via un serveur intermédiaire entre un client et un hôte de session quand 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 TCP.

Quand une connexion est en train d’être établie, l’établissement de connectivité interactive (ICE) coordonne la gestion de STUN et TURN pour optimiser la probabilité d’établir une connexion et 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 éphémère de ports (49152 to 65535 par défaut) qui accepte le trafic RDP Shortpath. Le port 65330 est ignoré de cette plage, car réservé à un usage 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.

Le diagramme suivant fournit une vue d’ensemble des connexions réseau lors de l’utilisation de RDP Shortpath pour les réseaux publics où des hôtes de session sont joints à Microsoft Entra ID.

Disponibilité du relais TURN

Le relais TURN est disponible dans les régions Azure suivantes :

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 de la région Royaume-Uni Sud ou Royaume-Uni Ouest est sélectionné. Si un appareil client est loin d’un relais TURN, la connexion UDP peut revenir au protocole TCP.

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.

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 :

1. 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.

2. 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.

3. 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.

4. Si le paquet atteint le serveur STUN, le serveur STUN répond avec l’adresse IP publique et le port. Ces informations sont stockées dans la table candidate en tant que candidat réflexif.

5. 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.

6. 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.

7. 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. Si STUN échoue parce qu’il est bloqué, une tentative de connexion relayée est effectuée avec TURN.

8. 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 sécurisée utilisant TLS sur un protocole UDP fiable avec l’hôte de session et lance le transport RDP Shortpath.

9. 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 ont à la fois RDP Shortpath pour le réseau managé et les réseaux publics à leur disposition, l’algorithme premier trouvé sera utilisé, ce qui signifie que l’utilisateur utilisera la connexion établie en premier pour cette session. Pour plus d’informations, consultez scénario exemple 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 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 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 votre environnement utilise la NAT symétrique, qui est le mappage d’une seule adresse IP:Port source privée à une adresse IP:Port de destination publique unique, vous pouvez utiliser une connexion relayée avec TURN. Ce sera le cas si vous utilisez le Pare-feu Azure et Azure NAT Gateway. Pour plus d’informations sur NAT avec des réseaux virtuels Azure, consultez Traduction d’adresses réseau source avec des réseaux virtuels.

Voici quelques recommandations générales pour la réussite des connexions en utilisant RDP Shortpath pour des réseaux publics. Pour plus d’informations, consultez Recommandations générales.

Quand vos utilisateurs disposent de RDP Shortpath pour un réseau géré et les réseaux publics, le premier algorithme trouvé est utilisé. L’utilisateur utilisera la première connexion établie pour cette session. Pour plus d’informations, consultez les Exemple de scénarios.

Les sections suivantes contiennent les exigences quant à la source, la destination et le protocole pour vos hôtes de session et les appareils clients qui doivent être autorisés pour que RDP Shortpath fonctionne.

Réseau virtuel hôte de session

Le tableau suivant détaille les exigences quant à la source, la destination et le protocole pour RDP Shortpath pour le réseau virtuel de votre hôte de session.

Réseau client

Le tableau suivant détaille les exigences quant à la source, la destination et le protocole pour vos appareils clients.

Prise en charge de Teredo

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 Activer la 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.