Unterstützte Netzwerkszenarien für Laborpläne in Azure Lab Services
Wichtig
Azure Lab Services wird am 28. Juni 2027 eingestellt. Weitere Informationen finden Sie im Einstellungsleitfaden.
Mit erweiterten Netzwerken für Laborpläne in Azure Lab Services können Sie verschiedene Netzwerkarchitekturen und Topologien implementieren. In diesem Artikel werden verschiedene Netzwerkszenarien und deren Support in Azure Lab Services aufgeführt.
Szenarien für den Netzwerkbetrieb
In der folgenden Tabelle sind allgemeine Netzwerkszenarien und Topologien sowie deren Support in Azure Lab Services aufgeführt.
Szenario | Aktiviert | Details |
---|---|---|
Lab-zu-Lab-Kommunikation | Ja | Erfahren Sie mehr über Einrichten der Lab-zu-Lab-Kommunikation. Wenn Lab-Benutzer mehrere virtuelle Computer benötigen, können Sie die geschachtelte Virtualisierungkonfigurieren. |
Öffnen zusätzlicher Ports für die Lab-VM | No | Sie können keine zusätzlichen Ports auf der Lab-VM öffnen, auch nicht mit erweiterten Netzwerken. |
Aktivieren eines entfernten Lizenzservers, z. B. lokal, regionsübergreifend | Ja | Fügen Sie eine benutzerdefinierte Route (User Defined Route, UDR) hinzu, die auf den Lizenzserver verweist. Wenn die Lab-Software eine Verbindung mit dem Lizenzserver anhand des Namens anstelle der IP-Adresse herstellen muss, müssen Sie einen vom Kunden bereitgestellten DNS-Server konfigurieren oder der hosts -Datei in der Lab-Vorlage einen Eintrag hinzufügen.Wenn mehrere Dienste Zugriff auf den Lizenzserver benötigen, sie aus mehreren Regionen verwenden oder der Lizenzserver Teil einer anderen Infrastruktur ist, können Sie die bewährte Hub-and-Spoke-Methode für Azure-Netzwerke verwenden. |
Zugriff auf lokale Ressourcen, z. B. einen Lizenzserver | Ja | Sie können mit den folgenden Optionen auf lokale Ressourcen zugreifen: – Konfigurieren von Azure ExpressRoute oder Erstellen einer Standort-zu-Standort-VPN-Verbindung (Überbrücken der Netzwerke). – Fügen Sie Ihrem lokalen Server eine öffentliche IP mit einer Firewall hinzu, die nur eingehende Verbindungen von Azure Lab Services zulässt. Um die lokalen Ressourcen von den virtuellen Labor-Computern zu erreichen, fügen Sie außerdem eine benutzerdefinierte Route (User Defined Route, UDR) hinzu. |
Verwenden eines Hub-and-Spoke-Netzwerk-Modells | Ja | Dieses Szenario funktioniert wie erwartet mit Lab-Plänen und erweiterten Netzwerken. Eine Reihe von Konfigurationsänderungen wird bei Azure Lab Services nicht unterstützt, z. B. das Hinzufügen einer Standardroute in einer Routentabelle. Weitere Informationen über die Änderungen der nicht unterstützten virtuellen Netzwerkkonfigurationen. |
Aufrufen von Lab-VMs anhand privater IP-Adressen (nur private Labs) | Nicht empfohlen | Dieses Szenario ist funktionsfähig, macht es aber für Lab-Benutzer schwierig, eine Verbindung mit ihrer Labor-VM herzustellen. Auf der Azure Lab Services-Website können Lab-Benutzer die private IP-Adresse ihrer Lab-VM nicht identifizieren. Darüber hinaus verweist die Schaltfläche „Verbinden“ auf den öffentlichen Endpunkt des Lab-VM. Der Ersteller des Labors muss Lab-Benutzern die private IP-Adresse ihrer Lab-VMs bereitstellen. Nach einem VM-Reimaging kann sich diese private IP-Adresse ändern. Wenn Sie dieses Szenario implementieren, löschen Sie nicht die öffentliche IP-Adresse oder das Lastenausgleichsmodul, das dem Lab zugeordnet ist. Wenn diese Ressourcen gelöscht werden, kann das Lab nicht skaliert oder veröffentlicht werden. |
Schützen lokaler Ressourcen mit einer Firewall | Ja | Das Platzieren einer Firewall zwischen den Lab-VM und einer bestimmten Ressource wird unterstützt. |
Platzieren Sie Lab-VMs hinter einer Firewall. Beispiel für Inhaltsfilterung, Sicherheit und mehr. | No | Die typische Firewalleinrichtung funktioniert nicht mit Azure Lab Services, es sei denn, beim Herstellen einer Verbindung mit Lab-VMs über die private IP-Adresse (siehe vorheriges Szenario). Wenn Sie die Firewall einrichten, wird in der Routentabelle für das Subnetz eine Standardroute hinzugefügt. Diese Standardroute führt zu einem asymmetrischen Routingproblem, das die RDP-/SSH-Verbindungen mit dem Labor aufbricht. |
Verwenden der Mitschnitt-Überwachungssoftware von Drittanbietern | Ja | Dieses Szenario wird mit erweiterten Netzwerken für Lab-Pläne unterstützt. |
Verwenden eines benutzerdefinierten Domänennamen für Labs. Beispiel: lab1.labs.myuniversity.edu.au |
No | Dieses Szenario funktioniert nicht, da der FQDN beim Erstellen des Lab basierend auf der öffentlichen IP-Adresse des Labs definiert ist. Änderungen an der öffentlichen IP-Adresse werden nicht an die Schaltfläche „Verbinden“ für die Vorlagen-VM oder die Lab-VMs weitergegeben. |
Aktivieren Sie erzwungenes Tunneln für Labore, bei denen die gesamte Kommunikation mit Lab-VMs nicht über das öffentliche Internet erfolgt. Diese werden auch als vollständig isolierte Labs bezeichnet. | No | Dieses Szenario funktioniert nicht sofort. Sobald Sie dem Subnetz, das eine Standardroute enthält, eine Routentabelle zuordnen, verlieren Lab-Benutzer die Verbindung zum Labor. Um dieses Szenario zu aktivieren, führen Sie die Schritte für den Zugriff auf Lab-VMs anhand der privaten IP-Adresse aus. |
Inhaltsfilterung aktivieren | Depends (Abhängig) | Unterstützte Inhaltsfilterszenarien: - Inhaltsfiltersoftware von Drittanbietern auf der Lab-VM: 1. Lab-Benutzer sollten Anwendungen als nichtadmin ausführen, um zu vermeiden, dass die Software deinstalliert oder deaktiviert wird. 2. Stellen Sie sicher, dass ausgehende Anrufe an Azure nicht blockiert werden. – DNS-basierte Inhaltsfilterung: Die Filterung funktioniert mit erweiterten Netzwerken und gibt den DNS-Server im Subnetz des Labors an. Sie können einen DNS-Server verwenden, der die Inhaltsfilterung unterstützt, um die DNS-basierte Filterung zu erledigen. – Proxybasierte Inhaltsfilterung: Das Filtern funktioniert mit erweiterten Netzwerken, wenn die Lab-VMs einen vom Kunden bereitgestellten Proxyserver verwenden können, der die Inhaltsfilterung unterstützt. Es funktioniert ähnlich wie die DNS-basierte Lösung. Nicht unterstützte Inhaltsfilter: – Netzwerk-Appliance (Firewall): Weitere Informationen finden Sie im Szenario zum Platzieren von Lab-VMs hinter einer Firewall. Implementieren Sie bei der Planung einer Inhaltsfilterlösung einen Machbarkeitsnachweis, um sicherzustellen, dass alles wie erwartet endet. |
Verwenden eines Verbindungsbrokers, z. B. Parsec, für Spielszenarien mit hoher Framerate | Nicht empfohlen | Dieses Szenario wird nicht direkt mit Azure Lab Services unterstützt und hätte die gleichen Herausforderungen wie der Zugriff auf Lab-VMs anhand der privaten IP-Adresse. |
Cyber-Feld-Szenario, das aus einer Reihe anfälliger VMs im Netzwerk besteht, um Lab-Benutzer zu entdecken und zu hacken (ethisches Hacken) | Ja | Dieses Szenario funktioniert mit erweiterten Netzwerken für Lab-Pläne. Erfahren Sie mehr über den Klassentyp für ethisches Hacken. |
Azure Bastion für Lab-VMs aktivieren | No | Azure Bastion wird in Azure Lab Services nicht unterstützt. |
Sichtverbindung zum Domänencontroller einrichten | Nicht empfohlen | Sichtverbindung von einem Labor zu einem Domänencontroller ist für die Microsoft Entra-Hybridbeitritts- oder AD-Domänenbeitritts-VMs erforderlich. Wir empfehlen derzeit jedoch aufgrund von Produktbeschränkungen nicht, dass Lab-VMs Microsoft Entra beitreten/dort registriert bzw. mit der Microsoft Entra Hybrid- oder der AD-Domäne verbunden werden. |
Nächste Schritte
- Verbinden eines Lab-Plans mit einem virtuellen Netzwerk mit erweiterten Netzwerken
- Tutorial: Einrichten der Lab-zu-Lab-Kommunikation
- Bereitstellen von Feedback oder Anfordern neuer Features auf der Azure Lab Services-Communitywebsite