Share via

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

  • Article

Avec la mise en réseau avancée d’Azure Lab Services pour les plans lab, 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 Enabled Détails
Communication lab-à-lab Oui En savoir plus sur la configuration de la communication lab-à-lab. Si les utilisateurs du laboratoire ont besoin de plusieurs machines virtuelles, vous pouvez configurer la virtualisation imbriquée.
Ouvrir des ports supplémentaires sur la machine virtuelle lab Non Vous ne pouvez pas ouvrir d’autres ports sur la machine virtuelle lab, même avec une mise en réseau avancée.
Activer le serveur de licences distant, tel que local, interrégion Oui Ajoutez un itinéraire défini par l’utilisateur qui pointe vers le serveur de licences.

Si le logiciel lab nécessite la connexion au serveur de licences par 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 dans le hosts modèle lab.

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 meilleure pratique de 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 (pontez 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 laboratoire, 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 laboratoire 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 du labo par adresse IP privée (laboratoires privés uniquement) Non recommandé Ce scénario est fonctionnel, mais rend difficile pour les utilisateurs du labo de se connecter à leur machine virtuelle lab. Sur le site web Azure Lab Services, les utilisateurs du labo ne peuvent pas identifier l’adresse IP privée de leur machine virtuelle lab. En outre, le bouton de connexion pointe vers le point de terminaison public de la machine virtuelle lab. Le créateur du labo doit fournir aux utilisateurs du labo l’adresse IP privée de leurs machines virtuelles de laboratoire. Une fois qu’une machine virtuelle est réimage, cette adresse IP privée peut changer.

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, le labo ne parvient pas à mettre à l’échelle ou publier.
Protéger les ressources locales avec un pare-feu Oui La mise en place d’un pare-feu entre les machines virtuelles de laboratoire et une ressource spécifique est prise en charge.
Placez des machines virtuelles lab 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 laboratoire par adresse IP privée (voir 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 de l’épaule tiers Oui Ce scénario est pris en charge avec la mise en réseau avancée pour les plans de laboratoire.
Utiliser un nom de domaine personnalisé pour les laboratoires, 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 la machine virtuelle modèle ou les machines virtuelles du labo.
Activez le tunneling forcé pour les laboratoires, où toutes les communications vers les machines virtuelles de laboratoire ne passent pas par l’Internet public. C’est également ce que l’on appelle des laboratoires entièrement isolés. Non Ce scénario ne fonctionne pas. 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 laboratoire par adresse IP privée.
Activer le filtrage de contenu Dépend Scénarios de filtrage de contenu pris en charge :
- Logiciel de filtrage de contenu tiers sur la machine virtuelle lab :
    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 lab peuvent utiliser un serveur proxy fourni par le client qui prend en charge le filtrage de contenu. Il fonctionne de la même façon 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 laboratoire 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 n’est pas directement pris en charge avec Azure Lab Services et rencontrerait les mêmes défis que l’accès aux machines virtuelles de laboratoire par adresse IP privée.
Scénario de cyber-champ , constitué d’un ensemble de machines virtuelles vulnérables sur le réseau pour que les utilisateurs du laboratoire découvrent et piratent (piratage éthique) Oui Ce scénario fonctionne avec la mise en réseau avancée pour les plans de laboratoire. Découvrez le type de classe de piratage éthique.
Activer l’utilisation d’Azure Bastion pour les machines virtuelles de laboratoire 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 laboratoire 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 vous déconseillons actuellement de ne pas recommander que les machines virtuelles lab soient jointes/inscrites à Microsoft Entra, jointes à l’hybride Microsoft Entra ou jointes à un domaine AD en raison des limitations du produit.

Étapes suivantes