Percorso breve RDP per Desktop virtuale Azure

È possibile ottenere la connettività diretta alla vista necessaria per usare il percorso breve RDP con le reti gestite usando i metodi seguenti.

• Peering privato ExpressRoute

• VPN da sito a sito o da punto a sito (IPsec), ad esempio Azure Gateway VPN

La connettività diretta della linea di vista significa che il client può connettersi direttamente all'host della sessione senza essere bloccato dai firewall.

Per usare RDP Shortpath per le reti gestite, è necessario abilitare un listener UDP negli host di sessione. Per impostazione predefinita, viene usata la porta 3390 , anche se è possibile usare una porta diversa.

Il diagramma seguente offre una panoramica generale delle connessioni di rete quando si usa RDP Shortpath per le reti gestite e gli host di sessione aggiunti a un dominio di Active Directory.

Sequenza di connessione

Tutte le connessioni iniziano stabilendo un trasporto di connessione inversa basato su TCP tramite il gateway Desktop virtuale Azure. Quindi, il client e l'host di sessione stabiliscono il trasporto RDP iniziale e iniziano a scambiarne le funzionalità. Queste funzionalità vengono negoziate usando il processo seguente:

1. L'host di sessione invia l'elenco dei relativi indirizzi IPv4 e IPv6 al client.

2. Il client avvia il thread in background per stabilire un trasporto parallelo basato su UDP direttamente in uno degli indirizzi IP dell'host sessione.

3. Mentre il client esegue il probe degli indirizzi IP forniti, continua a stabilire la connessione iniziale tramite il trasporto di connessione inversa per assicurarsi che non ci siano ritardi nella connessione utente.

4. Se il client ha una connessione diretta all'host di sessione, il client stabilisce una connessione sicura tramite TLS tramite UDP affidabile.

5. Dopo aver stabilito il trasporto per percorsi brevi RDP, tutti i canali virtuali dinamici, inclusi la grafica remota, l'input e il reindirizzamento del dispositivo, vengono spostati nel nuovo trasporto. Tuttavia, se un firewall o una topologia di rete impedisce al client di stabilire la connettività UDP diretta, RDP continua con un trasporto di connessione inversa.

Se gli utenti dispongono sia di RDP Shortpath per la rete gestita che di reti pubbliche, verrà usato il primo algoritmo trovato. L'utente userà la connessione stabilita per la prima volta per tale sessione.

Per offrire la migliore probabilità di riuscita di una connessione UDP quando si usa una connessione pubblica, sono disponibili i tipi di connessione diretta e inoltrata :

• Connessione diretta: STUN viene usato per stabilire una connessione UDP diretta tra un client e un host di sessione. Per stabilire questa connessione, il client e l'host di sessione devono essere in grado di connettersi tra loro tramite un indirizzo IP pubblico e una porta negoziata. Tuttavia, la maggior parte dei client non conosce il proprio indirizzo IP pubblico perché si trovano dietro un dispositivo gateway NAT (Network Address Translation). STUN è un protocollo per l'individuazione automatica di un indirizzo IP pubblico da dietro un dispositivo gateway NAT e il client per determinare il proprio indirizzo IP pubblico.

  Affinché un client usi STUN, la sua rete deve consentire il traffico UDP. Supponendo che sia il client che l'host di sessione possano instradarsi direttamente all'indirizzo IP e alla porta individuati dall'altro, la comunicazione viene stabilita con UDP diretto tramite il protocollo WebSocket. Se i firewall o altri dispositivi di rete bloccano le connessioni dirette, viene tentata una connessione UDP inoltrata.

• Connessione inoltrata: turn viene usato per stabilire una connessione, inoltrando il traffico attraverso un server intermedio tra un client e un host di sessione quando non è possibile una connessione diretta. TURN è un'estensione di STUN. L'uso di TURN significa che l'indirizzo IP pubblico e la porta sono noti in anticipo, che possono essere consentiti tramite firewall e altri dispositivi di rete.

  Se i firewall o altri dispositivi di rete bloccano il traffico UDP, la connessione tornerà a un trasporto di connessione inversa basato su TCP.

Quando viene stabilita una connessione, Interactive Connectivity Establishment (ICE) coordina la gestione di STUN e TURN per ottimizzare la probabilità che venga stabilita una connessione e assicurarsi che venga assegnata la precedenza ai protocolli di comunicazione di rete preferiti.

Ogni sessione RDP usa una porta UDP assegnata dinamicamente da un intervallo di porte temporanee (da 49152 a 65535 per impostazione predefinita) che accetta il traffico RDP Shortpath. La porta 65330 viene ignorata da questo intervallo perché è riservata per l'uso interno da parte di Azure. È anche possibile usare un intervallo di porte più piccolo e prevedibile. Per altre informazioni, vedere Limitare l'intervallo di porte usato dai client per le reti pubbliche.

Il diagramma seguente offre una panoramica generale delle connessioni di rete quando si usa RDP Shortpath per le reti pubbliche in cui gli host di sessione si sono uniti all'ID Microsoft Entra.

Disponibilità dell'inoltro TURN

L'inoltro TURN è disponibile nelle aree di Azure seguenti con ACS TURN Relay (51.5.0.0/16):

Viene selezionato un inoltro TURN in base alla posizione fisica del dispositivo client. Ad esempio, se un dispositivo client si trova nel Regno Unito, viene selezionato l'inoltro TURN nell'area Regno Unito meridionale o occidentale del Regno Unito. Se un dispositivo client è lontano da un inoltro TURN, la connessione UDP potrebbe tornare a TCP.

Network Address Translation e firewall

La maggior parte dei client di Desktop virtuale Azure viene eseguita nei computer nella rete privata. L'accesso a Internet viene fornito tramite un dispositivo gateway NAT (Network Address Translation). Pertanto, il gateway NAT modifica tutte le richieste di rete dalla rete privata e destinate a Internet. Tale modifica intende condividere un singolo indirizzo IP pubblico tra tutti i computer della rete privata.

A causa della modifica del pacchetto IP, il destinatario del traffico visualizzerà l'indirizzo IP pubblico del gateway NAT anziché il mittente effettivo. Quando il traffico torna al gateway NAT, si occuperà di inoltrarlo al destinatario previsto senza che il mittente ne sia a conoscenza. Nella maggior parte degli scenari, i dispositivi nascosti dietro tale NAT non sono in grado di riconoscere che la traduzione è in corso e non conoscono l'indirizzo di rete del gateway NAT.

NAT è applicabile alle reti virtuali di Azure in cui risiedono tutti gli host di sessione. Quando un host di sessione tenta di raggiungere l'indirizzo di rete su Internet, il gateway NAT (proprio o predefinito fornito da Azure) o Azure Load Balancer esegue la conversione degli indirizzi. Per altre informazioni sui vari tipi di traduzione degli indirizzi di rete di origine, vedere Usare SNAT (Source Network Address Translation) per le connessioni in uscita.

La maggior parte delle reti include in genere firewall che controllano il traffico e lo bloccano in base alle regole. La maggior parte dei clienti configura i firewall per impedire le connessioni in ingresso, ovvero i pacchetti non richiesti da Internet inviati senza una richiesta. I firewall usano tecniche diverse per tenere traccia del flusso di dati per distinguere tra traffico richiesto e non richiesto. Nel contesto di TCP, il firewall tiene traccia dei pacchetti SYN e ACK e il processo è semplice. I firewall UDP usano in genere l'euristica basata sugli indirizzi dei pacchetti per associare il traffico ai flussi UDP e consentirlo o bloccarlo. Sono disponibili molte implementazioni NAT diverse.

Sequenza di connessione

Tutte le connessioni iniziano stabilendo un trasporto di connessione inversa basato su TCP tramite il gateway Desktop virtuale Azure. Quindi, il client e l'host di sessione stabiliscono il trasporto RDP iniziale e iniziano a scambiarne le funzionalità. Se il percorso breve RDP per le reti pubbliche è abilitato nell'host della sessione, l'host della sessione avvia quindi un processo denominato raccolta di candidati:

1. L'host di sessione enumera tutte le interfacce di rete assegnate a un host sessione, incluse le interfacce virtuali come VPN e Teredo.

2. Servizi Desktop remoto del servizio Windows (TermService) alloca i socket UDP in ogni interfaccia e archivia la coppia IP:Porta nella tabella candidata come candidato locale.

3. Il servizio Servizi Desktop remoto usa ogni socket UDP allocato nel passaggio precedente per provare a raggiungere il server STUN di Desktop virtuale Azure su Internet pubblico. La comunicazione viene eseguita inviando un piccolo pacchetto UDP alla porta 3478.

4. Se il pacchetto raggiunge il server STUN, il server STUN risponde con l'INDIRIZZO IP pubblico e la porta. Queste informazioni vengono archiviate nella tabella candidata come candidato riflessivo.

5. Dopo che l'host della sessione ha raccolto tutti i candidati, l'host della sessione usa il trasporto di connessione inverso stabilito per passare l'elenco di candidati al client.

6. Quando il client riceve l'elenco dei candidati dall'host della sessione, il client esegue anche la raccolta dei candidati sul lato. Il client invia quindi l'elenco dei candidati all'host della sessione.

7. Dopo che l'host della sessione e il client si scambiano le liste di candidati, entrambe le parti tentano di connettersi tra loro usando tutti i candidati raccolti. Questo tentativo di connessione è simultaneo su entrambi i lati. Molti gateway NAT sono configurati per consentire il traffico in ingresso al socket non appena il trasferimento dei dati in uscita lo inizializza. Questo comportamento dei gateway NAT è il motivo per cui la connessione simultanea è essenziale. Se STUN ha esito negativo perché è bloccato, viene effettuato un tentativo di connessione inoltrata tramite TURN.

8. Dopo lo scambio di pacchetti iniziale, il client e l'host di sessione possono stabilire uno o più flussi di dati. Da questi flussi di dati, RDP sceglie il percorso di rete più veloce. Il client stabilisce quindi una connessione sicura usando TLS su un protocollo UDP affidabile con l'host di sessione e avvia il trasporto di shortpath RDP.

9. Dopo che RDP ha stabilito il trasporto RDP Shortpath, tutti i canali virtuali dinamici , inclusi la grafica remota, l'input e il reindirizzamento del dispositivo, vengono spostati nel nuovo trasporto.

Se gli utenti dispongono sia di RDP Shortpath per la rete gestita che di reti pubbliche, verrà usato il primo algoritmo trovato, vale a dire che l'utente userà la connessione stabilita per prima per quella sessione. Per altre informazioni, vedere scenario di esempio 4.

Configurazione di rete

Per supportare il percorso breve RDP per le reti pubbliche, in genere non è necessaria alcuna configurazione specifica. L'host e il client della sessione individuano automaticamente il flusso di dati diretto, se possibile nella configurazione di rete. Tuttavia, ogni ambiente è univoco e alcune configurazioni di rete possono influire negativamente sulla frequenza di riuscita della connessione diretta. Seguire le indicazioni per aumentare la probabilità di un flusso di dati diretto.

Poiché RDP Shortpath usa UDP per stabilire un flusso di dati, se un firewall nella rete blocca il traffico UDP, il percorso breve RDP avrà esito negativo e la connessione tornerà al trasporto di connessione inversa basata su TCP. Desktop virtuale Azure usa i server STUN forniti da Servizi di comunicazione di Azure e Microsoft Teams. Per la natura della funzionalità, è necessaria la connettività in uscita dagli host di sessione al client. Sfortunatamente, non è possibile prevedere dove si trovano gli utenti nella maggior parte dei casi. È pertanto consigliabile consentire la connettività UDP in uscita dagli host di sessione a Internet. Per ridurre il numero di porte necessarie, è possibile limitare l'intervallo di porte usato dai client per il flusso UDP. Usare le tabelle seguenti come riferimento quando si configurano i firewall per il percorso breve RDP.

Se l'ambiente usa NAT simmetrico, ovvero il mapping di un singolo IP:Porta di origine privata a un indirizzo IP:Porta di destinazione pubblica univoco, è possibile usare una connessione inoltrata con TURN. Questo avviene se si usano Firewall di Azure e il gateway NAT di Azure. Per altre informazioni su NAT con reti virtuali di Azure, vedere Traduzione degli indirizzi di rete di origine con reti virtuali.

Sono disponibili alcune raccomandazioni generali per il corretto funzionamento delle connessioni tramite il percorso breve RDP per le reti pubbliche. Per altre informazioni, vedere Raccomandazioni generali.

Se per gli utenti è disponibile il percorso breve RDP sia per la rete gestita che per le reti pubbliche, verrà usato il primo algoritmo trovato. L'utente userà la connessione stabilita per la prima volta per tale sessione. Per altre informazioni, vedere Scenari di esempio.

Le sezioni seguenti contengono i requisiti di origine, destinazione e protocollo per gli host sessione e i dispositivi client che devono essere consentiti per il funzionamento di Shortpath RDP.

Rete virtuale host sessione

Nella tabella seguente vengono illustrati in dettaglio i requisiti di origine, destinazione e protocollo per il percorso breve RDP per la rete virtuale dell'host sessione.

Rete client

La tabella seguente illustra in dettaglio i requisiti di origine, destinazione e protocollo per i dispositivi client.

supporto Teredo

Anche se non è necessario per il percorso breve RDP, Teredo aggiunge ulteriori candidati di attraversamento NAT e aumenta le probabilità di riuscita della connessione RDP Shortpath nelle reti solo IPv4. Per informazioni su come abilitare Teredo in host e client di sessione, vedere Abilitare il supporto Teredo.

Supporto di UPnP

Per migliorare le probabilità di una connessione diretta, sul lato del client Desktop remoto, RDP Shortpath può usare UPnP per configurare un mapping delle porte nel router NAT. UPnP è una tecnologia standard usata da varie applicazioni, ad esempio Xbox, Ottimizzazione recapito e Teredo. UPnP è disponibile a livello generale nei router in genere presenti in una rete domestica. UPnP è abilitato per impostazione predefinita nella maggior parte dei router home e dei punti di accesso, ma è spesso disabilitato nella rete aziendale.

Raccomandazioni generali

Ecco alcuni consigli generali quando si usa il percorso breve RDP per le reti pubbliche:

• Evitare di usare configurazioni di force tunneling se gli utenti accedono a Desktop virtuale Azure tramite Internet.

• Assicurarsi di non usare configurazioni NAT o CGN (Carrier-Grade-NAT) doppie.

• Consiglia agli utenti di non disabilitare UPnP nei router di casa.

• Evitare di usare i servizi di ispezione pacchetti cloud.

• Evitare di usare soluzioni VPN basate su TCP.

• Abilitare la connettività IPv6 o Teredo.