L'uso di RDP Shortpath per le reti pubbliche con TURN per Desktop virtuale Azure è attualmente in ANTEPRIMA. Vedere le condizioni per l'utilizzo supplementari per le anteprime di Microsoft Azure per termini legali aggiuntivi che si applicano a funzionalità di Azure in versione beta, in anteprima o in altro modo non ancora disponibili a livello generale.
RDP Shortpath stabilisce un trasporto diretto basato su UDP tra un'App di Windows del dispositivo locale o l'app Desktop remoto su piattaforme supportate e host sessione in Desktop virtuale Azure.
Per impostazione predefinita, Remote Desktop Protocol (RDP) tenta di stabilire una sessione remota tramite UDP e usa un trasporto di connessione inverso basato su TCP come meccanismo di connessione di fallback. Il trasporto basato su UDP offre una migliore affidabilità della connessione e una latenza più coerente. Il trasporto di connessione inversa basato su TCP offre la migliore compatibilità con varie configurazioni di networking, oltre che una frequenza di successo elevata per stabilire connessioni RDP.
RDP Shortpath può essere usato in due modi:
Reti gestite, in cui viene stabilita la connettività diretta tra il client e l'host sessione quando si usa una connessione privata, ad esempio una rete privata virtuale (VPN). Una connessione che usa una rete gestita viene stabilita in uno dei modi seguenti:
Connessione UDP diretta tra il dispositivo client e l'host sessione, in cui è necessario abilitare il listener Shortpath RDP e consentire a una porta in ingresso in ogni host di sessione di accettare le connessioni.
Una connessione UDP diretta tra il dispositivo client e l'host sessione, usando il protocollo Simple Traversal Underneath NAT (STUN) tra un client e un host di sessione. Le porte in ingresso nell'host di sessione non devono essere consentite.
Reti pubbliche, in cui viene stabilita la connettività diretta tra il client e l'host sessione quando si usa una connessione pubblica. Esistono due tipi di connessione quando si usa una connessione pubblica, elencata di seguito in ordine di preferenza:
Una connessione UDP diretta usando il protocollo STUN (Simple Traversal Sotto NAT) tra un client e un host di sessione.
Connessione UDP indiretta che usa il protocollo TURN (Traversal Using Relay NAT) con un inoltro tra un client e un host di sessione. Questa opzione è disponibile in anteprima.
Il trasporto usato per RDP Shortpath si basa sul protocollo URCP (Universal Rate Control Protocol). URCP ottimizza UDP con il monitoraggio attivo delle condizioni di rete e fornisce un utilizzo equo e completo dei collegamenti. URCP opera a bassi livelli di ritardo e perdita in base alle esigenze.
Importante
Durante l'anteprima, TURN è disponibile solo per le connessioni agli host sessione in un pool di host di convalida. Per configurare il pool di host come ambiente di convalida, vedere Definire il pool di host come ambiente di convalida.
RDP Shortpath per le reti pubbliche con TURN è disponibile solo nel cloud pubblico di Azure.
Vantaggi chiave
L'uso di RDP Shortpath offre i vantaggi principali seguenti:
L'uso di URCP per migliorare UDP consente di ottenere prestazioni ottimali mediante l'apprendimento dinamico dei parametri di rete e la fornitura del protocollo con un meccanismo di controllo della frequenza.
La rimozione di punti di inoltro aggiuntivi riduce il tempo di round trip, migliorando l'affidabilità della connessione e l'esperienza utente con applicazioni e metodi di input sensibili alla latenza.
Inoltre, per le reti gestite:
RDP Shortpath offre supporto per la configurazione della priorità di Qualità del servizio (QoS) per le connessioni RDP tramite marcatori DSCP (Differentiated Services Code Point).
Il trasporto SHORTPATH RDP consente di limitare il traffico di rete in uscita specificando una velocità di limitazione per ogni sessione.
Funzionamento di RDP Shortpath
Per informazioni sul funzionamento di RDP Shortpath per reti gestite e reti pubbliche, selezionare ognuna delle schede seguenti.
La connettività direct line-of-sight significa che il client può connettersi direttamente all'host di sessione senza essere bloccato dai firewall.
Nota
Se si usano altri tipi di VPN per connettersi ad Azure, è consigliabile usare una VPN basata su UDP. Sebbene la maggior parte delle soluzioni VPN basate su TCP supporti l'UDP annidato, aggiunge un sovraccarico ereditato del controllo della congestione TCP, che rallenta le prestazioni RDP.
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:
L'host di sessione invia l'elenco degli indirizzi IPv4 e IPv6 al client.
Il client avvia il thread in background per stabilire un trasporto basato su UDP parallelo direttamente a uno degli indirizzi IP dell'host sessione.
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.
Se il client dispone di una connessione diretta all'host sessione, il client stabilisce una connessione sicura usando TLS su UDP affidabile.
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 indiretta:
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, verrà tentata una connessione UDP indiretta.
Connessione indiretta: TURN viene usato per stabilire una connessione indiretta, 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.
TURN autorizza in genere l'accesso al server tramite nome utente/password e la modalità di funzionamento preferita consiste nell'usare socket UDP. 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.
Suggerimento
RDP Shortpath per le reti pubbliche funzionerà automaticamente senza alcuna configurazione aggiuntiva, fornendo reti e firewall che consentono il traffico attraverso e le impostazioni di trasporto RDP nel sistema operativo Windows per gli host di sessione e i client usano i valori predefiniti.
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.
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. Nella maggior parte dei casi, il gateway NAT e il firewall sono le funzioni dello stesso dispositivo fisico o virtuale.
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:
L'host di sessione enumera tutte le interfacce di rete assegnate a un host di sessione, incluse interfacce virtuali come VPN e Teredo.
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.
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.
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.
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.
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.
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 indiretto usando TURN.
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.
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.
Importante
Quando si usa un trasporto basato su TCP, il traffico in uscita dall'host sessione al client avviene tramite il gateway Desktop virtuale Azure. Con RDP Shortpath per le reti pubbliche tramite STUN, il traffico in uscita viene stabilito direttamente tra l'host sessione e il client tramite Internet. In questo modo viene rimosso un hop che migliora la latenza e l'esperienza dell'utente finale. Tuttavia, a causa delle modifiche apportate al flusso di dati tra l'host sessione e il client in cui il gateway non viene più usato, verranno addebitati importi standard per la rete in uscita di Azure oltre a ogni sottoscrizione per la larghezza di banda Internet usata. Per altre informazioni sulla stima della larghezza di banda usata da RDP, vedere Requisiti di larghezza di banda RDP.
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 una singola IP:Porta a origine privata a una IP:Porta di destinazione pubblica univoca, è possibile usare una connessione indiretta 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.
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.
Disponibilità TURN (anteprima)
TURN è disponibile nelle aree di Azure seguenti:
Australia sud-orientale
India centrale
Stati Uniti orientali
Stati Uniti orientali 2
Francia centrale
Giappone occidentale
Europa settentrionale
Stati Uniti centro-meridionali
Asia sud-orientale
Regno Unito meridionale
Regno Unito occidentale
Europa occidentale
Stati Uniti occidentali
West US 2
Rete virtuale host sessione
Nome
Source
Porta di origine
Destinazione
Porta di destinazione
Protocollo
Azione
Endpoint server RDP Shortpath
Subnet VM
Qualsiasi
Qualsiasi
1024-65535 (Valore predefinito=49152-65535)
UDP
Consenti
STUN/TURN UDP
Subnet VM
Any
20.202.0.0/16
3478
UDP
Consenti
STUN/TURN TCP
Subnet VM
Any
20.202.0.0/16
443
TCP
Consenti
Rete client
Nome
Source
Porta di origine
Destinazione
Porta di destinazione
Protocollo
Azione
Endpoint server RDP Shortpath
Rete client
Any
Indirizzi IP pubblici assegnati al gateway NAT o a Firewall di Azure (fornito dall'endpoint STUN)
1024-65535 (Valore predefinito=49152-65535)
UDP
Consenti
STUN/TURN UDP
Rete client
Any
20.202.0.0/16
3478
UDP
Consenti
STUN/TURN TCP
Rete client
Any
20.202.0.0/16
443
TCP
Consenti
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.
Sicurezza delle connessioni
RDP Shortpath estende le funzionalità di trasporto multipli RDP. Non sostituisce il trasporto di connessione inversa, ma lo integra. Il brokering di sessione iniziale viene gestito tramite il servizio Desktop virtuale Azure e il trasporto di connessione inversa. Tutti i tentativi di connessione vengono ignorati a meno che non corrispondano prima alla sessione di connessione inversa. RDP Shortpath viene stabilito dopo l'autenticazione e, se stabilito correttamente, il trasporto di connessione inversa viene eliminato e tutti i flussi di traffico su RDP Shortpath.
RDP Shortpath usa una connessione sicura usando TLS su UDP affidabile tra il client e l'host sessione usando i certificati dell'host sessione. Per impostazione predefinita, il certificato usato per la crittografia RDP viene generato automaticamente dal sistema operativo durante la distribuzione. È anche possibile distribuire certificati gestiti centralmente rilasciati da un'autorità di certificazione aziendale. Per altre informazioni sulle configurazioni dei certificati, vedere Configurazioni del certificato del listener desktop remoto.
Nota
La sicurezza offerta da RDP Shortpath è identica a quella offerta dal trasporto di connessione inversa TCP.
Scenari di esempio
Ecco alcuni scenari di esempio per mostrare come vengono valutate le connessioni per decidere se RDP Shortpath viene usato in topologie di rete diverse.
Scenario 1
Una connessione UDP può essere stabilita solo tra il dispositivo client e l'host di sessione su una rete pubblica (Internet). Una connessione diretta, ad esempio una VPN, non è disponibile. UDP è consentito tramite il firewall o il dispositivo NAT.
Scenario 2
Un firewall o un dispositivo NAT blocca una connessione UDP diretta, ma è possibile inoltrare una connessione UDP indiretta usando TURN tra il dispositivo client e l'host sessione su una rete pubblica (Internet). Un'altra connessione diretta, ad esempio una VPN, non è disponibile.
Scenario 3
È possibile stabilire una connessione UDP tra il dispositivo client e l'host sessione su una rete pubblica o tramite una connessione VPN diretta; tuttavia, RDP Shortpath per le reti gestite non è abilitato. Quando il client avvia la connessione, il protocollo ICE/STUN può visualizzare più route e valuterà ogni route e sceglierà quella con la latenza più bassa.
In questo esempio, verrà stabilita una connessione UDP che usa il RDP Shortpath per le reti pubbliche sulla connessione VPN diretta, in quanto ha la latenza più bassa, come illustrato dalla linea verde.
Scenario 4
Entrambe le reti RDP Shortpath per le reti pubbliche e le reti gestite sono abilitate. È possibile stabilire una connessione UDP tra il dispositivo client e l'host sessione tramite una rete pubblica o tramite una connessione VPN diretta. Quando il client avvia la connessione, vengono eseguiti tentativi simultanei di connettersi usando RDP Shortpath per le reti gestite tramite la porta 3390 (per impostazione predefinita) e RDP Shortpath per le reti pubbliche tramite il protocollo ICE/STUN. Verrà usato il primo algoritmo trovato e l'utente userà la connessione stabilita per la prima volta per la sessione.
Poiché l'esecuzione di una rete pubblica prevede più passaggi, ad esempio un dispositivo NAT, un servizio di bilanciamento del carico o un server STUN, è probabile che il primo algoritmo trovato selezioni la connessione usando RDP Shortpath per le reti gestite e venga stabilita per prima.
Scenario 5
È possibile stabilire una connessione UDP tra il dispositivo client e l'host sessione su una rete pubblica o tramite una connessione VPN diretta; tuttavia, RDP Shortpath per le reti gestite non è abilitato. Per impedire che ICE/STUN usi una determinata route, un amministratore può bloccare una delle route per il traffico UDP. Il blocco di una route garantisce che il percorso rimanente venga sempre usato.
In questo esempio, UDP viene bloccato sulla connessione VPN diretta e il protocollo ICE/STUN stabilisce una connessione tramite la rete pubblica.
Scenario 6
Entrambe le reti RDP Shortpath per le reti pubbliche e le reti gestite sono configurate, ma non è stato possibile stabilire una connessione UDP usando una connessione VPN diretta. Un firewall o un dispositivo NAT blocca anche una connessione UDP diretta tramite la rete pubblica (Internet), ma è possibile inoltrare una connessione UDP indiretta usando TURN tra il dispositivo client e l'host sessione su una rete pubblica (Internet).
Scenario 7
Entrambe le reti RDP Shortpath per le reti pubbliche e le reti gestite sono configurate, ma non è stato possibile stabilire una connessione UDP. In questo caso, RDP Shortpath avrà esito negativo e la connessione eseguirà il fallback al trasporto di connessione inversa basato su TCP.
Presto disponibile: Nel corso del 2024 verranno gradualmente disattivati i problemi di GitHub come meccanismo di feedback per il contenuto e ciò verrà sostituito con un nuovo sistema di feedback. Per altre informazioni, vedere https://aka.ms/ContentUserFeedback.
