RDP Shortpath stabilisce un trasporto basato su UDP tra un'app di app di Windows del dispositivo locale o l'app Desktop remoto su piattaforme supportate e host sessione in Desktop virtuale di Azure. Per impostazione predefinita, il protocollo RDP (Desktop remoto Protocol) avvia un trasporto di connessione inversa basato su TCP, quindi tenta di stabilire una sessione remota utilizzando UDP. Se la connessione UDP ha esito positivo, la connessione TCP viene interrotta, altrimenti la connessione TCP viene utilizzata come meccanismo di connessione di fallback.
Il trasporto basato su UDP offre una migliore affidabilità della connessione e una latenza più costante. Il trasporto di connessione inversa basato su TCP offre la migliore compatibilità con varie configurazioni di rete e ha un'elevata percentuale di successo per stabilire connessioni RDP.
RDP Shortpath può essere utilizzato in due modi:
Reti gestite, in cui viene stabilita una connettività diretta tra il client e l'host di sessione quando si usa una connessione privata, ad esempio Azure ExpressRoute o una rete privata virtuale (VPN) da sito a sito. Una connessione tramite una rete gestita viene stabilita in uno dei seguenti modi:
Connessione UDP diretta tra il dispositivo client e l'host di sessione, in cui è necessario abilitare il listener RDP Shortpath e consentire a una porta in entrata in ogni host di sessione di accettare connessioni.
Connessione UDP diretta tra il dispositivo client e l'host di sessione, utilizzando il protocollo STUN (Simple Traversal Underneath NAT) 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 una connettività diretta tra il client e l'host di sessione quando si usa una connessione pubblica. Quando si usa una connessione pubblica, sono disponibili due tipi di connessione elencati di seguito in ordine di preferenza:
Connessione UDP diretta che usa il protocollo STUN (Simple Traversal Underneath NAT) tra un client e un host di sessione.
Connessione UDP inoltrata che utilizza il protocollo TURN (Traversal Using Relay NAT) tra un client e un host di sessione.
Il trasporto utilizzato per RDP Shortpath è basato sul protocollo URCP (Universal Rate Control Protocol). URCP migliora UDP con il monitoraggio attivo delle condizioni di rete e fornisce un utilizzo equo e completo del collegamento. URCP opera a bassi livelli di ritardo e perdita secondo necessità.
Importante
-
Cloud di Azure: RDP Shortpath per reti pubbliche tramite STUN e TURN è disponibile a livello generale.
-
Cloud di Azure per enti pubblici: RDP Shortpath tramite STUN e TURN è disponibile in anteprima pubblica con **server dedicati con intervallo IP **20.140.236.0/22. I clienti possono provare la funzionalità per l'host di sessione nell'anello di convalida.
Vantaggi principali
L'uso di RDP Shortpath presenta i vantaggi chiave seguenti:
L'utilizzo di URCP per migliorare UDP consente di ottenere le migliori prestazioni apprendendo dinamicamente i parametri di rete e fornendo al protocollo un meccanismo di controllo della velocità.
Velocità effettiva più elevata.
Quando si utilizza STUN, la rimozione di punti di relè aggiuntivi riduce il tempo di round trip, migliora 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 il supporto per la configurazione della priorità QoS (Quality of Service) per le connessioni RDP tramite contrassegni DSCP (Differentiated Services Code Point).
Il trasporto RDP Shortpath consente di limitare il traffico di rete in uscita specificando una velocità di limitazione per ogni sessione.
Come funziona RDP Shortpath
Per informazioni sul funzionamento di RDP Shortpath per le reti gestite e le reti pubbliche, seleziona ognuna delle seguenti schede.
È possibile ottenere la connettività diretta della linea di vista necessaria per usare RDP Shortpath con le reti gestite usando i metodi seguenti.
La connettività in linea di vista diretta significa che il client può connettersi direttamente all'host della 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 UDP annidato, aggiungono il 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 negli host di sessione. Per impostazione predefinita, viene utilizzata 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 Active Directory.
Sequenza di connessione
Tutte le connessioni iniziano stabilendo un trasporto di connessione inversa basato su TCP su Gateway Desktop virtuale Azure. Quindi, il client e l'host della sessione stabiliscono il trasporto RDP iniziale e iniziano a scambiarsi le loro funzionalità. Queste capacità vengono negoziate usando il processo seguente:
L'host di sessione invia l'elenco dei relativi indirizzi IPv4 e IPv6 al client.
Il client avvia il thread in background per stabilire un trasporto parallelo basato su UDP direttamente a uno degli indirizzi IP dell'host della sessione.
Mentre il client esegue il prospetto degli indirizzi IP forniti, continua a stabilire la connessione iniziale tramite il trasporto di connessione inversa per assicurarsi che non si verifichino ritardi nella connessione utente.
Se il client dispone di una connessione diretta all'host di sessione, il client stabilisce una connessione sicura utilizzando TLS su UDP affidabile.
Dopo aver stabilito il trasporto RDP Shortpath, tutti i canali virtuali dinamici (DVC), 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 hanno a disposizione sia RDP Shortpath per la rete gestita che per le reti pubbliche, verrà usato il primo algoritmo trovato. L'utente userà la connessione stabilita per prima per quella sessione.
Per fornire le migliori possibilità di successo di una connessione UDP quando si utilizza una connessione pubblica, sono disponibili i tipi di connessione diretta e inoltrata :
Connessione diretta: STUN viene utilizzato 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 trova 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 dal client per determinare il proprio indirizzo IP pubblico.
Affinché un client possa utilizzare STUN, la sua rete deve consentire il traffico UDP. Supponendo che sia il client che l'host di sessione possano instradare direttamente l'indirizzo IP e la porta scoperti dell'altro, la comunicazione viene stabilita con UDP diretto tramite il protocollo WebSocket. Se firewall o altri dispositivi di rete bloccano le connessioni dirette, viene tentata una connessione UDP inoltrata.
Connessione inoltrata: TURN viene utilizzato 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'utilizzo di TURN significa che l'indirizzo IP pubblico e la porta sono noti in anticipo, il che può essere consentito tramite firewall e altri dispositivi di rete.
Se 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, l'Interactive Connectivity Establishment (ICE) coordina la gestione di STUN e TURN per ottimizzare la probabilità che venga stabilita una connessione e garantire che venga data la precedenza ai protocolli di comunicazione di rete preferiti.
Ogni sessione RDP usa una porta UDP assegnata dinamicamente da un intervallo di porte temporaneo (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 ulteriori informazioni, vedere Limitazione dell'intervallo di porte utilizzato dai client per le reti pubbliche.
Consiglio
RDP Shortpath per le reti pubbliche funzionerà automaticamente senza alcuna configurazione aggiuntiva, a condizione che reti e firewall consentano il traffico attraverso e le impostazioni di trasporto RDP nel sistema operativo Windows per gli host e i client di sessione utilizzino i loro valori predefiniti.
Il diagramma seguente offre una panoramica di alto livello delle connessioni di rete quando si usa RDP Shortpath per le reti pubbliche in cui gli host di sessione sono stati aggiunti a Microsoft Entra ID.
Disponibilità relè TURN
L'inoltro TURN è disponibile nelle aree di Azure seguenti con inoltro TURN ACS (51.5.0.0/16):
- Australia centrale
- Australia orientale
- Australia sudorientale
- Brasile meridionale
- Canada centrale
- Canada orientale
- India centrale
- Stati Uniti centrali
- Stati Uniti orientali
- Stati Uniti orientali 2
- Francia centrale
- Germania Centro-Occidentale
- Israele centrale
- Giappone orientale
- Giappone occidentale
- Corea centrale
- Corea del Sud
- Messico centrale
- Stati Uniti centro-settentrionali
- Europa settentrionale
- Norvegia occidentale
- Sudafrica settentrionale
- Sudafrica orientale
- Stati Uniti centro-meridionali
- Asia sudorientale
- India meridionale
- Spagna centrale
- Svizzera nord
- Tawain Nord
- Tawain Nord-Est
- Emirati Arabi Uniti Centrali
- Emirati Arabi Uniti Settentrionali
- Regno Unito meridionale
- Regno Unito orientale
- Stati Uniti centro-occidentali
- Europa occidentale
- Stati Uniti occidentali
- Stati Uniti occidentali 2
- Stati Uniti occidentali 3
Viene selezionato un relè TURN in base alla posizione fisica del dispositivo client. Ad esempio, se un dispositivo client si trova nel Regno Unito, viene selezionato il relè TURN nella regione del Regno Unito meridionale o del Regno Unito occidentale. Se un dispositivo client è lontano da un relè 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 in 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 provenienti dalla rete privata e destinate a Internet. Tale modifica intende condividere un singolo indirizzo IP pubblico su tutti i computer della rete privata.
A causa della modifica del pacchetto IP, il destinatario del traffico vedrà l'indirizzo IP pubblico del gateway NAT anziché il mittente effettivo. Quando il traffico ritorna al gateway NAT, si occuperà di inoltrarlo al destinatario previsto all'insaputa del mittente. Nella maggior parte degli scenari, i dispositivi nascosti dietro un NAT di questo tipo non sono a conoscenza della conversione 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 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 dell'indirizzo. Per altre informazioni sui vari tipi di Source Network Address Translation, vedere Usare Source Network Address Translation (SNAT) per le connessioni in uscita.
La maggior parte delle reti in genere include firewall che ispezionano il traffico e lo bloccano in base a regole. La maggior parte dei clienti configura i propri firewall per impedire le connessioni in ingresso, ovvero i pacchetti non richiesti provenienti da Internet inviati senza richiesta. I firewall utilizzano diverse tecniche per tenere traccia del flusso di dati e distinguere tra traffico sollecitato e non richiesto. Nel contesto di TCP, il firewall tiene traccia dei pacchetti SYN e ACK e il processo è semplice. I firewall UDP utilizzano 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 su Gateway Desktop virtuale Azure. Quindi, il client e l'host della sessione stabiliscono il trasporto RDP iniziale e iniziano a scambiarsi le loro funzionalità. Se RDP Shortpath per reti pubbliche è abilitato sull'host di sessione, l'host di sessione avvia un processo denominato raccolta dei candidati:
L'host di sessione enumera tutte le interfacce di rete assegnate a un host di sessione, incluse le interfacce virtuali come VPN e Teredo.
Il servizio Windows Servizi Desktop remoto (TermService) alloca i socket UDP in ogni interfaccia e archivia la coppia IP:porta nella tabella dei candidati 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 su Internet pubblico. La comunicazione avviene inviando un piccolo pacchetto UDP alla porta 3478.
Se il pacchetto raggiunge il server STUN, il server STUN risponde con l'IP pubblico e la porta. Queste informazioni vengono archiviate nella tabella dei suggerimenti come candidato riflessivo.
Dopo che l'host della sessione ha raccolto tutti i candidati, l'host della sessione utilizza il trasporto di connessione inversa stabilito per passare l'elenco dei candidati al client.
Quando il client riceve l'elenco dei candidati dall'host della sessione, il client esegue anche la raccolta dei candidati da parte sua. Quindi il client invia il proprio elenco di candidati all'host della sessione.
Dopo che l'organizzatore della sessione e il cliente si sono scambiati le loro liste di candidati, entrambe le parti tentano di connettersi tra loro utilizzando 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 fallisce perché è bloccato, viene effettuato un tentativo di connessione inoltrata utilizzando TURN.
Dopo lo scambio di pacchetti iniziale, il client e l'host della 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 utilizzando TLS su UDP affidabile con l'host della sessione e avvia il trasporto di RDP Shortpath.
Dopo che RDP ha stabilito il trasporto RDP Shortpath, tutti i canali virtuali dinamici (DVC), inclusi grafica remota, input e reindirizzamento del dispositivo passano al nuovo trasporto.
Se gli utenti hanno a disposizione sia RDP Shortpath per la rete gestita che per le reti pubbliche, verrà utilizzato il primo algoritmo trovato, il che significa che l'utente utilizzerà la connessione stabilita per prima per quella sessione. Per altre informazioni, vedere lo scenario di esempio 4.
Configurazione di rete
Per supportare RDP Shortpath per le reti pubbliche, in genere non è necessaria alcuna configurazione particolare. L'host e il client della sessione individuano automaticamente il flusso di dati diretto, se possibile nella configurazione della rete. Tuttavia, ogni ambiente è unico e alcune configurazioni di rete possono influire negativamente sulla frequenza di successo della connessione diretta. Seguire le raccomandazioni per aumentare la probabilità di un flusso di dati diretto.
Poiché RDP Shortpath utilizza UDP per stabilire un flusso di dati, se un firewall sulla rete blocca il traffico UDP, RDP Shortpath avrà esito negativo e la connessione tornerà al trasporto di connessione inversa basato su TCP. Desktop virtuale Azure usa server STUN forniti dai Servizi di comunicazione di Azure e Microsoft Teams. In base alla natura della funzionalità, è necessaria la connettività in uscita dagli host di sessione al client. Nella maggior parte dei casi, purtroppo, non è possibile prevedere dove si trovano gli utenti. 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 utilizzato dai client per il flusso UDP. Utilizzare le tabelle seguenti come riferimento per la configurazione dei firewall per RDP Shortpath.
Se l'ambiente utilizza NAT simmetrico, ovvero il mapping di un singolo IP:Port di origine privata a un IP di destinazione pubblico univoco, è possibile utilizzare una connessione inoltrata con TURN. Questo accade se si usa Firewall di Azure e Gateway NAT di Azure. Per altre informazioni su NAT con le reti virtuali di Azure, vedere Conversione degli indirizzi di rete di origine con le reti virtuali.
Sono disponibili alcuni consigli generali per connessioni riuscite utilizzando 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à utilizzato il primo algoritmo trovato. L'utente userà la connessione stabilita per prima per quella 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.
Nota
Microsoft ha completato la transizione dalla subnet 20.202.0.0/16 condivisa in precedenza al nuovo intervallo IP di inoltro 51.5.0.0/16 TURN in 39 aree di Azure. Questa nuova gamma è dedicata esclusivamente a Desktop virtuale Azure e Windows 365, separandolo dall'infrastruttura dei Servizi di comunicazione di Azure. L'aggiornamento è progettato per migliorare RDP Shortpath per le reti pubbliche (tramite TURN/Relay), offrendo una connettività più veloce e affidabile e una migliore esperienza utente.
Nota
Le connessioni basate su TURN sono soggette a interruzioni di connessione durante gli aggiornamenti del relè TURN. Questi aggiornamenti si verificano in genere durante le finestre di manutenzione pianificate, ma occasionalmente possono verificarsi al di fuori della finestra pianificata a causa di correzioni urgenti dell'infrastruttura di Azure.
In tutti gli scenari precedenti, il client si riconnette automaticamente entro pochi secondi.
Rete virtuale host sessione
La tabella seguente illustra in dettaglio i requisiti di origine, destinazione e protocollo per RDP Shortpath per la rete virtuale host sessione.
| Nome |
Origine |
Porta di origine |
Destinazione |
Porta di destinazione |
Protocollo |
Azione |
| Connessione diretta STUN |
Subnet della macchina virtuale |
Qualsiasi |
Qualsiasi |
1024-65535
(predefinito 49152-65535) |
UDP |
Consenti |
| Relè STUN/TURN |
Subnet della macchina virtuale |
Qualsiasi |
51.5.0.0/16 |
3478 |
UDP |
Consenti |
Rete client
La tabella seguente illustra in dettaglio i requisiti di origine, destinazione e protocollo per i dispositivi client.
| Nome |
Origine |
Porta di origine |
Destinazione |
Porta di destinazione |
Protocollo |
Azione |
| Connessione diretta STUN |
Rete client |
Qualsiasi |
Indirizzi IP pubblici assegnati al gateway NAT o al firewall di Azure (forniti dall'endpoint STUN) |
1024-65535
(predefinito 49152-65535) |
UDP |
Consenti |
| Relè STUN/TURN |
Rete client |
Qualsiasi |
51.5.0.0/16 |
3478 |
UDP |
Consenti |
Importante
L'intervallo IP di inoltro TURN dedicato per Azure per enti pubblici è 20.140.236.0/22. RDP Shortpath tramite TURN è attualmente in anteprima pubblica in Azure per enti pubblici. I clienti possono provare la funzionalità usando l'anello di convalida.
Rete virtuale host sessione
La tabella seguente illustra in dettaglio i requisiti di origine, destinazione e protocollo per RDP Shortpath per la rete virtuale host sessione.
| Nome |
Origine |
Porta di origine |
Destinazione |
Porta di destinazione |
Protocollo |
Azione |
| Connessione diretta STUN |
Subnet della macchina virtuale |
Qualsiasi |
Qualsiasi |
1024-65535
(impostazione predefinita: 49152-65535) |
UDP |
Consenti |
| Relè STUN/TURN |
Subnet della macchina virtuale |
Qualsiasi |
20.140.236.0/22 |
3478 |
UDP |
Consenti |
Rete client
La tabella seguente illustra in dettaglio i requisiti di origine, destinazione e protocollo per i dispositivi client.
| Nome |
Origine |
Porta di origine |
Destinazione |
Porta di destinazione |
Protocollo |
Azione |
| Connessione diretta STUN |
Rete client |
Qualsiasi |
Indirizzi IP pubblici assegnati al gateway NAT o al firewall di Azure (forniti dall'endpoint STUN) |
1024-65535
(impostazione predefinita: 49152-65535) |
UDP |
Consenti |
| Relè STUN/TURN |
Rete client |
Qualsiasi |
20.140.236.0/22 |
3478 |
UDP |
Consenti |
Supporto per Teredo
Sebbene non sia necessario per RDP Shortpath, Teredo aggiunge ulteriori candidati per l'attraversamento NAT e aumenta le possibilità di connessione RDP Shortpath nelle reti solo IPv4. Per informazioni su come abilitare Teredo su host di sessione e client, vedi Abilitazione del supporto Teredo.
Supporto UPnP
Per migliorare le possibilità di una connessione diretta, sul lato del client Desktop remoto, RDP Shortpath può utilizzare UPnP per configurare un mapping delle porte sul router NAT. UPnP è una tecnologia standard usata da varie applicazioni, ad esempio Xbox, Ottimizzazione recapito e Teredo. UPnP è generalmente disponibile nei router che in genere si trovano su una rete domestica. UPnP è abilitato per impostazione predefinita nella maggior parte dei router e dei punti di accesso domestici, ma è spesso disabilitato nelle reti aziendali.
Raccomandazioni generali
Di seguito sono riportati alcuni consigli generali per l'utilizzo di RDP Shortpath per le reti pubbliche:
Evitare di usare le configurazioni di tunneling forzato se gli utenti accedono a Desktop virtuale Azure tramite Internet.
Assicurati di non utilizzare configurazioni NAT doppio o Carrier-Grade-NAT (CGN).
Consigliare agli utenti di non disabilitare UPnP nei router di casa.
Evita di utilizzare i servizi di ispezione dei pacchetti cloud.
Evitare di usare soluzioni VPN basate su TCP.
Abilita la connettività IPv6 o Teredo.
Sicurezza della connessione
RDP Shortpath estende le funzionalità di trasporto multiplo RDP. Non sostituisce il trasporto con connessione inversa ma lo completa. Il brokering della 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 tutto il traffico scorre su RDP Shortpath.
RDP Shortpath usa una connessione sicura tramite TLS su UDP affidabile tra il client e l'host della sessione usando i certificati dell'host della sessione. Per impostazione predefinita, il certificato usato per la crittografia RDP viene generato automaticamente dal sistema operativo durante la distribuzione. Desktop virtuale Azure non supporta l'uso di un certificato rilasciato da un'autorità di certificazione in questo momento.
Scenari di esempio
Di seguito sono riportati alcuni scenari di esempio per mostrare come vengono valutate le connessioni per decidere se RDP Shortpath viene utilizzato in topologie di rete diverse.
Scenario 1
È possibile stabilire una connessione UDP solo tra il dispositivo client e l'host della sessione tramite una rete pubblica (Internet). Una connessione diretta, ad esempio una VPN, non è disponibile. UDP è consentito tramite firewall o dispositivo NAT.
Scenario 2
Un firewall o un dispositivo NAT blocca una connessione UDP diretta, ma una connessione UDP inoltrata può essere inoltrata utilizzando TURN tra il dispositivo client e l'host della sessione su una rete pubblica (Internet). Non è disponibile un'altra connessione diretta, ad esempio una VPN.
Scenario 3
È possibile stabilire una connessione UDP tra il dispositivo client e l'host di sessione tramite una rete pubblica o una connessione VPN diretta, ma RDP Shortpath per le reti gestite non è abilitato. Quando il client avvia la connessione, il protocollo ICE/STUN può visualizzare più route e valuterà ciascuna route e sceglierà quella con la latenza più bassa.
In questo esempio, verrà effettuata una connessione UDP che utilizza RDP Shortpath per le reti pubbliche sulla connessione VPN diretta in quanto ha la latenza più bassa, come mostrato dalla linea verde.
Scenario 4
Sono abilitati sia RDP Shortpath per le reti pubbliche che per le reti gestite. È possibile stabilire una connessione UDP tra il dispositivo client e l'host di sessione tramite una rete pubblica o una connessione VPN diretta. Quando il client avvia la connessione, si verificano 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 prima per quella sessione.
Poiché il passaggio su una rete pubblica prevede più passaggi, ad esempio un dispositivo NAT, un bilanciamento del carico o un server STUN, è probabile che il primo algoritmo selezionato selezionerà la connessione utilizzando RDP Shortpath per le reti gestite e verrà stabilito per primo.
Scenario 5
È possibile stabilire una connessione UDP tra il dispositivo client e l'host di sessione tramite una rete pubblica o una connessione VPN diretta, ma RDP Shortpath per le reti gestite non è abilitato. Per impedire a ICE/STUN di utilizzare una determinata route, un amministratore può bloccare una delle route per il traffico UDP. Bloccando un percorso si garantisce che venga sempre usato il percorso rimanente.
In questo esempio, UDP è bloccato sulla connessione VPN diretta e il protocollo ICE/STUN stabilisce una connessione sulla rete pubblica.
Scenario 6
Sia RDP Shortpath per le reti pubbliche che per le reti gestite sono configurati, tuttavia non è stato possibile stabilire una connessione UDP usando la connessione VPN diretta. Anche un firewall o un dispositivo NAT blocca una connessione UDP diretta tramite la rete pubblica (Internet), ma una connessione UDP inoltrata può essere inoltrata utilizzando TURN tra il dispositivo client e l'host della sessione su una rete pubblica (Internet).
Scenario 7
Sia RDP Shortpath per le reti pubbliche che per le reti gestite sono configurati, tuttavia 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.
Passaggi successivi
