RDP Shortpath per Desktop virtuale Azure

È possibile ottenere la connettività direct line of sight necessaria per usare RDP Shortpath con reti gestite usando i metodi seguenti.

• Peering privato ExpressRoute

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

La connettività direct line-of-sight significa che il client può connettersi direttamente all'host di sessione senza essere bloccato dai firewall.

Per usare RDP Shortpath per le reti gestite, è necessario abilitare un listener UDP sugli 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 reti gestite e 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, l'host client e sessione stabiliscono il trasporto RDP iniziale e iniziano a scambiare le proprie funzionalità. Queste funzionalità vengono negoziate usando il processo seguente:

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

2. Il client avvia il thread in background per stabilire un trasporto basato su UDP parallelo direttamente a 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 vi sia alcun ritardo nella connessione utente.

4. Se il client dispone di una connessione diretta all'host sessione, il client stabilisce una connessione sicura usando TLS su UDP affidabile.

5. Dopo aver stabilito il trasporto Shortpath RDP, tutti i canali virtuali dinamici (DVC), inclusi grafica remota, input e reindirizzamento dei dispositivi, vengono spostati nel nuovo trasporto. Tuttavia, se una topologia firewall o di rete impedisce al client di stabilire la connettività UDP diretta, RDP continua con un trasporto di connessione inverso.

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

Per offrire la migliore possibilità di una connessione UDP quando si usa una connessione pubblica, esistono 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, l'host client e sessione deve 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 mentre si trovano dietro un dispositivo gateway Network Address Translation (NAT). 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 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, inoltrare il traffico attraverso un server intermedio tra un client e un host sessione quando non è possibile stabilire una connessione diretta. TURN è un'estensione di STUN. L'uso di TURN indica 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 eseguirà il fallback a un trasporto di connessione inverso basato su TCP.

Quando viene stabilita una connessione, Interactive Connectivity Establishment (ICE) coordina la gestione di STUN e TURN per ottimizzare la probabilità di stabilire una connessione e assicurarsi che la precedenza venga assegnata 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 Shortpath RDP. La porta 65330 viene ignorata da questo intervallo perché è riservata per l'uso internamente da 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 sessione sono stati aggiunti a Microsoft Entra ID.

Disponibilità dell'inoltro TURN

Turn Relay è disponibile nelle aree di Azure seguenti:

Un inoltro TURN viene selezionato 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 Regno Unito occidentale. Se un dispositivo client è lontano da un inoltro TURN, la connessione UDP potrebbe eseguire il fallback a TCP.

Network Address Translation e firewall

La maggior parte dei client Desktop virtuale Azure viene eseguita nei computer della 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 in tutti i computer nella 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, sarà necessario inoltrarlo al destinatario desiderato senza conoscere il mittente. Nella maggior parte degli scenari, i dispositivi nascosti dietro un NAT di questo tipo non sono in grado di riconoscere la traduzione avviene e non conoscono l'indirizzo di rete del gateway NAT.

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

La maggior parte delle reti in genere include 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 pacchetti non richiesti da Internet inviati senza una richiesta). I firewall usano tecniche diverse per tenere traccia del flusso di dati per distinguere tra il traffico richiesto e quello 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 euristica in base agli indirizzi di pacchetto per associare il traffico ai flussi UDP e consentire 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, l'host client e sessione stabiliscono il trasporto RDP iniziale e iniziano a scambiare le proprie funzionalità. Se RDP Shortpath per le reti pubbliche è abilitato nell'host sessione, l'host di sessione avvia un processo denominato raccolta candidata:

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

2. Il Servizio Desktop remoto di 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 sulla rete Internet pubblica. 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 raccoglie tutti i candidati, l'host della sessione usa il trasporto di connessione inverso stabilito per passare l'elenco dei candidati al client.

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

7. Dopo che l'host della sessione e il client scambiano gli elenchi 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 verso il 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 eseguito un tentativo di connessione inoltrato usando TURN.

8. Dopo lo scambio di pacchetti iniziale, l'host client e sessione può 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 UDP affidabile con l'host di sessione e avvia il trasporto Shortpath RDP.

9. Dopo che RDP stabilisce il trasporto Shortpath RDP, tutti i canali virtuali dinamici (DVC), inclusi grafica remota, input e reindirizzamento del dispositivo passano al nuovo trasporto.

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

Configurazione di rete

Per supportare RDP Shortpath per le reti pubbliche, in genere non è necessaria alcuna configurazione specifica. L'host sessione e il client rileveranno 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 esito positivo 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, RDP Shortpath avrà esito negativo e la connessione eseguirà il fallback al trasporto di connessione inversa basato su TCP. Desktop virtuale Azure usa server STUN forniti da Servizi di comunicazione di Azure e Microsoft Teams. Per 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. È quindi 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 per riferimento quando si configurano i firewall per RDP Shortpath.

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

Sono disponibili alcuni consigli generali per le connessioni riuscite che usano RDP Shortpath per le reti pubbliche. Per altre informazioni, vedere Raccomandazioni generali.

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

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

Rete virtuale host sessione

La tabella seguente illustra in dettaglio i requisiti di origine, destinazione e protocollo per RDP Shortpath 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 di Teredo

Sebbene non sia necessario per RDP Shortpath, Teredo aggiunge altri candidati di attraversamento NAT e aumenta la probabilità di una connessione RDP Shortpath di successo nelle reti solo IPv4. Per informazioni su come abilitare Teredo in host di sessione e client, vedere Abilitare il supporto Teredo.

Supporto 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 domestici e dei punti di accesso, ma è spesso disabilitato nel networking aziendale.

Raccomandazioni generali

Ecco alcuni consigli generali quando si usa RDP Shortpath per le reti pubbliche:

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

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

• Consigliare agli utenti di non disabilitare UPnP nei router domestici.

• Evitare di usare i servizi di ispezione dei pacchetti cloud.

• Evitare di usare soluzioni VPN basate su TCP.

• Abilitare la connettività IPv6 o Teredo.