Scenari di rete supportati per i piani lab in Azure Lab Services
Importante
Azure Lab Services verrà ritirato il 28 giugno 2027. Per altre informazioni vedere la Guida al ritiro.
Con la rete avanzata di Azure Lab Services per i piani lab è possibile implementare diverse architetture di rete e topologie. Questo articolo elenca diversi scenari di rete e il relativo supporto in Azure Lab Services.
Scenari di rete
La tabella seguente elenca gli scenari di rete e le topologie comuni e il relativo supporto in Azure Lab Services.
Scenario | Attivata | Dettagli |
---|---|---|
Comunicazione da lab a lab | Sì | Altre informazioni sulla configurazione della comunicazione da lab a lab. Se gli utenti del lab necessitano di più macchine virtuali, è possibile configurare la virtualizzazione annidata. |
Aprire porte aggiuntive per la macchina virtuale del lab | No | Non è possibile aprire porte aggiuntive nella macchina virtuale del lab, anche con funzionalità di rete avanzate. |
Abilitare un server licenze distante, ad esempio in locale, tra aree | Sì | Aggiungere una route definita dall'utente che punta al server licenze. Se il software lab richiede la connessione al server licenze in base al nome anziché all'indirizzo IP, è necessario configurare un server DNS fornito dal cliente o aggiungere una voce al file hosts nel modello di lab.Se più servizi devono accedere al server licenze, usandoli da più aree o se il server licenze fa parte di un'altra infrastruttura, è possibile usare la procedura consigliata per la rete di Azure hub-spoke. |
Accesso alle risorse locali, ad esempio un server licenze | Sì | È possibile accedere alle risorse locali con queste opzioni: - Configurare Azure ExpressRoute o creare una connessione VPN da sito a sito (bridge delle reti). - Aggiungere un indirizzo IP pubblico al server locale con un firewall che consente solo le connessioni in ingresso da Azure Lab Services. Inoltre, per raggiungere le risorse locali dalle macchine virtuali del lab, aggiungere una route definita dall'utente. |
Usare un modello di rete hub-spoke | Sì | Questo scenario funziona come previsto con i piani lab e la rete avanzata. Alcune modifiche alla configurazione non sono supportate con Azure Lab Services, ad esempio l'aggiunta di una route predefinita in una tabella di route. Informazioni sulle modifiche alla configurazione della rete virtuale non supportate. |
Accedere alle macchine virtuali del lab in base all'indirizzo IP privato (lab solo privati) | Non consigliata | Questo scenario è funzionale, ma rende difficile per gli utenti del lab connettersi alla macchina virtuale del lab. Nel sito Web di Azure Lab Services gli utenti del lab non possono identificare l'indirizzo IP privato della macchina virtuale del lab. Inoltre, il pulsante di connessione punta all'endpoint pubblico della macchina virtuale lab. L'autore del lab deve fornire agli utenti del lab l'indirizzo IP privato delle macchine virtuali del lab. Dopo la ricreazione dell'immagine di una macchina virtuale, questo indirizzo IP privato potrebbe cambiare. Se si implementa questo scenario, non eliminare l'indirizzo IP pubblico o il servizio di bilanciamento del carico associato al lab. Se tali risorse vengono eliminate, il lab non riesce a ridimensionare o pubblicare. |
Proteggere le risorse locali con un firewall | Sì | È supportato l'inserimento di un firewall tra le macchine virtuali del lab e una risorsa specifica. |
Inserire le macchine virtuali del lab dietro un firewall. Ad esempio, per il filtro del contenuto, la sicurezza e altro ancora. | No | La configurazione tipica del firewall non funziona con Azure Lab Services, a meno che non si connetta alle macchine virtuali lab tramite indirizzo IP privato (vedere lo scenario precedente). Quando si configura il firewall, viene aggiunta una route predefinita nella tabella di route per la subnet. Questa route predefinita introduce un problema di routing asimmetrico, che interrompe le connessioni RDP/SSH al lab. |
Usare software di monitoraggio over-the-shoulder di terze parti | Sì | Questo scenario è supportato con funzionalità di rete avanzate per i piani lab. |
Usare un nome di dominio personalizzato per i lab, ad esempio lab1.labs.myuniversity.edu.au |
No | Questo scenario non funziona perché il nome di dominio completo viene definito al momento della creazione del lab, in base all'indirizzo IP pubblico del lab. Le modifiche apportate all'indirizzo IP pubblico non vengono propagate al pulsante di connessione per la macchina virtuale modello o le macchine virtuali del lab. |
Abilitare il tunneling forzato per i lab, in cui tutte le comunicazioni con le macchine virtuali del lab non passano tramite La rete Internet pubblica. Questo è noto anche come laboratori completamente isolati. | No | Questo scenario non funziona per impostazione predefinita. Non appena si associa una tabella di route alla subnet che contiene una route predefinita, gli utenti del lab perdono la connettività al lab. Per abilitare questo scenario, seguire la procedura per accedere alle macchine virtuali del lab in base all'indirizzo IP privato. |
Abilitare il filtro del contenuto | Dipende da | Scenari di filtro dei contenuti supportati: - Software di filtro del contenuto di terze parti nella macchina virtuale del lab: 1. Gli utenti del lab devono essere eseguiti come non amministratore per evitare la disinstallazione o la disabilitazione del software 2. Assicurarsi che le chiamate in uscita ad Azure non siano bloccate. - Filtro del contenuto basato su DNS: il filtro funziona con la rete avanzata e specifica il server DNS nella subnet del lab. È possibile usare un server DNS che supporta il filtro del contenuto per eseguire filtri basati su DNS. - Filtro del contenuto basato su proxy: il filtro funziona con la rete avanzata se le macchine virtuali del lab possono usare un server proxy fornito dal cliente che supporta il filtro del contenuto. Funziona in modo analogo alla soluzione basata su DNS. Filtro contenuto non supportato: - Appliance di rete (firewall): per altre informazioni, vedere lo scenario per l'inserimento di macchine virtuali lab dietro un firewall. Quando si pianifica una soluzione di filtro del contenuto, implementare un modello di verifica per assicurarsi che tutto funzioni come previsto end-to-end. |
Usare un broker di connessione, ad esempio Parsec, per scenari di gioco a framerate elevato | Non consigliata | Questo scenario non è supportato direttamente con Azure Lab Services e presenta le stesse problematiche dell'accesso alle macchine virtuali del lab tramite indirizzo IP privato. |
Scenario sul campo informatico, costituito da un set di macchine virtuali vulnerabili sulla rete per consentire agli utenti del lab di individuare e violare (hacking etico) | Sì | Questo scenario funziona con le funzionalità di rete avanzate per i piani lab. Informazioni sul tipo di classe di hacking etico. |
Abilitare l'uso di Azure Bastion per le macchine virtuali lab | No | Azure Bastion non è supportato in Azure Lab Services. |
Configurare line-of-sight sul controller di dominio | Non consigliata | La linea di visualizzazione da un lab a un controller di dominio è necessaria per l'aggiunta ibrida a Microsoft Entra o alle macchine virtuali di aggiunta a un dominio AD; Tuttavia, attualmente non è consigliabile che le macchine virtuali del lab siano aggiunte/registrate da Microsoft Entra, aggiunte a Microsoft entra ibride o aggiunte a un dominio AD a causa di limitazioni del prodotto. |
Passaggi successivi
- Connettere un piano lab a una rete virtuale con una rete avanzata
- Esercitazione: Configurare la comunicazione da lab a lab
- Inviare commenti e suggerimenti o richiedere nuove funzionalità nel sito della community di Azure Lab Services