Instructions relatives aux serveurs proxy pour Azure Virtual Desktop

Cet article vous montre comment utiliser un serveur proxy avec Azure Virtual Desktop. Les recommandations de cet article s’appliquent uniquement aux connexions entre l’infrastructure, le client et les agents hôtes de session Azure Virtual Desktop. Cet article ne traite pas de la connectivité réseau pour Office, Windows 10, FSLogix ou d’autres applications Microsoft.

Que sont les serveurs proxy ?

Nous vous recommandons de contourner les proxys pour le trafic Azure Virtual Desktop. Les proxys ne rendent pas Azure Virtual Desktop plus sécurisé, car le trafic est déjà chiffré. Pour en savoir plus sur la sécurité des connexions, consultez Sécurité des connexions.

La plupart des serveurs proxy ne sont pas conçus pour prendre en charge les connexions WebSocket de longue durée et peuvent affecter la stabilité des connexions. L’extensibilité du serveur proxy entraîne également des problèmes, car Azure Virtual Desktop utilise plusieurs connexions à long terme. Si vous utilisez des serveurs proxy, ils doivent avoir la taille appropriée pour exécuter ces connexions.

Si la zone géographique du serveur proxy est éloignée de l’hôte, cette distance entraîne une latence plus élevée dans vos connexions utilisateur. Une latence plus élevée signifie un temps de connexion plus lent et une expérience utilisateur moins bonne, en particulier dans les scénarios qui nécessitent des interactions graphiques, audio ou à faible latence avec les périphériques d’entrée. Si vous devez utiliser un serveur proxy, gardez à l’esprit que vous devez placer le serveur dans la même zone géographique que l’agent et le client Azure Virtual Desktop.

Si vous configurez votre serveur proxy comme seul chemin d’accès pour le trafic Azure Virtual Desktop, les données RDP (Remote Desktop Protocol) sont forcées sur TCP (Transmission Control Protocol) au lieu du protocole UDP (User Datagram Protocol). Ce déplacement réduit la qualité visuelle et la réactivité de la connexion à distance.

En résumé, nous vous déconseillons d’utiliser des serveurs proxy sur Azure Virtual Desktop, car ils entraînent des problèmes de performances liés à la dégradation de la latence et à la perte de paquets.

Contournement d’un serveur proxy

Si les stratégies réseau et de sécurité de votre organization nécessitent des serveurs proxy pour le trafic web, vous pouvez configurer votre environnement pour contourner les connexions Azure Virtual Desktop tout en continuant à router le trafic via le serveur proxy. Toutefois, les stratégies de chaque organization étant uniques, certaines méthodes peuvent mieux fonctionner pour votre déploiement que d’autres. Voici quelques méthodes de configuration que vous pouvez essayer d’éviter une perte de performances et de fiabilité dans votre environnement :

• Balises de service Azure avec Pare-feu Azure
• Contournement du serveur proxy à l’aide des fichiers de configuration automatique du proxy (.PAC)
• Liste de contournement dans la configuration du proxy local
• Utilisation de serveurs proxy pour la configuration par utilisateur
• Utilisation de RDP Shortpath pour la connexion RDP tout en conservant le trafic de service sur le proxy

Recommandations relatives à l’utilisation des serveurs proxy

Certaines organisations exigent que tout le trafic utilisateur passe par un serveur proxy pour le suivi ou l’inspection des paquets. Cette section décrit comment nous vous recommandons de configurer votre environnement dans ces cas.

Utiliser des serveurs proxy dans la même zone géographique Azure

Lorsque vous utilisez un serveur proxy, il gère toutes les communications avec l’infrastructure Azure Virtual Desktop et effectue la résolution DNS et le routage Anycast vers l’instance Azure Front Door la plus proche. Si vos serveurs proxy sont distants ou distribués dans une zone géographique Azure, votre résolution géographique sera moins précise. Une résolution géographique moins précise signifie que les connexions seront routées vers un cluster Azure Virtual Desktop plus distant. Pour éviter ce problème, utilisez uniquement des serveurs proxy qui sont géographiquement proches de votre cluster Azure Virtual Desktop.

Utiliser RDP Shortpath pour les réseaux managés pour la connectivité de bureau

Lorsque vous activez RDP Shortpath pour les réseaux managés, les données RDP contournent le serveur proxy, si possible. Le contournement du serveur proxy garantit un routage optimal lors de l’utilisation du transport UDP. Les autres trafics Azure Virtual Desktop, tels que le répartiteur, l’orchestration et les diagnostics, transitent toujours par le serveur proxy.

N’utilisez pas l’arrêt SSL sur le serveur proxy

L’arrêt SSL (Secure Sockets Layer) remplace les certificats de sécurité des composants Azure Virtual Desktop par les certificats générés par le serveur proxy. Cette fonctionnalité de serveur proxy permet l’inspection des paquets pour le trafic HTTPS sur le serveur proxy. Toutefois, l’inspection des paquets augmente également le temps de réponse du service, ce qui rend la connexion des utilisateurs plus longue. Pour les scénarios de connexion inverse, l’inspection des paquets du trafic RDP n’est pas nécessaire, car le trafic RDP de connexion inverse est binaire et utilise des niveaux de chiffrement supplémentaires.

Si vous configurez votre serveur proxy pour utiliser l’inspection SSL, n’oubliez pas que vous ne pouvez pas rétablir son état d’origine après que l’inspection SSL a apporté des modifications. Si un élément de votre environnement Azure Virtual Desktop cesse de fonctionner alors que l’inspection SSL est activée, vous devez désactiver l’inspection SSL et réessayer avant d’ouvrir un cas de support. L’inspection SSL peut également entraîner l’arrêt du fonctionnement de l’agent Azure Virtual Desktop, car elle interfère avec les connexions approuvées entre l’agent et le service.

N’utilisez pas de serveurs proxy qui ont besoin d’une authentification

Les composants Azure Virtual Desktop sur l’hôte de session s’exécutent dans le contexte de leur système d’exploitation, de sorte qu’ils ne prennent pas en charge les serveurs proxy qui nécessitent une authentification. Si le serveur proxy nécessite une authentification, la connexion échoue.

Planifier la capacité réseau du serveur proxy

Les serveurs proxy ont des limites de capacité. Contrairement au trafic HTTP standard, le trafic RDP a des connexions longues et bavards qui sont bidirectionnelles et consomment beaucoup de bande passante. Avant de configurer un serveur proxy, contactez le fournisseur de votre serveur proxy pour connaître le débit dont dispose votre serveur. Veillez également à leur demander combien de sessions proxy vous pouvez exécuter en même temps. Après avoir déployé le serveur proxy, surveillez attentivement son utilisation des ressources pour identifier les goulots d’étranglement dans le trafic Azure Virtual Desktop.

Serveurs proxy et optimisation des médias Microsoft Teams

Azure Virtual Desktop ne prend pas en charge les serveurs proxy avec l’optimisation des médias pour Microsoft Teams.

Recommandations relatives à la configuration de l’hôte de session

Pour configurer un serveur proxy au niveau de l’hôte de session, vous devez activer un proxy à l’échelle du système. N’oubliez pas que la configuration à l’échelle du système d’exploitation affecte tous les composants et applications du système d’exploitation en cours d’exécution sur l’hôte de session. Les sections suivantes sont des recommandations pour la configuration des proxys à l’échelle du système.

Utiliser le protocole WPAD (Web Proxy Auto-Discovery)

L’agent Azure Virtual Desktop tente automatiquement de localiser un serveur proxy sur le réseau à l’aide du protocole WPAD (Web Proxy Auto-Discovery). Lors d’une tentative d’emplacement, l’agent recherche un fichier nommé wpad.domainsuffix dans le serveur de noms de domaine (DNS). Si l’agent trouve le fichier dans le DNS, il effectue une requête HTTP pour un fichier nommé wpad.dat. La réponse devient le script de configuration de proxy qui choisit le serveur proxy sortant.

Pour configurer votre réseau afin qu’il utilise la résolution DNS pour WPAD, suivez les instructions fournies dans Détection automatique des paramètres Internet Explorer 11. Assurez-vous que la liste de blocage des requêtes globales du serveur DNS autorise la résolution WPAD en suivant les instructions de Set-DnsServerGlobalQueryBlockList.

Définir manuellement un proxy à l’échelle de l’appareil pour les services Windows

Si vous spécifiez un serveur proxy manuellement, vous devez au minimum définir un proxy pour les services Windows RDAgent et les services Bureau à distance sur vos hôtes de session. RDAgent s’exécute avec le compte Système local et les services Bureau à distance s’exécutent avec le compte Service réseau. Vous pouvez définir un proxy pour ces comptes à l’aide de l’outil bitsadmin en ligne de commande.

L’exemple suivant configure les comptes Système local et Service réseau pour utiliser un fichier proxy .pac . Vous devez exécuter ces commandes à partir d’une invite de commandes avec élévation de privilèges, en modifiant la valeur de l’espace réservé pour <server> avec votre propre adresse :

bitsadmin /util /setieproxy LOCALSYSTEM AUTOSCRIPT http://<server>/proxy.pac
bitsadmin /util /setieproxy NETWORKSERVICE AUTOSCRIPT http://<server>/proxy.pac

Pour obtenir des informations de référence complètes et d’autres exemples, consultez bitsadmin util et setieproxy.

Vous pouvez également définir un proxy à l’échelle de l’appareil ou une configuration automatique de proxy (. PAC) qui s’applique à tous les utilisateurs interactifs, système local et service réseau. Si vos hôtes de session sont inscrits auprès d’Intune, vous pouvez définir un proxy avec le fournisseur de services de configuration proxy réseau. Toutefois, les systèmes d’exploitation clients windows multisession ne prennent pas en charge le csp Policy, car ils prennent uniquement en charge le catalogue de paramètres. Vous pouvez également configurer un proxy à l’échelle de l’appareil à l’aide de la netsh winhttp commande . Pour obtenir des informations de référence complètes et des exemples, consultez Commandes Netsh pour le protocole WINHTTP (Windows Hypertext Transfer Protocol)

Prise en charge du proxy côté client

Le client Azure Virtual Desktop prend en charge les serveurs proxy configurés avec des paramètres système ou un fournisseur de services de configuration de proxy réseau.

Prise en charge du client Azure Virtual Desktop

Le tableau suivant indique les clients Azure Virtual Desktop qui prennent en charge les serveurs proxy :

Pour plus d’informations sur la prise en charge des proxys sur les clients légers Linux, consultez Prise en charge des clients légers.

Limitations de la prise en charge

Il existe de nombreux services et applications tiers qui agissent en tant que serveur proxy. Ces services tiers incluent des pare-feu de nouvelle génération distribués, des systèmes de sécurité web et des serveurs proxy de base. Nous ne pouvons pas garantir que chaque configuration est compatible avec Azure Virtual Desktop. Microsoft fournit uniquement une prise en charge limitée des connexions établies sur un serveur proxy. Si vous rencontrez des problèmes de connectivité lors de l’utilisation d’un serveur proxy, le support Microsoft vous recommande de configurer un contournement de proxy, puis d’essayer de reproduire le problème.

Étapes suivantes

Pour plus d’informations sur la sécurisation de votre déploiement Azure Virtual Desktop, case activée notre guide de sécurité.