adresses IP de communication de l’infrastructure Azure

les hôtes de session Azure Virtual Desktop (AVD) et les PC cloud Windows 365 nécessitent une connectivité à deux adresses IP Azure plateforme. Ces adresses permettent d’accéder aux services d’infrastructure de base qui prennent en charge l’approvisionnement, la surveillance de l’intégrité, l’identité et la communication de la plateforme.

Le trafic vers ces adresses fonctionne au niveau de l’infrastructure de la plateforme Azure. Il se comporte différemment du trafic aux points de terminaison basés sur le nom de domaine complet et doit être géré en conséquence.

Cet article explique ce que sont ces adresses IP, pourquoi elles sont essentielles, en quoi elles diffèrent des autres points de terminaison et comment garantir la réussite de la connectivité.

Vue d’ensemble

Azure hôtes de session Virtual Desktop et les PC cloud Windows 365 nécessitent une connectivité aux adresses IP suivantes :

Azure Instance Metadata Service (169.254.169.254)

Azure Instance Metadata Service (IMDS) est un point de terminaison d’API REST qui fournit des informations sur une machine virtuelle en cours d’exécution. Les logiciels à l’intérieur de la machine virtuelle utilisent IMDS pour s’intégrer à l’environnement Azure.

Les machines virtuelles utilisent IMDS pour récupérer :

• Données de configuration et d’identité de machine virtuelle

• Jetons d’identité managée pour l’authentification auprès des services Azure

• Événements planifiés et notifications de maintenance

• Métadonnées telles que la région, la zone de disponibilité, la taille de machine virtuelle et la configuration réseau

L’adresse 169.254.169.254 est une adresse IP locale de lien. Il n’est pas routable et accessible uniquement à partir de la machine virtuelle. Les demandes adressées à cette adresse ne quittent jamais l’hôte physique. L’hyperviseur Azure intercepte et répond au trafic localement.

IMDS fonctionne au niveau de l’hyperviseur. Il n’est pas affecté par les groupes de sécurité réseau, les itinéraires définis par l’utilisateur ou les règles de Pare-feu Azure. Toutefois, la configuration du système d’exploitation à l’intérieur de la machine virtuelle, telle que les pare-feu hôtes ou les clients VPN, peut bloquer l’accès.

Surveillance de l’intégrité de la plateforme Azure (168.63.129.16)

L’adresse 168.63.129.16 est une adresse IP publique virtuelle utilisée par Azure services de plateforme pour communiquer avec les machines virtuelles. Cette adresse est également appelée point de terminaison WireServer.

Les machines virtuelles utilisent cette adresse pour :

• Surveillance de l’intégrité et communication par pulsation à partir de l’agent de machine virtuelle Azure

• Résolution DNS lors de l’utilisation du DNS fourni par Azure

• Communication DHCP pour l’attribution et le renouvellement d’adresses IP

Le trafic vers 168.63.129.16 traverse l’infrastructure de réseau virtuel Azure. Azure routage de plateforme applique une gestion spéciale pour garantir que l’adresse reste accessible dans les réseaux avec des configurations de routage ou de sécurité restrictives.

Différences par rapport aux points de terminaison standard

Azure Virtual Desktop et Windows 365 également besoin d’une connectivité aux points de terminaison FQDN, tels que les services de plan de contrôle, les Microsoft Entra ID, etc. Le trafic vers ces points de terminaison se comporte comme un trafic Internet standard vers des adresses IP publiques. Une partie de ce trafic, comme RDP, nécessite une optimisation dans les réseaux clients, mais peut généralement être traité comme des points de terminaison publics normaux.

Toutefois, le trafic vers 169.254.169.254 et 168.63.129.16 se comporte différemment.

• Azure interne et non routable. Ces adresses font partie de Azure’infrastructure de plateforme interne. Il ne s’agit pas de points de terminaison Internet, ne sont pas résolus via le DNS public et ne sont pas accessibles à partir de Azure externes ou de réseaux locaux.

• Ils ne peuvent pas être proxiés, car les serveurs proxy ne sont pas en mesure d’atteindre ces adresses. Les tentatives d’envoi de ce trafic via un proxy échouent, que ce soit via des fichiers PAC, des stratégie de groupe ou des paramètres de proxy d’application.

• Ils ne peuvent pas traverser les tunnels VPN ou les passerelles web sécurisées. Les clients VPN et les agents de passerelle web sécurisés qui fonctionnent en mode tunnel complet ou tunnel forcé capturent tout le trafic de la machine virtuelle. Lorsqu’ils capturent le trafic vers ces adresses, la connectivité échoue, car les adresses ne sont pas accessibles via des tunnels VPN ou une infrastructure de sécurité tierce.

• Partiellement protégé par Azure routage de plateforme. Azure mise en réseau comprend des protections pour garantir la connectivité à ces adresses au niveau de la couche fabric. Les itinéraires par défaut tels que 0.0.0.0/0 et la plupart des règles de groupe de sécurité réseau ne bloquent pas ce trafic. Toutefois, ces protections ne s’appliquent pas à la configuration à l’intérieur de la machine virtuelle ou aux règles de réseau explicites qui ciblent ces adresses ou leurs étiquettes de service.

Il est donc essentiel de vous assurer que les problèmes de configuration suivants ne sont pas présents dans votre environnement :

Problèmes de configuration dans la machine virtuelle

La plupart des problèmes de connectivité sont dus à la configuration à l’intérieur de la machine virtuelle plutôt qu’à Azure configuration de la couche réseau.

Clients VPN et agents de passerelle web sécurisée

Les organisations déploient des clients VPN ou des agents de passerelle web sécurisés sur des PC cloud et des hôtes de session pour appliquer des stratégies de sécurité. Par exemple, Zscaler Internet Access, Accès Internet Microsoft Entra, PaloAlto Global Protect, etc.

Lorsque ces agents s’exécutent en mode tunnel forcé, ils redirigent tout le trafic via une carte virtuelle. Cette configuration peut inclure le trafic vers Azure adresses de plateforme, ce qui interrompt la connectivité.

Ce qu’il faut case activée :

• Utilisez le tunneling fractionné pour que Azure trafic de la plateforme reste local

• Configurer des règles de contournement ou d’exclusion explicites pour 169.254.169.254 et 168.63.129.16

Configuration du proxy et du pac

Les paramètres de proxy appliqués via des fichiers PAC, stratégie de groupe, WinHTTP, WinINET ou des paramètres spécifiques à l’application peuvent entraîner le proxy de la machine virtuelle Azure trafic de la plateforme.

Ce qu’il faut case activée :

• Les fichiers PAC retournent une connexion directe pour ces adresses

• Les listes de contournement de proxy incluent les deux adresses

• Les paramètres de proxy au niveau de l’utilisateur et de l’ordinateur sont examinés

Règles de pare-feu d’hôte

Les pare-feu basés sur l’hôte ou les logiciels de protection des points de terminaison peuvent bloquer le trafic TCP sortant.

Ce qu’il faut case activée :

• Autoriser le trafic TCP sortant vers 169.254.169.254 sur le port 80

• Autoriser le trafic TCP sortant vers 168.63.129.16 sur les ports 80 et 32526

Logiciel de sécurité des points de terminaison et de filtrage réseau

L’antivirus, les détections de points de terminaison & response (EDR) ou les outils de protection contre la perte de données (DLP) peuvent inclure des fonctionnalités d’inspection réseau.

Ce qu’il faut case activée :

• Vérifiez que ces outils ne bloquent pas ou n’inspectent pas le trafic vers ces adresses

• Ajouter des règles d’autorisation ou d’exclusion basées sur IP si nécessaire

Azure problèmes de configuration de la couche réseau

Groupes de sécurité réseau

Azure définit des étiquettes de service pour ces points de terminaison :

• AzurePlatformIMDS pour 169.254.169.254

• AzurePlatformDNS pour 168.63.129.16

Les règles de refus explicites ciblant ces balises de service peuvent interférer avec la connectivité.

Ce qu’il faut case activée :

• Supprimer les règles de refus ciblant ces balises ou adresses de service

• Vérifier que les règles de trafic sortant refus tout restrictives incluent des règles d’autorisation explicites pour ces balises de service

Itinéraires définis par l’utilisateur et appliances virtuelles réseau

Azure routage de plateforme garantit normalement l’accessibilité, quels que soient les itinéraires par défaut. Toutefois, des itinéraires explicites ou des topologies de routage complexes peuvent entraîner des problèmes.

Ce qu’il faut case activée :

• Aucun itinéraire ne cible explicitement 169.254.169.254 ou 168.63.129.16

• Les pare-feu ou appliances virtuelles réseau dans le chemin autorisent le trafic sortant vers ces adresses et ports

Azure vérifications de l’intégrité de la connexion réseau

Windows 365 Entreprise utilise Azure connexions réseau pour provisionner des PC cloud. Chaque connexion inclut des vérifications d’intégrité automatisées qui valident la connectivité réseau.

Quels sont les contrôles d’intégrité validés

• Connectivité de l’infrastructure réseau aux points de terminaison de plateforme Azure

• Configuration du groupe de sécurité réseau

• Configuration de la table de routage

• Résolution DNS à l’aide du DNS fourni par Azure

Quels sont les contrôles d’intégrité qui ne valident pas

• Clients VPN ou agents de passerelle web sécurisés installés après l’approvisionnement

• Configuration du proxy ou du pac appliquée via stratégie de groupe ou Intune

• Règles de pare-feu d’hôte ou logiciel de sécurité de point de terminaison

• Configuration appliquée à l’intérieur de la machine virtuelle après l’affectation

Un case activée d’intégrité de passage confirme que le réseau Azure autorise le trafic de la plateforme. Cela ne garantit pas que les PC cloud ou les hôtes de session peuvent atteindre ces points de terminaison après l’application de la configuration dans la machine virtuelle.

Résumé

La connectivité à 169.254.169.254 et 168.63.129.16 est requise pour Azure Virtual Desktop et Windows 365. Le blocage de ces points de terminaison entraîne des problèmes d’approvisionnement et d’exploitation avec Windows 365 et Azure Virtual Desktop.

Ces adresses sont des points de terminaison de plateforme internes Azure. Le trafic vers ces adresses ne doit pas être proxié, intercepté ou routé via des tunnels VPN ou des passerelles web sécurisées.

La plupart des échecs de connectivité sont dus à la configuration à l’intérieur de la machine virtuelle, comme les clients VPN, les paramètres de proxy, les pare-feu hôtes ou les logiciels de sécurité de point de terminaison. Les problèmes de couche réseau sont moins courants, mais peuvent se produire lorsque des règles explicites ciblent ces adresses ou leurs étiquettes de service.

Azure vérifications de l’intégrité de la connexion réseau valident uniquement la connectivité de la couche réseau. Ils ne détectent pas les problèmes de configuration dans la machine virtuelle.