Partager via

Scénarios de mise en réseau pris en charge pour les plans de labo dans Azure Lab Services

  • Article

Important

Azure Lab Services sera mis hors service le 28 juin 2027. Pour plus d’informations, consultez le guide de mise hors service.

Avec la mise en réseau avancée d’Azure Lab Services pour les plans de labo, vous pouvez implémenter différentes architectures réseau et topologies. Cet article répertorie différents scénarios de mise en réseau et leur prise en charge dans Azure Lab Services.

Scénarios réseau

Le tableau suivant répertorie les scénarios et topologies réseau courants et leur prise en charge dans Azure Lab Services.

Scénario Activé(e) Détails
Communication entre labos Oui En savoir plus sur la configuration de la communication entre labos. Si les utilisateurs du labo ont besoin de plusieurs machines virtuelles, vous pouvez configurer la virtualisation imbriquée.
Ouvrir des ports supplémentaires sur la machine virtuelle du labo Non Vous ne pouvez pas ouvrir d’autres ports sur la machine virtuelle du labo, même avec une mise en réseau avancée.
Activer le serveur de licences distant, tel que local ou interrégion Oui Ajoutez une route définie par l’utilisateur (UDR) qui pointe vers le serveur de licences.

Si le logiciel de labo nécessite la connexion au serveur de licences via son nom au lieu de l’adresse IP, vous devez configurer un serveur DNS fourni par le client ou ajouter une entrée au fichier hosts dans le modèle de labo.

Si plusieurs services ont besoin d’accéder au serveur de licences, en les utilisant à partir de plusieurs régions ou si le serveur de licences fait partie d’une autre infrastructure, vous pouvez utiliser la mise en réseau Azure hub-and-spoke.
Accès aux ressources locales, telles qu’un serveur de licences Oui Vous pouvez accéder aux ressources locales avec ces options :
– Configurez Azure ExpressRoute ou créez une connexion VPN de site à site (reliez les réseaux).
– Ajoutez une adresse IP publique à votre serveur local avec un pare-feu qui autorise uniquement les connexions entrantes à partir d’Azure Lab Services.

En outre, pour atteindre les ressources locales à partir des machines virtuelles du labo, ajoutez un itinéraire défini par l’utilisateur (UDR).
Utiliser un modèle de mise en réseau hub-and-spoke Oui Ce scénario fonctionne comme prévu avec les plans de labo et la mise en réseau avancée.

Un certain nombre de modifications de configuration ne sont pas prises en charge avec Azure Lab Services, comme l’ajout d’un itinéraire par défaut sur une table de routage. Découvrez les modifications de configuration de réseau virtuel non prises en charge.
Accéder aux machines virtuelles de labo via une adresse IP privée (labos privés uniquement) Non recommandé Ce scénario est fonctionnel, mais complique la connexion des utilisateurs du labo à leur machine virtuelle de labo. Sur le site web Azure Lab Services, les utilisateurs du labo ne peuvent pas identifier l’adresse IP privée de leur machine virtuelle de labo. En outre, le bouton de connexion pointe vers le point de terminaison public de la machine virtuelle de labo. Le créateur du labo doit fournir aux utilisateurs du labo l’adresse IP privée de leurs machines virtuelles de labo. Cette adresse IP privée peut changer après une réinitialisation de machine virtuelle.

Si vous implémentez ce scénario, ne supprimez pas l’adresse IP publique ou l’équilibreur de charge associé au labo. Si ces ressources sont supprimées, la mise à l’échelle ou la publication du labo échouent.
Protéger des ressources locales avec un pare-feu Oui La mise en place d’un pare-feu entre les machines virtuelles de labo et une ressource spécifique est prise en charge.
Placez des machines virtuelles de labo derrière un pare-feu. Par exemple, pour le filtrage de contenu, la sécurité et bien plus encore. Non La configuration classique du pare-feu ne fonctionne pas avec Azure Lab Services, sauf si vous vous connectez à des machines virtuelles de labo par adresse IP privée (consultez le scénario précédent).

Lorsque vous configurez le pare-feu, un itinéraire par défaut est ajouté sur la table de routage du sous-réseau. Cet itinéraire par défaut introduit un problème de routage asymétrique, qui interrompt les connexions RDP/SSH au labo.
Utiliser un logiciel de surveillance par procuration de privilège Oui Ce scénario est pris en charge avec la mise en réseau avancée pour les plans de labo.
Utilisez un nom de domaine personnalisé pour les labos, par exemple lab1.labs.myuniversity.edu.au Non Ce scénario ne fonctionne pas, car le nom de domaine complet est défini lors de la création du labo, en fonction de l’adresse IP publique du labo. Les modifications apportées à l’adresse IP publique ne sont pas propagées au bouton de connexion pour le modèle de machine virtuel ou les machines virtuelles du labo.
Activez le tunneling forcé pour les labos, où toutes les communications vers les machines virtuelles de labos ne passeront pas par l’Internet public. C’est également ce qu’on appelle les labos entièrement isolés. Non Ce scénario ne fonctionne pas tel quel. Dès que vous associez une table de routage au sous-réseau qui contient un itinéraire par défaut, les utilisateurs du labo perdent la connectivité au labo.
Pour activer ce scénario, suivez les étapes d’accès aux machines virtuelles de labo via une adresse IP privée.
Activer le filtrage du contenu Dépend Scénarios de filtrage du contenu pris en charge :
– Logiciel de filtrage de contenu tiers sur la machine virtuelle de labo :
    1. Les utilisateurs du labo doivent s’exécuter en tant que non-administrateurs pour éviter de désinstaller ou de désactiver le logiciel
    2. Vérifiez que les appels sortants vers Azure ne sont pas bloqués.

– Filtrage de contenu basé sur DNS : le filtrage fonctionne avec la mise en réseau avancée et en spécifiant le serveur DNS sur le sous-réseau du labo. Vous pouvez utiliser un serveur DNS qui prend en charge le filtrage de contenu pour effectuer un filtrage basé sur DNS.

– Filtrage de contenu basé sur le proxy : le filtrage fonctionne avec la mise en réseau avancée si les machines virtuelles de labo peuvent utiliser un serveur proxy fourni par le client qui prend en charge le filtrage de contenu. Il fonctionne de la même manière que la solution basée sur DNS.

Filtrage de contenu non pris en charge :
– Appliance réseau (pare-feu) : pour plus d’informations, consultez le scénario de mise en place de machines virtuelles de labo derrière un pare-feu.

Lors de la planification d’une solution de filtrage de contenu, implémentez une preuve de concept pour vous assurer que tout fonctionne comme prévu de bout en bout.
Utiliser un répartiteur de connexion, tel que Parsec, pour les scénarios de jeux à débit élevé Non recommandé Ce scénario ne dispose pas directement d’une prise en charge Azure Lab Services et rencontrerait les mêmes obstacles que l’accès aux machines virtuelles de labo via une adresse IP privée.
Scénario de cyberchamp, composé d’un ensemble de machines virtuelles vulnérables sur le réseau pour que les utilisateurs du labo le découvrent et le piratent (piratage éthique) Oui Ce scénario fonctionne avec la mise en réseau avancée pour les plans de labo. Découvrez-en davantage sur le type de classe de piratage éthique.
Activer l’utilisation d’Azure Bastion pour les machines virtuelles de labo Non Azure Bastion n’est pas pris en charge dans Azure Lab Services.
Configurer la ligne de vue sur le contrôleur de domaine Non recommandé La ligne de vue d’un labo vers un contrôleur de domaine est requise pour les machines virtuelles de jointure hybride Microsoft Entra ou de jonction de domaine AD. Toutefois, nous déconseillons de joindre ou d’inscrire des machines virtuelles de labo à Microsoft Entra, de les joindre de manière hybride à Microsoft Entra ou de les joindre à un domaine AD en raison des limitations du produit.

Étapes suivantes