Collegamento privato di Azure con Desktop virtuale Azure
È possibile usare Collegamento privato di Azure con Desktop virtuale Azure per connettersi privatamente alle risorse remote. Creando un endpoint privato, il traffico tra la rete virtuale e il servizio rimane nella rete Microsoft, quindi non è più necessario esporre il servizio alla rete Internet pubblica. È anche possibile usare una VPN o ExpressRoute per gli utenti con il client Desktop remoto per connettersi alla rete virtuale. Mantenere il traffico all'interno della rete Microsoft migliora la sicurezza e mantiene i dati al sicuro. Questo articolo descrive come Collegamento privato consente di proteggere l'ambiente Desktop virtuale Azure.
Come funziona Collegamento privato con Desktop virtuale Azure?
Desktop virtuale Azure include tre flussi di lavoro con tre tipi di risorse corrispondenti da usare con endpoint privati. Questi flussi di lavoro sono:
Individuazione del feed iniziale: consente al client di individuare tutte le aree di lavoro assegnate a un utente. Per abilitare questo processo, è necessario creare un singolo endpoint privato per la sotto-risorsa globale in qualsiasi area di lavoro. Tuttavia, è possibile creare un solo endpoint privato nell'intera distribuzione di Desktop virtuale Azure. Questo endpoint crea voci DNS (Domain Name System) e route IP private per il nome di dominio completo globale (FQDN) necessario per l'individuazione iniziale del feed. Questa connessione diventa una singola route condivisa per tutti i client da usare.
Download del feed: il client scarica tutti i dettagli di connessione per un utente specifico per le aree di lavoro che ospitano i gruppi di applicazioni. Si crea un endpoint privato per la sotto-risorsa del feed per ogni area di lavoro che si desidera usare con Collegamento privato.
Connessioni ai pool di host: ogni connessione a un pool di host ha due lati: client e host di sessione. È necessario creare un endpoint privato per la sotto-risorsa di connessione per ogni pool di host che si desidera usare con Collegamento privato.
Il diagramma generale seguente illustra in che modo Collegamento privato connette in modo sicuro un client locale al servizio Desktop virtuale Azure. Per informazioni più dettagliate sulle connessioni client, vedere Sequenza di connessione client.
Scenari supportati
Quando si aggiunge un collegamento privato con Desktop virtuale Azure, sono disponibili gli scenari supportati seguenti per connettersi a Desktop virtuale Azure. Lo scenario scelto dipende dai requisiti. È possibile condividere questi endpoint privati nella topologia di rete oppure isolare le reti virtuali in modo che ognuno disponga del proprio endpoint privato nel pool di host o nell'area di lavoro.
Tutte le parti della connessione, ovvero l'individuazione iniziale del feed, il download dei feed e le connessioni di sessione remote per i client e gli host sessione, usano route private. Sono necessari gli endpoint privati seguenti:
Scopo Tipo di risorsa Risorsa secondaria di destinazione Quantità di endpoint Connessioni ai pool di host Microsoft.DesktopVirtualization/hostpools connection Uno per pool di host Download del feed Microsoft.DesktopVirtualization/workspaces feed Uno per area di lavoro Individuazione iniziale del feed Microsoft.DesktopVirtualization/workspaces global Solo una per tutte le distribuzioni di Desktop virtuale Azure Il download dei feed e le connessioni di sessione remote per i client e gli host sessione usano route private, mentre l'individuazione iniziale dei feed usa route pubbliche. Sono necessari gli endpoint privati seguenti. L'endpoint per l'individuazione iniziale del feed non è obbligatorio.
Scopo Tipo di risorsa Risorsa secondaria di destinazione Quantità di endpoint Connessioni ai pool di host Microsoft.DesktopVirtualization/hostpools connection Uno per pool di host Download del feed Microsoft.DesktopVirtualization/workspaces feed Uno per area di lavoro Solo le connessioni di sessione remote per i client e gli host sessione usano route private, mentre l'individuazione iniziale dei feed e il download dei feed usano route pubbliche. Sono necessari gli endpoint privati seguenti. Gli endpoint alle aree di lavoro non sono necessari.
Scopo Tipo di risorsa Risorsa secondaria di destinazione Quantità di endpoint Connessioni ai pool di host Microsoft.DesktopVirtualization/hostpools connection Uno per pool di host Sia i client che le macchine virtuali host sessione usano route pubbliche. Collegamento privato non viene usato in questo scenario.
Importante
Se si crea un endpoint privato per l'individuazione iniziale dei feed, l'area di lavoro usata per la sotto-risorsa globale regola il Nome di dominio completo condiviso (FQDN), semplificando l'individuazione iniziale dei feed in tutte le aree di lavoro. È consigliabile creare un'area di lavoro separata usata solo per questo scopo e per cui non siano registrati gruppi di applicazioni. L'eliminazione di questa area di lavoro causerà l'interruzione del funzionamento di tutti i processi di individuazione dei feed.
Non è possibile controllare l'accesso all'area di lavoro usata per l'individuazione iniziale del feed (sotto-risorsa globale). Se si configura questa area di lavoro per consentire solo l'accesso privato, l'impostazione viene ignorata. Questa area di lavoro è sempre accessibile dalle route pubbliche.
Le allocazioni degli indirizzi IP sono soggette a modifiche man mano che aumenta la richiesta di indirizzi IP. Durante le espansioni della capacità, sono necessari indirizzi aggiuntivi per gli endpoint privati. È importante considerare l'esaurimento potenziale dello spazio di indirizzi e garantire un'adeguata capacità di crescita. Per altre informazioni sulla determinazione della configurazione di rete appropriata per gli endpoint privati in una topologia hub o spoke, vedere Albero delle decisioni per la distribuzione del collegamento privato.
Risultati della configurazione
Le impostazioni vengono configurate nelle aree di lavoro e nei pool di host di Desktop virtuale Azure pertinenti per impostare l'accesso pubblico o privato. Per le connessioni a un'area di lavoro, ad eccezione dell'area di lavoro usata per l'individuazione iniziale dei feed (sotto-risorsa globale), la tabella seguente illustra in dettaglio il risultato di ogni scenario:
| Impostazione | Risultato |
|---|---|
| Accesso pubblico abilitato da tutte le reti | Le richieste di feed dell'area di lavoro sono consentite da route pubbliche. Le richieste di feed dell'area di lavoro sono consentite da route private. |
| Accesso pubblico disabilitato da tutte le reti | Le richieste di feed dell'area di lavoro vengono negate da route pubbliche . Le richieste di feed dell'area di lavoro sono consentite da route private. |
Con il trasporto di connessione inversa sono disponibili due connessioni di rete per le connessioni ai pool di host: il client al gateway e l'host di sessione al gateway. Oltre ad abilitare o disabilitare l'accesso pubblico per entrambe le connessioni, è anche possibile scegliere di abilitare l'accesso pubblico per i client che si connettono al gateway e consentire l'accesso privato solo per gli host sessione che si connettono al gateway. La tabella seguente illustra in dettaglio il risultato di ogni scenario:
| Impostazione | Risultato |
|---|---|
| Accesso pubblico abilitato da tutte le reti | Le sessioni remote sono consentite quando l'host client o sessione usa una route pubblica. Le sessioni remote sono consentite quando l'host client o sessione usa una route privata. |
| Accesso pubblico disabilitato da tutte le reti | Le sessioni remote vengono negate quando l'host client o sessione usa una route pubblica. Le sessioni remote sono consentite quando sia il client che l'host sessione usano una route privata. |
| Accesso pubblico abilitato per le reti client, ma disabilitato per le reti host di sessione | Le sessioni remote vengono negate se l'host sessione usa una route pubblica, indipendentemente dalla route usata dal client. Le sessioni remote sono consentite purché l'host di sessione usi una route privata, indipendentemente dalla route usata dal client. |
Sequenza della connessione client
Quando un utente si connette a Desktop virtuale Azure tramite collegamento privato e Desktop virtuale Azure è configurato per consentire solo le connessioni client da route private, la sequenza di connessione è la seguente:
Con un client supportato, un utente sottoscrive un'area di lavoro. Il dispositivo dell'utente esegue una query DNS per l'indirizzo
rdweb.wvd.microsoft.com(o l'indirizzo corrispondente per altri ambienti di Azure).La zona DNS privato per privatelink-global.wvd.microsoft.com restituisce l'indirizzo IP privato per l'individuazione iniziale del feed (sotto-risorsa globale). Se non si usa un endpoint privato per l'individuazione iniziale del feed, viene restituito un indirizzo IP pubblico.
Per ogni area di lavoro nel feed, viene eseguita una query DNS per l'indirizzo
<workspaceId>.privatelink.wvd.microsoft.com.La zona DNS privato per privatelink.wvd.microsoft.com restituisce l'indirizzo IP privato per il download del feed dell'area di lavoro e scarica il feed usando la porta TCP 443.
Quando ci si connette a una sessione remota, il file
.rdpproveniente dal download del feed dell'area di lavoro contiene l'indirizzo per il servizio gateway Desktop virtuale Azure con la latenza più bassa per il dispositivo dell'utente. Viene eseguita una query DNS in un indirizzo nel formato<hostpooId>.afdfp-rdgateway.wvd.microsoft.com.La zona DNS privato per privatelink.wvd.microsoft.com restituisce l'indirizzo IP privato per il servizio gateway Desktop virtuale Azure da usare per il pool di host che fornisce la sessione remota. L'orchestrazione tramite la rete virtuale e l'endpoint privato usa la porta TCP 443.
Dopo l'orchestrazione, il traffico di rete tra il client, il servizio gateway Desktop virtuale Azure e l'host sessione viene trasferito a una porta nell'intervallo di porte dinamiche TCP compreso tra 1 e 65535.
Importante
Se si intende limitare le porte di rete dai dispositivi client utente o dalle macchine virtuali host sessione agli endpoint privati, sarà necessario consentire il traffico nell'intero intervallo di porte dinamiche TCP compreso tra 1 e 65535 all'endpoint privato per la risorsa del pool di host usando la sotto-risorsa di connessione. L'intero intervallo di porte dinamiche TCP è necessario perché il networking privato di Azure esegue internamente il mapping di queste porte al gateway appropriato selezionato durante l'orchestrazione client. Se si limitano le porte all'endpoint privato, gli utenti potrebbero non essere in grado di connettersi a Desktop virtuale Azure.
Problemi noti e limitazioni
Collegamento privato con Desktop virtuale Azure presenta le limitazioni seguenti:
Prima di usare Collegamento privato per Desktop virtuale Azure, è necessario abilitare Collegamento privato con Desktop virtuale Azure in ogni sottoscrizione di Azure che si desidera collegare privatamente con Desktop virtuale Azure.
È possibile usare tutti i client Desktop remoto per connettersi a Desktop virtuale Azure con Collegamento privato. Se si usa il client Desktop remoto per Windows in una rete privata senza accesso a Internet e si è iscritti a feed pubblici e privati, non è possibile accedere al feed.
Dopo aver modificato un endpoint privato in un pool di host, è necessario riavviare il servizio Caricatore agente Desktop remoto (RDAgentBootLoader) in ogni host di sessione nel pool di host. È anche necessario riavviare questo servizio ogni volta che si modifica la configurazione di rete di un pool di host. Anziché riavviare il servizio, è possibile riavviare ogni host di sessione.
L'uso di collegamento privato e RDP Shortpath per le reti gestite non è supportato, ma può essere usato insieme. È possibile usare collegamento privato e RDP Shortpath per le reti gestite a proprio rischio. Tutte le altre opzioni di RDP Shortpath che usano STUN o TURN non sono supportate con collegamento privato.
Nelle prime fasi dell'anteprima di Collegamento privato con Desktop virtuale Azure, l'endpoint privato per l'individuazione iniziale del feed (per la sotto-risorsa globale ) ha condiviso il nome della zona DNS privato di
privatelink.wvd.microsoft.comcon altri endpoint privati per le aree di lavoro e i pool di host. In questa configurazione gli utenti non sono in grado di stabilire endpoint privati esclusivamente per pool di host e aree di lavoro. A partire dal 1° settembre 2023, la condivisione della zona DNS privato in questa configurazione non sarà più supportata. È necessario creare un nuovo endpoint privato per la sotto-risorsa globale per usare il nome della zona DNS privato diprivatelink-global.wvd.microsoft.com. Per la procedura per eseguire questa operazione, vedere Individuazione iniziale dei feed.
Passaggi successivi
- Informazioni su come Configurare Collegamento privato con Desktop virtuale Azure.
- Informazioni su come configurare DNS dell'endpoint privato di Azure in Integrazione DNS collegamento privato.
- Per le guide generali alla risoluzione dei problemi relativi al Collegamento privato, vedere Risoluzione dei problemi di connettività dell'endpoint privato di Azure.
- Informazioni sulla connettivitàdi rete di Desktop virtuale Azure.
- Vedere l'Elenco degli URL necessari per l'elenco degli URL che è necessario sbloccare per garantire l'accesso di rete al servizio Desktop virtuale Azure.