Requisiti di rete di Microsoft Dev Box
Microsoft Dev Box è un servizio che consente agli utenti di connettersi a una workstation basata sul cloud in esecuzione su Azure tramite Internet, da qualsiasi dispositivo, ovunque esso si trovi. Per supportare queste connessioni Internet, è necessario rispettare i requisiti di rete elencati in questo articolo. È consigliabile collaborare con il team di rete e il team di sicurezza della propria organizzazione per pianificare e implementare l'accesso alla rete per le macchine di sviluppo.
Microsoft Dev Box è strettamente correlato ai servizi Desktop virtuale Azure e Windows 365, e in molti casi i requisiti di rete sono gli stessi.
Requisiti di rete generali
Le finestre di sviluppo richiedono una connessione di rete per accedere alle risorse. È possibile scegliere tra una connessione di rete ospitata da Microsoft e una connessione di rete di Azure creata nella propria sottoscrizione. La scelta di un metodo per consentire l'accesso alle risorse di rete dipende dalla posizione in cui si trovano le risorse.
Quando si usa una connessione ospitata da Microsoft:
- Microsoft fornisce e gestisce completamente l'infrastruttura.
- È possibile gestire la sicurezza delle macchine di sviluppo da Microsoft Intune.
Per usare la propria rete e effettuare il provisioning delle macchine di sviluppo aggiunte a Microsoft Entra, è necessario soddisfare i requisiti seguenti:
- Rete virtuale di Azure: è necessario avere una rete virtuale nella propria sottoscrizione di Azure. L'area selezionata per la rete virtuale è la posizione in cui Azure distribuisce le macchine di sviluppo.
- Una subnet nella rete virtuale e lo spazio indirizzi IP disponibile.
- Larghezza di banda della rete: vedere Linee guida per la rete di Azure.
Per usare la propria rete e effettuare il provisioning delle macchine di sviluppo ibride aggiunte a Microsoft Entra, è necessario soddisfare i requisiti sopra indicati e seguire i requisiti di seguenti:
- La rete virtuale di Azure deve essere in grado di risolvere le voci DNS (Domain Name Services) per l'ambiente Active Directory Domain Services (AD DS). Per supportare questa risoluzione, definire i server DNS di Active Directory Domain Services come server DNS per la rete virtuale.
- La rete virtuale di Azure deve avere accesso di rete a un controller di dominio aziendale, in Azure o in locale.
Importante
Quando si usa la propria rete, Microsoft Dev Box attualmente non supporta lo spostamento delle interfacce di rete in una rete virtuale diversa o in una subnet diversa.
Consentire la connettività di rete
Nella configurazione di rete è necessario consentire il traffico verso gli URL e le porte del servizio seguenti per supportare il provisioning, la gestione e la connettività remota delle macchine di sviluppo.
FQDN ed endpoint necessari per Microsoft Dev Box
Per configurare le macchine di sviluppo e consentire agli utenti di connettersi alle risorse, è necessario consentire il traffico per specifici nomi di dominio completi (FQDN) ed endpoint. Questi FQDN ed endpoint potrebbero essere bloccati se si usa un firewall, ad esempio Firewall di Azure o un servizio proxy.
È possibile verificare che le macchine di sviluppo possano connettersi a questi FQDN ed endpoint seguendo la procedura per eseguire lo strumento URL agente desktop virtuale Azure in Controllare l'accesso ai nomi di dominio completi e agli endpoint necessari per Desktop virtuale Azure. Lo strumento URL agente desktop virtuale Azure convalida ogni FQDN ed endpoint e mostra se le macchine di sviluppo possono accedervi.
Importante
Microsoft non supporta le distribuzioni di macchine di sviluppo in cui i nomi di dominio completo e gli endpoint elencati in questo articolo sono bloccati.
Usare tag FQDN e tag di servizio per gli endpoint tramite Firewall di Azure
La gestione dei controlli di sicurezza di rete per le macchine di sviluppo può essere complessa. Per semplificare la configurazione, usare tag del nome di dominio completo (FQDN) e tag del servizio per consentire il traffico di rete.
Tag FQDN
Un tag FQDN è un tag predefinito in Firewall di Azure che rappresenta un gruppo di nomi di dominio completi. Usando i tag FQDN, è possibile creare e gestire facilmente regole in uscita per servizi specifici come Windows 365 senza specificare manualmente ogni nome di dominio.
I raggruppamenti definiti dai tag FQDN possono sovrapporsi. Ad esempio, il tag FQDN di Windows365 include endpoint AVD per porte standard, vedi informazioni di riferimento.
I firewall non Microsoft in genere non supportano tag del FQDN o tag del servizio. Potrebbe esserci un termine diverso per la stessa funzionalità; controllare la documentazione del firewall.
Tag di servizio
Un tag del servizio rappresenta un gruppo di prefissi di indirizzi IP di un determinato servizio di Azure. Microsoft gestisce i prefissi di indirizzo inclusi nel tag del servizio e aggiorna automaticamente il tag in base alla modifica degli indirizzi, riducendo la complessità degli aggiornamenti frequenti alle regole di sicurezza di rete. I tag di servizio possono essere usati sia nelle regole del gruppo di sicurezza di rete (NSG) che in quelle del Firewall di Azure per limitare l'accesso alla rete in uscita, e in Route definita dall'utente (UDR) per personalizzare il comportamento di routing del traffico.
Endpoint necessari per la connettività di rete dei dispositivi fisici
Sebbene la maggior parte della configurazione riguardi la rete di macchine di sviluppo basata sul cloud, la connettività degli utenti finali avviene da un dispositivo fisico. Pertanto, è necessario seguire anche le linee guida sulla connettività nella rete fisica del dispositivo.
| Dispositivo o servizio | URL e porte necessarie per la connettività di rete | Descrizione | Obbligatorio? |
|---|---|---|---|
| Dispositivo fisico | Collegamento | Connettività e aggiornamenti del client Desktop remoto. | Sì |
| Servizio Microsoft Intune | Collegamento | Servizi cloud di Intune come la gestione dei dispositivi, la distribuzione delle applicazioni e l'analisi degli endpoint. | Sì |
| Macchina virtuale host di sessione di Desktop virtuale Azure | Collegamento | Connettività remota tra le macchine di sviluppo e il servizio Desktop virtuale Azure back-end. | Sì |
| Servizio Windows 365 | Collegamento | Provisioning e controlli di integrità. | Sì |
Qualsiasi dispositivo usato per connettersi a una casella di sviluppo deve avere accesso ai nomi di dominio completi e agli endpoint seguenti. Consentire questi FQDN ed endpoint è essenziale per un'esperienza client affidabile. Il blocco dell'accesso a questi FQDN ed endpoint non è supportato e influisce sulle funzionalità del servizio.
| Address | Protocollo | Porta in uscita | Scopo | Client | Obbligatorio? |
|---|---|---|---|---|---|
| login.microsoftonline.com | TCP | 443 | Autenticazione a Microsoft Online Services | Tutti | Sì |
| *.wvd.microsoft.com | TCP | 443 | Traffico del servizio | Tutti | Sì |
| *.servicebus.windows.net | TCP | 443 | Dati per la risoluzione dei problemi | Tutti | Sì |
| go.microsoft.com | TCP | 443 | FWLink Microsoft | Tutti | Sì |
| aka.ms | TCP | 443 | Abbreviazione URL Microsoft | Tutti | Sì |
| zcusa.951200.xyz | TCP | 443 | Documentazione | Tutti | Sì |
| privacy.microsoft.com | TCP | 443 | Informativa sulla privacy | Tutti | Sì |
| query.prod.cms.rt.microsoft.com | TCP | 443 | Scaricare un MSI per aggiornare il client. Obbligatorio per gli aggiornamenti automatici. | Windows Desktop | Sì |
Questi FQDN ed endpoint corrispondono solo a siti e risorse client.
Endpoint necessari per il provisioning di Dev Box
Gli URL e le porte seguenti sono necessari per il provisioning delle macchine di sviluppo e per i controlli di integrità della connessione di rete di Azure. Tutti gli endpoint si connettono sulla porta 443, se non diversamente specificato.
| Categoria | Endpoint | Tag FQDN o tag del servizio | Obbligatorio? |
|---|---|---|---|
| Endpoint di comunicazione macchine di sviluppo | .agentmanagement.dc.azure.com .cmdagent.trafficmanager.net |
N/D | Sì |
| Endpoint di registrazione e servizio Windows 365 | Per gli endpoint di registrazione correnti di Windows 365, vedere Requisiti di rete di Windows 365. | Tag FQDN: Windows365 | Sì |
| Endpoint servizio Desktop virtuale Azure | Per gli endpoint di servizio AVD correnti, vedere Macchine virtuali host di sessione. | Tag FQDN: WindowsVirtualDesktop | Sì |
| Microsoft Entra ID | Gli FQDN e gli endpoint per Microsoft Entra ID sono disponibili in ID 56, 59 e 125 negli URL e negli intervalli di indirizzi IP di Office 365. | Tag del servizio: AzureActiveDirectory | Sì |
| Microsoft Intune | Per gli FQDN e gli endpoint correnti per Microsoft Entra ID, vedere Servizio principale di Intune. | Tag FQDN: MicrosoftIntune | Sì |
I nomi di dominio completi e gli endpoint e i tag elencati corrispondono alle risorse necessarie. Non includono FQDN ed endpoint per tutti i servizi. Per i tag di servizio per altri servizi, vedere Tag del servizio disponibili.
Desktop virtuale Azure non dispone di un elenco di intervalli di indirizzi IP che è possibile sbloccare anziché FQDN per consentire il traffico di rete. Se si usa un firewall di nuova generazione (NGFW), è necessario usare un elenco dinamico creato per gli indirizzi IP di Azure per assicurarsi di potersi connettere.
Per altre informazioni, vedere Usare Firewall di Azure per gestire e proteggere gli ambienti Windows 365.
La tabella seguente è l'elenco di FQDN ed endpoint a cui devono accedere le macchine di sviluppo. Tutte le voci sono in uscita; non è necessario aprire le porte in ingresso per le macchine di sviluppo.
| Address | Protocollo | Porta in uscita | Scopo | Tag di servizio | Obbligatorio? |
|---|---|---|---|---|---|
| login.microsoftonline.com | TCP | 443 | Autenticazione a Microsoft Online Services | AzureActiveDirectory | Sì |
| *.wvd.microsoft.com | TCP | 443 | Traffico del servizio | WindowsVirtualDesktop | Sì |
| *.prod.warm.ingest.monitor.core.windows.net | TCP | 443 | Output di diagnostica del traffico dell'agente | AzureMonitor | Sì |
| catalogartifact.azureedge.net | TCP | 443 | Azure Marketplace | AzureFrontDoor.Frontend | Sì |
| gcs.prod.monitoring.core.windows.net | TCP | 443 | Traffico dell'agente | AzureCloud | Sì |
| kms.core.windows.net | TCP | 1688 | Attivazione di Windows | Internet | Sì |
| azkms.core.windows.net | TCP | 1688 | Attivazione di Windows | Internet | Sì |
| mrsglobalsteus2prod.blob.core.windows.net | TCP | 443 | Aggiornamenti dello stack di agenti e affiancato | AzureCloud | Sì |
| wvdportalstorageblob.blob.core.windows.net | TCP | 443 | Supporto del portale di Azure | AzureCloud | Sì |
| 169.254.169.254 | TCP | 80 | Endpoint del servizio metadati dell'istanza di Azure | N/D | Sì |
| 168.63.129.16 | TCP | 80 | Monitoraggio dell'integrità dell'host sessione | N/D | Sì |
| oneocsp.microsoft.com | TCP | 80 | Certificati | N/D | Sì |
| www.microsoft.com | TCP | 80 | Certificati | N/D | Sì |
La tabella seguente elenca FQDN ed endpoint a cui le macchine virtuali dell'host di sessione potrebbero dover accedere per altri servizi:
| Address | Protocollo | Porta in uscita | Scopo | Obbligatorio? |
|---|---|---|---|---|
| login.windows.net | TCP | 443 | Accedere a Microsoft Online Services e Microsoft 365 | Facoltativo |
| *.events.data.microsoft.com | TCP | 443 | Servizio di telemetria | Facoltativo |
| www.msftconnecttest.com | TCP | 80 | Rileva se l'host di sessione è connesso a Internet | Facoltativo |
| *.prod.do.dsp.mp.microsoft.com | TCP | 443 | Windows Update | Facoltativo |
| *.sfx.ms | TCP | 443 | Aggiornamenti per il software client di OneDrive | Facoltativo |
| *.digicert.com | TCP | 80 | Verifica della revoca del certificato | Facoltativo |
| *.azure-dns.com | TCP | 443 | Risoluzione DNS di Azure | Facoltativo |
| *.azure-dns.net | TCP | 443 | Risoluzione DNS di Azure | Facoltativo |
Questo elenco non include FQDN ed endpoint per altri servizi, ad esempio Microsoft Entra ID, Office 365, provider DNS personalizzati o servizi temporali. Gli FQDN e gli endpoint di Microsoft Entra sono disponibili in ID 56, 59 e 125 negli URL e negli intervalli di indirizzi IP di Office 365.
Suggerimento
È necessario usare il carattere jolly (*) per gli FQDN che coinvolgono il traffico del servizio. Per il traffico dell'agente, se si preferisce non usare un carattere jolly, ecco come trovare FQDN specifici per consentire:
- Verificare che le macchine virtuali host di sessione siano registrate in un pool di host.
- In un host di sessione aprire Visualizzatore eventi, quindi passare a Registri di Windows>Applicazione>WVD-Agent e cercare l'ID evento 3701.
- Sbloccare i nomi di dominio completi disponibili nell'ID evento 3701. I nomi di dominio completi nell'ID evento 3701 sono specifici dell'area. È necessario ripetere questo processo con i nomi di dominio completi pertinenti per ogni area di Azure in cui si vogliono distribuire le macchine virtuali dell'host di sessione.
Endpoint di servizio del broker RDP (Remote Desktop Protocol)
La connettività diretta agli endpoint di servizio del broker RDP di Desktop virtuale Azure è fondamentale per le prestazioni remote di una macchina di sviluppo. Questi endpoint influiscono sia sulla connettività che sulla latenza. Per allinearsi ai principi di connettività di rete di Microsoft 365, è necessario classificare questi endpoint come endpoint di ottimizzazione e usare uno shortpath RDP (Remote Desktop Protocol) dalla rete virtuale di Azure a tali endpoint. Lo shortpath RDP può fornire un altro percorso di connessione per migliorare la connettività della macchina di sviluppo, in particolare in condizioni di rete non ottimali.
Per semplificare la configurazione dei controlli di sicurezza di rete, usare i tag del servizio Desktop virtuale Azure per identificare tali endpoint per il routing diretto usando una route definita dall'utente di Rete di Azure. Una route definita dall'utente comporta un routing diretto tra la rete virtuale e il broker RDP per una latenza più bassa.
La modifica delle route di rete di una macchina di sviluppo (a livello di rete o a livello di macchina di sviluppo come una VPN) potrebbe interrompere la connessione tra la macchina di sviluppo e il broker RDP di Desktop virtuale Azure. In tal caso, l'utente finale viene disconnesso dalla propria macchina di sviluppo fino a quando non viene ristabilita una connessione.
Requisiti DNS
Nell’ambito dei requisiti di aggiunta ibrida di Microsoft Entra, le macchine di sviluppo devono essere in grado di unirsi ad Active Directory locale. Le macchine di sviluppo devono essere in grado di risolvere i record DNS per l'ambiente AD locale a cui unirsi.
Configurare la rete virtuale di Azure in cui viene effettuato il provisioning delle macchine di sviluppo come indicato di seguito:
- Assicurarsi che la rete virtuale di Azure disponga della connettività di rete verso i server DNS in grado di risolvere il dominio di Active Directory.
- Nelle impostazioni della rete virtuale di Azure selezionare Server DNS>Personalizza.
- Immettere l'indirizzo IP dei server DNS che possono risolvere il dominio di Active Directory Domain Services.
Suggerimento
L'aggiunta di almeno due server DNS, come si farebbe con un PC fisico, consente di ridurre il rischio di un singolo punto di guasto nella risoluzione dei nomi. Per altre informazioni, vedere Configurazione delle impostazioni delle reti virtuali di Azure.
Connessione a risorse di rete
È possibile consentire alle macchine di sviluppo di connettersi alle risorse locali tramite una connessione ibrida. Collaborare con l'esperto di rete di Azure per implementare una topologia di rete hub and spoke. L'hub è il punto centrale che si connette alla rete locale; è possibile usare Express Route, una VPN da sito a sito o una VPN da punto a sito. Lo spoke è la rete virtuale che contiene le macchine di sviluppo. La topologia hub-spoke consente di gestire il traffico di rete e la sicurezza. Si esegue il peering della rete virtuale della macchina di sviluppo alla rete virtuale connessa locale per fornire l'accesso alle risorse locali.
Tecnologie di intercettazione del traffico
Alcuni clienti aziendali usano l'intercettazione del traffico, la decrittografia TLS, l'ispezione approfondita dei pacchetti e altre tecnologie simili per i team di sicurezza per monitorare il traffico di rete. Queste tecnologie di intercettazione del traffico possono causare problemi con l'esecuzione dei controlli delle connessioni di rete di Azure o del provisioning di macchine di sviluppo. Assicurarsi che non venga eseguita alcuna intercettazione di rete per le macchine di sviluppo di cui è stato effettuato il provisioning all'interno di Microsoft Dev Box.
Le tecnologie di intercettazione del traffico possono esacerbare i problemi di latenza. È possibile usare uno shortpath RDP (Remote Desktop Protocol) per ridurre al minimo i problemi di latenza.
Risoluzione dei problemi
Questa sezione illustra alcuni problemi comuni di connessione e rete.
Problemi di connessione
Tentativo di accesso non riuscito
Se l'utente della finestra di sviluppo rileva problemi di accesso e visualizza un messaggio di errore che indica che il tentativo di accesso non è riuscito, assicurarsi di abilitare il protocollo PKU2U sia nel PC locale che nell'host della sessione.
Per altre informazioni sulla risoluzione degli errori di accesso, vedere Risolvere i problemi relativi alle connessioni alle macchine virtuali aggiunte a Microsoft Entra - Client Desktop di Windows.
Problemi relativi a Criteri di gruppo negli ambienti ibridi
Se si usa un ambiente ibrido, potrebbero verificarsi problemi con i criteri di gruppo. È possibile verificare se il problema è correlato ai criteri di gruppo escludendo temporaneamente la macchina di sviluppo dai criteri di gruppo.
Per altre informazioni sulla risoluzione dei problemi relativi ai criteri di gruppo, vedere Applicazione di linee guida per la risoluzione dei problemi relativi a Criteri di gruppo.
Risoluzione dei problemi relativi a IPv6
Se si verificano problemi IPv6, verificare che l'endpoint del servizio Microsoft.AzureActiveDirectory non sia abilitato nella rete virtuale o nella subnet. Questo endpoint servizio converte IPv4 in IPv6.
Per altre informazioni, vedere Endpoint servizio di rete virtuale.
Aggiornamento dei problemi relativi all'immagine della definizione della macchina di sviluppo
Quando si aggiorna l'immagine usata in una definizione della macchina di sviluppo, è necessario assicurarsi di disporre di indirizzi IP sufficienti disponibili nella rete virtuale. Per il controllo dell'integrità della connessione di rete di Azure sono necessari altri indirizzi IP gratuiti. Se il controllo di integrità non riesce, la definizione della casella di sviluppo non viene aggiornata. È necessario un indirizzo IP aggiuntivo per ogni casella di sviluppo e un indirizzo IP per il controllo di integrità e l'infrastruttura di Dev Box.
Per altre informazioni sull'aggiornamento delle immagini di definizione della macchina di sviluppo, vedere Aggiornare una definizione di macchina di sviluppo.
Contenuto correlato
- Controllare l'accesso a FQDN e endpoint necessari per Desktop virtuale Azure.
- Per informazioni su come sbloccare questi FQDN ed endpoint in Firewall di Azure, vedere Usare Firewall di Azure per proteggere il Desktop virtuale Azure.
- Per altre informazioni sulla connettività di rete, vedere Informazioni sulla connettività di rete di Desktop virtuale Azure.