Het gebruik van RDP Shortpath voor openbare netwerken met TURN voor Azure Virtual Desktop is momenteel in PREVIEW. Raadpleeg de Aanvullende voorwaarden voor Microsoft Azure-previews voor juridische voorwaarden die van toepassing zijn op Azure-functies die in bèta of preview zijn of die anders nog niet algemeen beschikbaar zijn.
Verbinding maken ions naar Azure Virtual Desktop maken gebruik van Transmission Control Protocol (TCP) of User Datagram Protocol (UDP). RDP Shortpath is een functie van Azure Virtual Desktop waarmee een direct UDP-transport tot stand wordt gebracht tussen een ondersteunde Windows Remote Desktop-client en sessiehost. RdP (Remote Desktop Protocol) probeert standaard een verbinding tot stand te brengen met behulp van UDP en maakt gebruik van een op TCP gebaseerd reverse connect-transport als een terugvalverbindingsmechanisme. Reverse Connect-transport op basis van TCP biedt de beste compatibiliteit met verschillende netwerkconfiguraties en heeft een hoog succespercentage voor het tot stand brengen van RDP-verbindingen. UDP-transport biedt een betere betrouwbaarheid van verbindingen en consistentere latentie.
RDP Shortpath kan op twee manieren worden gebruikt:
Beheerde netwerken, waarbij directe connectiviteit tot stand wordt gebracht tussen de client en de sessiehost wanneer u een privéverbinding gebruikt, zoals een virtueel particulier netwerk (VPN).
Openbare netwerken, waarbij directe connectiviteit tot stand is gebracht tussen de client en de sessiehost wanneer u een openbare verbinding gebruikt. Er zijn twee verbindingstypen wanneer u een openbare verbinding gebruikt, die hier worden vermeld in volgorde van voorkeur:
Een directe UDP-verbinding met behulp van het Simple Traversal Under under NAT-protocol (STUN) tussen een client en sessiehost.
Een indirecte UDP-verbinding met behulp van het Traversal Using Relay NAT-protocol (TURN) met een relay tussen een client en sessiehost. Dit is in preview.
Het transport dat wordt gebruikt voor RDP Shortpath is gebaseerd op het UNIVERSAL Rate Control Protocol (URCP). URCP verbetert UDP met actieve bewaking van de netwerkomstandigheden en biedt eerlijk en volledig koppelingsgebruik. URCP werkt indien nodig op lage vertragings- en verliesniveaus.
RDP Shortpath voor openbare netwerken met TURN is alleen beschikbaar in de openbare Azure-cloud.
Belangrijkste voordelen
Het gebruik van RDP Shortpath heeft de volgende belangrijke voordelen:
Het gebruik van URCP om UDP te verbeteren, levert de beste prestaties door dynamisch netwerkparameters te leren en het protocol een mechanisme voor snelheidscontrole te bieden.
Het verwijderen van extra relaypunten vermindert de retourtijd, waardoor de betrouwbaarheid van de verbinding en gebruikerservaring met latentiegevoelige toepassingen en invoermethoden worden verbeterd.
Daarnaast geldt het volgende voor beheerde netwerken:
RDP Shortpath biedt ondersteuning voor het configureren van QoS-prioriteit (Quality of Service) voor RDP-verbindingen via DSCP-markeringen (Differentiated Services Code Point).
Met het RDP Shortpath-transport kan uitgaand netwerkverkeer worden beperkt door voor elke sessie een vertragingssnelheid op te geven.
Hoe RDP Shortpath werkt
Als u wilt weten hoe RDP Shortpath werkt voor beheerde netwerken en openbare netwerken, selecteert u elk van de volgende tabbladen.
U kunt de directe verbindingslijn bereiken die is vereist voor het gebruik van RDP Shortpath met beheerde netwerken met behulp van de volgende methoden.
Site-naar-site- of punt-naar-site-VPN (IPsec), zoals Azure VPN Gateway
Het hebben van directe verbindingslijn betekent dat de client rechtstreeks verbinding kan maken met de sessiehost zonder dat deze wordt geblokkeerd door firewalls.
Notitie
Als u andere VPN-typen gebruikt om verbinding te maken met Azure, raden we u aan een UDP-VPN te gebruiken. Hoewel de meeste OP TCP gebaseerde VPN-oplossingen geneste UDP ondersteunen, voegen ze overgenomen overhead van TCP-congestiebeheer toe, waardoor de RDP-prestaties worden vertraagd.
Als u RDP Shortpath wilt gebruiken voor beheerde netwerken, moet u een UDP-listener inschakelen op uw sessiehosts. Standaard wordt poort 3390 gebruikt, hoewel u een andere poort kunt gebruiken.
In het volgende diagram ziet u een algemeen overzicht van de netwerkverbindingen bij het gebruik van RDP Shortpath voor beheerde netwerken en sessiehosts die zijn toegevoegd aan een Active Directory-domein.
Verbinding maken reeks
Alle verbindingen beginnen met het tot stand brengen van een reverse connect-transport op basis van TCP via de Azure Virtual Desktop-gateway. Vervolgens brengt de client- en sessiehost het eerste RDP-transport tot stand en begint de uitwisseling van hun mogelijkheden. Deze mogelijkheden worden onderhandeld met behulp van het volgende proces:
De sessiehost verzendt de lijst met de IPv4- en IPv6-adressen naar de client.
De client start de achtergrondthread om rechtstreeks een parallel UDP-transport tot stand te brengen naar een van de IP-adressen van de sessiehost.
Terwijl de client de opgegeven IP-adressen doorneemt, blijft deze de eerste verbinding tot stand brengen via het reverse connect-transport om ervoor te zorgen dat er geen vertraging is in de gebruikersverbinding.
Als de client een directe verbinding met de sessiehost heeft, brengt de client een beveiligde verbinding tot stand met behulp van TLS via betrouwbare UDP.
Na het tot stand brengen van het RDP Shortpath-transport worden alle dynamische virtuele kanalen (DVCs), inclusief externe afbeeldingen, invoer en apparaatomleiding, verplaatst naar het nieuwe transport. Als een firewall of netwerktopologie echter voorkomt dat de client directe UDP-connectiviteit tot stand brengt, gaat RDP verder met een transport voor reverse connect.
Als uw gebruikers zowel RDP Shortpath hebben voor beheerde netwerken als openbare netwerken die voor hen beschikbaar zijn, wordt het eerst gevonden algoritme gebruikt. De gebruiker gebruikt de verbinding die eerst tot stand wordt gebracht voor die sessie.
Als u de beste kans wilt bieden dat een UDP-verbinding succesvol is wanneer u een openbare verbinding gebruikt, zijn er de typen directe en indirecte verbindingen:
Directe verbinding: STUN wordt gebruikt om een directe UDP-verbinding tot stand te brengen tussen een client en sessiehost. Om deze verbinding tot stand te brengen, moeten de client- en sessiehost verbinding met elkaar kunnen maken via een openbaar IP-adres en een onderhandelde poort. De meeste clients kennen echter hun eigen openbare IP-adres niet omdat ze zich achter een NAT-gatewayapparaat (Network Address Translation ) bevinden. STUN is een protocol voor de zelfdetectie van een openbaar IP-adres achter een NAT-gatewayapparaat en de client om een eigen openbaar IP-adres te bepalen.
Als een client STUN wil gebruiken, moet het netwerk UDP-verkeer toestaan. Ervan uitgaande dat zowel de client- als sessiehost rechtstreeks naar het gedetecteerde IP-adres en de poort van de andere kan worden gerouteerd, wordt communicatie tot stand gebracht met directe UDP via het WebSocket-protocol. Als firewalls of andere netwerkapparaten directe verbindingen blokkeren, wordt een indirecte UDP-verbinding geprobeerd.
Indirecte verbinding: TURN wordt gebruikt om een indirecte verbinding tot stand te brengen en verkeer door te sturen via een tussenliggende server tussen een client en sessiehost wanneer een directe verbinding niet mogelijk is. TURN is een uitbreiding van STUN. Het gebruik van TURN betekent dat het openbare IP-adres en de poort van tevoren bekend zijn, wat kan worden toegestaan via firewalls en andere netwerkapparaten.
TURN autoriseert doorgaans de toegang tot de server via gebruikersnaam/wachtwoord en de voorkeursmodus is het gebruik van UDP-sockets. Als firewalls of andere netwerkapparaten UDP-verkeer blokkeren, valt de verbinding terug op een op TCP gebaseerd reverse connect-transport.
Wanneer een verbinding tot stand wordt gebracht, coördineert Interactive Verbinding maken ivity Establishment (ICE) het beheer van STUN en TURN om de waarschijnlijkheid van een verbinding te optimaliseren en ervoor te zorgen dat prioriteit wordt gegeven aan voorkeursprotocollen voor netwerkcommunicatie.
Elke RDP-sessie maakt gebruik van een dynamisch toegewezen UDP-poort van een kortstondig poortbereik (standaard 49152 tot 65535 ) dat het RDP Shortpath-verkeer accepteert. Poort 65330 wordt genegeerd uit dit bereik omdat deze is gereserveerd voor intern gebruik door Azure. U kunt ook een kleiner, voorspelbaar poortbereik gebruiken. Zie Het poortbereik beperken dat wordt gebruikt door clients voor openbare netwerken voor meer informatie.
Fooi
RDP Shortpath voor openbare netwerken werkt automatisch zonder aanvullende configuratie, waardoor netwerken en firewalls het verkeer via en RDP-transportinstellingen in het Windows-besturingssysteem toestaan voor sessiehosts en clients hun standaardwaarden gebruiken.
In het volgende diagram ziet u een algemeen overzicht van de netwerkverbindingen bij het gebruik van RDP Shortpath voor openbare netwerken waarbij sessiehosts zijn toegevoegd aan Microsoft Entra ID.
Netwerkadresomzetting en firewalls
De meeste Azure Virtual Desktop-clients worden uitgevoerd op computers in het privénetwerk. Internettoegang wordt geboden via een NAT-gatewayapparaat (Network Address Translation). Daarom wijzigt de NAT-gateway alle netwerkaanvragen van het particuliere netwerk en bestemd voor internet. Deze wijziging is van plan één openbaar IP-adres te delen op alle computers in het particuliere netwerk.
Vanwege het wijzigen van IP-pakketten ziet de ontvanger van het verkeer het openbare IP-adres van de NAT-gateway in plaats van de werkelijke afzender. Wanneer verkeer terugkomt naar de NAT-gateway, zorgt dit ervoor dat het wordt doorgestuurd naar de beoogde ontvanger zonder de kennis van de afzender. In de meeste scenario's zijn de apparaten die achter een dergelijke NAT verborgen zijn, niet op de hoogte van de vertaling en weten ze het netwerkadres van de NAT-gateway niet.
NAT is van toepassing op de virtuele Azure-netwerken waar alle sessiehosts zich bevinden. Wanneer een sessiehost het netwerkadres op internet probeert te bereiken, voert de NAT-gateway (uw eigen of standaardinstelling van Azure) of Azure Load Balancer de adresomzetting uit. Zie Source Network Address Translation (SNAT) gebruiken voor uitgaande verbindingen voor meer informatie over verschillende typen Bronnetwerkadresomzetting.
De meeste netwerken bevatten doorgaans firewalls die verkeer inspecteren en blokkeren op basis van regels. De meeste klanten configureren hun firewalls om binnenkomende verbindingen te voorkomen (dat wil gezegd, ongevraagde pakketten van internet die zonder een verzoek worden verzonden). Firewalls maken gebruik van verschillende technieken om de gegevensstroom bij te houden om onderscheid te maken tussen aangevraagd en ongevraagd verkeer. In de context van TCP houdt de firewall SYN- en ACK-pakketten bij en is het proces eenvoudig. UDP-firewalls gebruiken meestal heuristieken op basis van pakketadressen om verkeer aan UDP-stromen te koppelen en toe te staan of te blokkeren.
Er zijn veel verschillende NAT-implementaties beschikbaar. In de meeste gevallen zijn NAT-gateway en firewall de functies van hetzelfde fysieke of virtuele apparaat.
Verbinding maken reeks
Alle verbindingen beginnen met het tot stand brengen van een reverse connect-transport op basis van TCP via de Azure Virtual Desktop-gateway. Vervolgens brengt de client- en sessiehost het eerste RDP-transport tot stand en begint de uitwisseling van hun mogelijkheden. Als RDP Shortpath voor openbare netwerken is ingeschakeld op de sessiehost, start de sessiehost vervolgens een proces met de naam kandidaat verzamelen:
De sessiehost bevat alle netwerkinterfaces die zijn toegewezen aan een sessiehost, inclusief virtuele interfaces zoals VPN en Teredo.
De Windows-service Extern bureaublad-services (TermService) wijst UDP-sockets toe op elke interface en slaat het IP:Port-paar op in de kandidaattabel als een lokale kandidaat.
De Service Extern bureaublad-services maakt gebruik van elke UDP-socket die in de vorige stap is toegewezen om de Azure Virtual Desktop STUN-server op het openbare internet te bereiken. Communicatie wordt uitgevoerd door een klein UDP-pakket naar poort 3478 te verzenden.
Als het pakket de STUN-server bereikt, reageert de STUN-server met het openbare IP-adres en de poort. Deze informatie wordt opgeslagen in de kandidaattabel als reflexieve kandidaat.
Nadat de sessiehost alle kandidaten heeft verzameld, gebruikt de sessiehost het tot stand gebrachte reverse connect-transport om de lijst met kandidaten door te geven aan de client.
Wanneer de client de lijst met kandidaten van de sessiehost ontvangt, voert de client ook het verzamelen van kandidaten aan zijn zijde uit. Vervolgens verzendt de client de lijst met kandidaten naar de sessiehost.
Nadat de sessiehost en client hun kandidaatlijsten hebben uitgewisseld, proberen beide partijen met elkaar te verbinden met behulp van alle verzamelde kandidaten. Deze verbindingspoging is aan beide zijden gelijktijdig. Veel NAT-gateways zijn zo geconfigureerd dat het binnenkomende verkeer naar de socket wordt toegestaan zodra de uitgaande gegevensoverdracht deze initialiseert. Dit gedrag van NAT-gateways is de reden dat de gelijktijdige verbinding essentieel is. Als STUN mislukt omdat deze wordt geblokkeerd, wordt er een indirecte verbindingspoging uitgevoerd met BEHULP van TURN.
Na de initiële pakketuitwisseling kan de client- en sessiehost een of meer gegevensstromen tot stand brengen. Vanuit deze gegevensstromen kiest RDP het snelste netwerkpad. De client brengt vervolgens een beveiligde verbinding tot stand met behulp van TLS via betrouwbare UDP met de sessiehost en initieert RDP Shortpath-transport.
Nadat RDP het RDP Shortpath-transport tot stand heeft gebracht, worden alle dynamische virtuele kanalen (DVCs), inclusief externe graphics, invoer en apparaatomleiding naar het nieuwe transport verplaatst.
Als uw gebruikers zowel RDP Shortpath hebben voor het beheerde netwerk als openbare netwerken die voor hen beschikbaar zijn, wordt het eerst gevonden algoritme gebruikt, wat betekent dat de gebruiker de verbinding gebruikt die eerst tot stand wordt gebracht voor die sessie. Zie voorbeeldscenario 4 voor meer informatie.
Belangrijk
Wanneer u een TCP-transport gebruikt, bevindt uitgaand verkeer van sessiehost naar client zich via de Azure Virtual Desktop-gateway. Met RDP Shortpath voor openbare netwerken met behulp van STUN wordt uitgaand verkeer rechtstreeks tot stand gebracht tussen sessiehost en client via internet. Hiermee verwijdert u een hop die de latentie en de ervaring van eindgebruikers verbetert. Vanwege de wijzigingen in de gegevensstroom tussen de sessiehost en de client waar de gateway niet meer wordt gebruikt, worden er standaard netwerkkosten voor uitgaand Verkeer van Azure in rekening gebracht naast het abonnement voor de verbruikte internetbandbreedte. Zie de vereisten voor RDP-bandbreedte voor meer informatie over het schatten van de bandbreedte die door RDP wordt gebruikt.
Netwerkconfiguratie
Ter ondersteuning van RDP Shortpath voor openbare netwerken hebt u doorgaans geen specifieke configuratie nodig. De sessiehost en client detecteren automatisch de directe gegevensstroom als dit mogelijk is in uw netwerkconfiguratie. Elke omgeving is echter uniek en sommige netwerkconfiguraties kunnen een negatieve invloed hebben op het succespercentage van de directe verbinding. Volg de aanbevelingen om de kans op een directe gegevensstroom te vergroten.
Omdat RDP Shortpath gebruikmaakt van UDP om een gegevensstroom tot stand te brengen, mislukt RDP Shortpath als een firewall op uw netwerk UDP-verkeer blokkeert en valt de verbinding terug op tcp-gebaseerd reverse connect-transport. Azure Virtual Desktop maakt gebruik van STUN-servers die worden geleverd door Azure Communication Services en Microsoft Teams. Uitgaande connectiviteit van de sessiehosts naar de client is vereist vanwege de aard van de functie. Helaas kunt u niet voorspellen waar uw gebruikers zich in de meeste gevallen bevinden. Daarom raden we u aan uitgaande UDP-connectiviteit van uw sessiehosts naar internet toe te staan. Als u het vereiste aantal poorten wilt beperken, kunt u het poortbereik beperken dat door clients voor de UDP-stroom wordt gebruikt. Gebruik de volgende tabellen ter referentie bij het configureren van firewalls voor RDP Shortpath.
Als uw omgeving symmetrische NAT gebruikt. Dit is de toewijzing van één privé-bron-IP :Poort naar een uniek openbaar doel-IP :Poort, dan kunt u een indirecte verbinding met TURN gebruiken. Dit is het geval als u Azure Firewall en Azure NAT Gateway gebruikt. Zie Bronnetwerkadresomzetting met virtuele netwerken met virtuele netwerken van Azure voor meer informatie over NAT met virtuele netwerken.
Waar gebruikers RDP Shortpath hebben voor zowel het beheerde netwerk als openbare netwerken, is voor hen beschikbaar, wordt het eerste gevonden algoritme gebruikt. De gebruiker gebruikt de verbinding die eerst tot stand wordt gebracht voor die sessie. Zie Voorbeeldscenario's voor meer informatie.
TURN-beschikbaarheid (preview)
TURN is beschikbaar in de volgende Azure-regio's:
Australië - zuidoost
India - centraal
VS - oost
VS - oost 2
Frankrijk - centraal
Japan - west
Europa - noord
VS - zuid-centraal
Azië - zuidoost
Verenigd Koninkrijk Zuid
Verenigd Koninkrijk West
Europa -west
VS - west
VS - west 2
Virtueel netwerk sessiehost
Naam
Source
Bronpoort
Doel
Doelpoort
Protocol
Actie
RDP Shortpath-servereindpunt
VM-subnet
Alle
Alle
1024-65535 (standaard 49152-65535)
UDP
Toestaan
STUN/TURN UDP
VM-subnet
Alle
20.202.0.0/16
3478
UDP
Toestaan
STUN/TURN TCP
VM-subnet
Alle
20.202.0.0/16
443
TCP
Toestaan
Clientnetwerk
Naam
Source
Bronpoort
Doel
Doelpoort
Protocol
Actie
RDP Shortpath-servereindpunt
Clientnetwerk
Alle
Openbare IP-adressen die zijn toegewezen aan NAT Gateway of Azure Firewall (geleverd door het STUN-eindpunt)
1024-65535 (standaard 49152-65535)
UDP
Toestaan
STUN/TURN UDP
Clientnetwerk
Alle
20.202.0.0/16
3478
UDP
Toestaan
STUN/TURN TCP
Clientnetwerk
Alle
20.202.0.0/16
443
TCP
Toestaan
Teredo-ondersteuning
Hoewel dit niet vereist is voor RDP Shortpath, voegt Teredo extra NAT-traversal kandidaten toe en verhoogt de kans op de succesvolle RDP Shortpath-verbinding in IPv4-netwerken. Zie Teredo-ondersteuning voor meer informatie over het inschakelen van Teredo op sessiehosts en -clients.
UPnP-ondersteuning
Om de kans op een directe verbinding te verbeteren, kan RDP Shortpath aan de zijkant van de Extern bureaublad-client UPnP gebruiken om een poorttoewijzing op de NAT-router te configureren. UPnP is een standaardtechnologie die wordt gebruikt door verschillende toepassingen, zoals Xbox, Delivery Optimization en Teredo. UPnP is algemeen beschikbaar op routers die doorgaans op een thuisnetwerk worden gevonden. UPnP is standaard ingeschakeld voor de meeste thuisrouters en toegangspunten, maar is vaak uitgeschakeld op bedrijfsnetwerken.
Algemene aanbevelingen
Hier volgen enkele algemene aanbevelingen bij het gebruik van RDP Shortpath voor openbare netwerken:
Vermijd het gebruik van configuraties voor geforceerde tunneling als uw gebruikers via internet toegang hebben tot Azure Virtual Desktop.
Zorg ervoor dat u geen dubbele NAT- of CGN-configuraties (Carrier-Grade-NAT) gebruikt.
Raad uw gebruikers aan om UPnP niet uit te schakelen op hun thuisrouters.
Vermijd het gebruik van services voor cloudpakketteninspectie.
Vermijd het gebruik van VPN-oplossingen op basis van TCP.
IPv6-connectiviteit of Teredo inschakelen.
Verbindingsbeveiliging
RDP Shortpath breidt RDP-mogelijkheden voor meerdere transporten uit. Het vervangt niet het omgekeerde verbindingstransport, maar vormt een aanvulling op het transport. Initiële sessiebrokering wordt beheerd via de Azure Virtual Desktop-service en het reverse connect-transport. Alle verbindingspogingen worden genegeerd, tenzij ze eerst overeenkomen met de sessie voor reverse connect. RDP Shortpath wordt tot stand gebracht na verificatie en als het tot stand is gebracht, wordt het reverse connect-transport verwijderd en loopt al het verkeer over het RDP Shortpath.
RDP Shortpath maakt gebruik van een beveiligde verbinding via TLS via betrouwbare UDP tussen de client en de sessiehost met behulp van de certificaten van de sessiehost. Standaard wordt het certificaat dat wordt gebruikt voor RDP-versleuteling zelf gegenereerd door het besturingssysteem tijdens de implementatie. U kunt ook centraal beheerde certificaten implementeren die zijn uitgegeven door een certificeringsinstantie voor ondernemingen. Zie de configuraties van het extern bureaublad-listenercertificaat voor meer informatie over certificaatconfiguraties.
Notitie
De beveiliging die wordt geboden door RDP Shortpath is hetzelfde als de beveiliging die wordt aangeboden door TCP reverse connect-transport.
Voorbeeldscenario's
Hier volgen enkele voorbeeldscenario's om te laten zien hoe verbindingen worden geëvalueerd om te bepalen of RDP Shortpath wordt gebruikt in verschillende netwerktopologieën.
Scenario 1
Er kan alleen een UDP-verbinding tot stand worden gebracht tussen het clientapparaat en de sessiehost via een openbaar netwerk (internet). Een directe verbinding, zoals een VPN, is niet beschikbaar. UDP is toegestaan via firewall of NAT-apparaat.
Scenario 2
Een firewall of NAT-apparaat blokkeert een directe UDP-verbinding, maar een indirecte UDP-verbinding kan worden doorgestuurd via TURN tussen het clientapparaat en de sessiehost via een openbaar netwerk (internet). Een andere directe verbinding, zoals een VPN, is niet beschikbaar.
Scenario 3
Er kan een UDP-verbinding tot stand worden gebracht tussen het clientapparaat en de sessiehost via een openbaar netwerk of via een directe VPN-verbinding, maar RDP Shortpath voor beheerde netwerken is niet ingeschakeld. Wanneer de client de verbinding initieert, kan het ICE/STUN-protocol meerdere routes zien en wordt elke route geëvalueerd en wordt de route met de laagste latentie gekozen.
In dit voorbeeld wordt een UDP-verbinding met BEHULP van RDP Shortpath voor openbare netwerken via de directe VPN-verbinding gemaakt omdat deze de laagste latentie heeft, zoals wordt weergegeven door de groene lijn.
Scenario 4
RdP Shortpath voor openbare netwerken en beheerde netwerken zijn ingeschakeld. Er kan een UDP-verbinding tot stand worden gebracht tussen het clientapparaat en de sessiehost via een openbaar netwerk of via een directe VPN-verbinding. Wanneer de client de verbinding initieert, zijn er gelijktijdige pogingen om verbinding te maken via RDP Shortpath voor beheerde netwerken via poort 3390 (standaard) en RDP Shortpath voor openbare netwerken via het ICE/STUN-protocol. Het eerst gevonden algoritme wordt gebruikt en de gebruiker gebruikt de verbinding die eerst tot stand wordt gebracht voor die sessie.
Omdat een openbaar netwerk meer stappen heeft, bijvoorbeeld een NAT-apparaat, een load balancer of een STUN-server, is het waarschijnlijk dat het eerst gevonden algoritme de verbinding selecteert met BEHULP van RDP Shortpath voor beheerde netwerken en eerst tot stand wordt gebracht.
Scenario 5
Er kan een UDP-verbinding tot stand worden gebracht tussen het clientapparaat en de sessiehost via een openbaar netwerk of via een directe VPN-verbinding, maar RDP Shortpath voor beheerde netwerken is niet ingeschakeld. Om te voorkomen dat ICE/STUN een bepaalde route gebruikt, kan een beheerder een van de routes voor UDP-verkeer blokkeren. Als u een route blokkeert, zorgt u ervoor dat het resterende pad altijd wordt gebruikt.
In dit voorbeeld wordt UDP geblokkeerd op de directe VPN-verbinding en het ICE/STUN-protocol brengt een verbinding tot stand via het openbare netwerk.
Scenario 6
Zowel RDP Shortpath voor openbare netwerken als beheerde netwerken zijn geconfigureerd, maar er kan geen UDP-verbinding tot stand worden gebracht met behulp van een directe VPN-verbinding. Een firewall of NAT-apparaat blokkeert ook een directe UDP-verbinding via het openbare netwerk (internet), maar een indirecte UDP-verbinding kan worden doorgestuurd via TURN tussen het clientapparaat en de sessiehost via een openbaar netwerk (internet).
Scenario 7
Zowel RDP Shortpath voor openbare netwerken als beheerde netwerken zijn geconfigureerd, maar er kan geen UDP-verbinding tot stand worden gebracht. In dit geval mislukt RDP Shortpath en valt de verbinding terug op TCP-gebaseerd reverse connect-transport.
