Informazioni sulla connettività di rete di Desktop virtuale Azure

Azure Desktop virtuale ospita le sessioni client negli host sessione in esecuzione in Azure. Microsoft gestisce parti dei servizi per conto del cliente e fornisce endpoint sicuri per la connessione di client e host di sessione. Il diagramma seguente offre una panoramica generale delle connessioni di rete usate da desktop virtuale Azure.

Diagramma delle connessioni di rete di Desktop virtuale Azure

Connettività della sessione

Desktop virtuale Azure usa il protocollo RDP (Desktop remoto Protocol) per fornire funzionalità di input e visualizzazione remota tramite connessioni di rete. RDP si è continuamente evoluto con ogni versione di Microsoft Windows e Windows Server. Fin dall'inizio, RDP si è sviluppato per essere indipendente dallo stack di trasporto sottostante e attualmente supporta più tipi di trasporto.

Trasporto di connetti inverso

Azure Desktop virtuale usa il trasporto di connessione inversa per stabilire la sessione remota e per trasportare il traffico RDP. A differenza delle distribuzioni di Servizi Desktop remoto locali, il trasporto di connessione inversa non usa un listener TCP per ricevere le connessioni RDP in ingresso. Usa invece la connettività in uscita all'infrastruttura di Desktop virtuale Azure tramite la connessione HTTPS.

Canale di comunicazione host sessione

All'avvio dell'host sessione di Desktop virtuale Azure, il servizio Caricatore agente Desktop remoto stabilisce il canale di comunicazione permanente del broker di Desktop virtuale Azure. Questo canale di comunicazione è sovrapposto a una connessione TLS (Transport Layer Security) sicura e funge da bus per lo scambio di messaggi di servizio tra l'host della sessione e Azure'infrastruttura di Desktop virtuale.

Sequenza di connessione client

La sequenza di connessione client è la seguente (i passaggi possono variare al di fuori di Azure cloud pubblico):

  1. L'uso di Azure utente client di Desktop virtuale supportato sottoscrive l'area di lavoro desktop virtuale Azure.

  2. Microsoft Entra autentica l'utente e restituisce il token usato per enumerare le risorse disponibili per un utente.

  3. Il client passa il token al servizio di sottoscrizione del feed desktop virtuale Azure.

  4. Azure servizio di sottoscrizione del feed di Desktop virtuale convalida il token.

  5. Azure servizio di sottoscrizione del feed desktop virtuale passa di nuovo l'elenco di desktop e applicazioni disponibili al client sotto forma di configurazione di connessione con firma digitale.

  6. Il client archivia la configurazione della connessione per ogni risorsa disponibile in un set di .rdp file.

  7. Nelle connessioni cloud pubbliche, quando un utente seleziona la risorsa da connettere, il client usa il file associato .rdp e stabilisce una connessione TLS sicura a un'istanza del gateway desktop virtuale Azure con l'aiuto di Azure Frontdoor e passa le informazioni di connessione. Viene valutata la latenza di tutti i gateway e i gateway vengono inseriti in gruppi di 10 ms. Viene scelto il gateway con la latenza più bassa e quindi il numero più basso di connessioni esistenti. Altri cloud possono usare gestione traffico Azure per questo passaggio.

  8. Azure gateway desktop virtuale convalida la richiesta e chiede al gestore di Desktop virtuale Azure di orchestrare la connessione.

  9. Azure gestore di Desktop virtuale identifica l'host sessione e usa il canale di comunicazione permanente stabilito in precedenza per inizializzare la connessione.

  10. Lo stack di Desktop remoto avvia una connessione TLS alla stessa istanza del gateway desktop virtuale Azure usata dal client.

  11. Dopo che sia il client che l'host sessione si sono connessi al gateway, il gateway avvia l'inoltro dei dati tra entrambi gli endpoint. Questa connessione stabilisce il trasporto di connessione inversa di base per la connessione RDP tramite un tunnel annidato, usando la versione TLS reciprocamente approvata supportata e abilitata tra il client e l'host sessione, fino a TLS 1.3.

  12. Dopo aver impostato il trasporto di base, il client avvia l'handshake RDP.

Sicurezza della connessione

TLS viene usato per tutte le connessioni. La versione usata dipende dalla connessione effettuata e dalle funzionalità del client e dell'host di sessione:

  • Per tutte le connessioni avviate dai client e dagli host di sessione ai componenti dell'infrastruttura di Desktop virtuale Azure, TLS 1.2 è il valore minimo e TLS 1.3 può essere usato se il sistema operativo client lo supporta. Azure Desktop virtuale usa le stesse crittografie TLS 1.2 o 1.3 di Azure Frontdoor. È importante assicurarsi che sia i computer client che gli host di sessione possano usare queste crittografie.

  • Per il trasporto di connessione inversa, sia il client che l'host di sessione si connettono al gateway desktop virtuale Azure. Dopo aver stabilito la connessione TCP per il trasporto di base, il client o l'host di sessione convalida il certificato del gateway desktop virtuale Azure. RDP stabilisce quindi una connessione TLS annidata tra client e host di sessione usando i certificati dell'host sessione. La versione di TLS usa la versione TLS reciprocamente approvata supportata e abilitata tra il client e l'host di sessione, fino a TLS 1.3. TLS 1.3 è supportato a partire da Windows 11 (21H2) e in Windows Server 2022. Per altre informazioni, vedere Windows 11 supporto TLS. Per altri sistemi operativi, rivolgersi al fornitore del sistema operativo per il supporto di TLS 1.3.

Per impostazione predefinita, il certificato usato per la crittografia RDP viene generato automaticamente dal sistema operativo durante la distribuzione. Azure Desktop virtuale non supporta attualmente l'uso di un certificato emesso da un'autorità di certificazione.

Passaggi successivi

  • Last updated on