RDP Shortpath brengt een op UDP gebaseerd transport tot stand tussen een lokaal apparaat Windows App of de app Extern bureaublad op ondersteunde platforms en sessiehost in Azure Virtual Desktop. RdP (Remote Desktop Protocol) start standaard een reverse connect-transport op basis van TCP en probeert vervolgens een externe sessie tot stand te brengen met behulp van UDP. Als de UDP-verbinding slaagt, wordt de TCP-verbinding verwijderd, anders wordt de TCP-verbinding gebruikt als een terugvalverbindingsmechanisme.
Transport op basis van UDP biedt een betere betrouwbaarheid van de verbinding en een consistentere latentie. Tcp-gebaseerd reverse connect-transport biedt de beste compatibiliteit met verschillende netwerkconfiguraties en heeft een hoog slagingspercentage voor het tot stand brengen van RDP-verbindingen.
RDP Shortpath kan op twee manieren worden gebruikt:
Beheerde netwerken, waarbij directe connectiviteit tot stand wordt gebracht tussen de client en de sessiehost bij het gebruik van een privéverbinding, zoals Azure ExpressRoute of een site-naar-site virtueel particulier netwerk (VPN). Een verbinding met een beheerd netwerk wordt op een van de volgende manieren tot stand gebracht:
Een directe UDP-verbinding tussen het clientapparaat en de sessiehost, waarbij u de RDP Shortpath-listener moet inschakelen en een binnenkomende poort op elke sessiehost moet toestaan om verbindingen te accepteren.
Een directe UDP-verbinding tussen het clientapparaat en de sessiehost, met behulp van het Simple Traversal Underneath NAT-protocol (STUN) tussen een client en sessiehost. Binnenkomende poorten op de sessiehost hoeven niet te zijn toegestaan.
Openbare netwerken, waarbij directe connectiviteit tot stand wordt gebracht tussen de client en de sessiehost bij gebruik van een openbare verbinding. Er zijn twee verbindingstypen bij het gebruik van een openbare verbinding, die hier in volgorde van voorkeur worden vermeld:
Een directe UDP-verbinding met behulp van het STUN-protocol (Simple Traversal Under under NAT) tussen een client en sessiehost.
Een relay-UDP-verbinding met behulp van het TURN-protocol (Traversal Using Relay NAT) tussen een client en sessiehost.
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 netwerkvoorwaarden en biedt een eerlijk en volledig koppelingsgebruik. URCP werkt waar nodig met lage vertragings- en verliesniveaus.
Belangrijk
- RDP Shortpath voor openbare netwerken via STUN voor Azure Virtual Desktop is beschikbaar in de Azure openbare cloud en Azure Government cloud.
- RDP Shortpath voor openbare netwerken via TURN voor Azure Virtual Desktop is alleen beschikbaar in de Azure openbare cloud.
Belangrijkste voordelen
Het gebruik van RDP Shortpath heeft de volgende belangrijke voordelen:
Als u URCP gebruikt om UDP te verbeteren, worden de beste prestaties bereikt door netwerkparameters dynamisch te leren en het protocol te voorzien van een mechanisme voor snelheidscontrole.
Hogere doorvoer.
Wanneer U STUN gebruikt, vermindert het verwijderen van extra relaypunten de retourtijd om de betrouwbaarheid van de verbinding en de gebruikerservaring met latentiegevoelige toepassingen en invoermethoden te verbeteren.
Daarnaast geldt 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 kunt u uitgaand netwerkverkeer beperken door voor elke sessie een beperkingssnelheid 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 line-of-sight-connectiviteit bereiken die vereist is voor het gebruik van RDP Shortpath met beheerde netwerken met behulp van de volgende methoden.
Als u directe line-of-sight-connectiviteit hebt, betekent dit dat de client rechtstreeks verbinding kan maken met de sessiehost zonder te worden geblokkeerd door firewalls.
Opmerking
Als u andere VPN-typen gebruikt om verbinding te maken met Azure, raden we u aan een VPN op basis van UDP te gebruiken. Hoewel de meeste TCP-gebaseerde VPN-oplossingen geneste UDP ondersteunen, voegen ze overgenomen overhead van TCP-congestiebeheer toe, waardoor 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.
Het volgende diagram geeft een overzicht op hoog niveau van de netwerkverbindingen bij het gebruik van RDP Shortpath voor beheerde netwerken en sessiehosts die zijn gekoppeld aan een Active Directory-domein.
Verbindingsreeks
Alle verbindingen beginnen met het tot stand brengen van een reverse connect-transport op basis van TCP via de Azure Virtual Desktop Gateway. Vervolgens stellen de client en sessiehost het eerste RDP-transport tot stand en beginnen ze hun mogelijkheden uit te wisselen. Over deze mogelijkheden wordt 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 een parallel op UDP gebaseerd transport rechtstreeks naar een van de IP-adressen van de sessiehost tot stand te brengen.
Terwijl de client de opgegeven IP-adressen test, blijft deze de eerste verbinding tot stand brengen via het reverse connect-transport om ervoor te zorgen dat de gebruikersverbinding niet wordt vertraagd.
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.
Nadat het RDP Shortpath-transport tot stand is gebracht, worden alle dynamische virtuele kanalen (DVC's), inclusief externe afbeeldingen, invoer en apparaatomleiding, verplaatst naar het nieuwe transport. Als een firewall of netwerktopologie echter verhindert dat de client directe UDP-connectiviteit tot stand brengt, gaat RDP verder met een omgekeerde verbinding.
Als uw gebruikers zowel RDP Shortpath voor beheerde netwerken als openbare netwerken voor hen beschikbaar hebben, wordt het eerst gevonden algoritme gebruikt. De gebruiker gebruikt de verbinding die het eerst tot stand wordt gebracht voor die sessie.
Om de beste kans te bieden dat een UDP-verbinding slaagt bij het gebruik van een openbare verbinding, zijn er de typen directe en doorgegeven 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 van achter een NAT-gatewayapparaat en de client om het eigen openbare IP-adres te bepalen.
Een client kan STUN alleen gebruiken als het netwerk UDP-verkeer toestaat. Ervan uitgaande dat zowel de client als de sessiehost rechtstreeks naar het gedetecteerde IP-adres en de poort van de ander kunnen worden gerouteerd, wordt de communicatie tot stand gebracht met directe UDP via het WebSocket-protocol. Als firewalls of andere netwerkapparaten directe verbindingen blokkeren, wordt een relayed UDP-verbinding geprobeerd.
Relayed connection: TURN wordt gebruikt om een verbinding tot stand te brengen, waarbij verkeer wordt doorgegeven 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 vooraf bekend zijn, wat kan worden toegestaan via firewalls en andere netwerkapparaten.
Als firewalls of andere netwerkapparaten UDP-verkeer blokkeren, valt de verbinding terug op een omgekeerde verbinding op basis van TCP.
Wanneer een verbinding tot stand wordt gebracht, coördineert Interactive Connectivity Establishment (ICE) het beheer van STUN en TURN om de kans te optimaliseren dat een verbinding tot stand wordt gebracht en ervoor te zorgen dat voorkeursprotocollen voor netwerkcommunicatie voorrang krijgen.
Elke RDP-sessie maakt gebruik van een dynamisch toegewezen UDP-poort van een tijdelijk poortbereik (standaard 49152 tot 65535 ) die het RDP-shortpath-verkeer accepteert. Poort 65330 wordt in dit bereik genegeerd 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.
Tip
RDP Shortpath voor openbare netwerken werkt automatisch zonder aanvullende configuratie, mits netwerken en firewalls het verkeer door en RDP-transportinstellingen in het Windows-besturingssysteem toestaan voor sessiehosts en clients die hun standaardwaarden gebruiken.
Het volgende diagram geeft een overzicht op hoog niveau van de netwerkverbindingen bij het gebruik van RDP Shortpath voor openbare netwerken waar sessiehosts zijn gekoppeld aan Microsoft Entra ID.
Beschikbaarheid van turnrelais
TURN Relay is beschikbaar in de volgende Azure regio's met ACS TURN Relay (51.5.0.0/16):
- Australië - centraal
- Australië - oost
- Australië - zuidoost
- Brazilië - zuid
- Canada - centraal
- Canada - oost
- India - centraal
- VS - centraal
- VS - oost
- VS - oost 2
- Frankrijk - centraal
- Duitsland - west-centraal
- Israël - centraal
- Japan - oost
- Japan West
- Korea - centraal
- Korea - zuid
- Mexico - centraal
- VS - noord-centraal
- Europa - noord
- Noorwegen - west
- Zuid-Afrika - noord
- Zuid-Afrika - west
- VS - zuid-centraal
- Azië - zuidoost
- India - zuid
- Spanje - centraal
- Zwitserland - noord
- Tawain - noord
- Tawain Noordoost
- UAE - centraal
- UAE - noord
- VK - zuid
- VK - west
- VS - west-centraal
- Europa - west
- VS - west
- VS - west 2
- VS - west 3
Een TURN Relay wordt geselecteerd op basis van de fysieke locatie van het clientapparaat. Als een clientapparaat zich bijvoorbeeld in het VK bevindt, is de TURN-relay in de regio VK - zuid of VK - west geselecteerd. Als een clientapparaat zich ver van een TURN-relay bevindt, kan de UDP-verbinding terugvallen op TCP.
Netwerkadresomzetting en firewalls
De meeste Azure Virtual Desktop-clients worden uitgevoerd op computers in het particuliere netwerk. Internettoegang wordt geleverd via een NAT-gatewayapparaat (Network Address Translation). Daarom wijzigt de NAT-gateway alle netwerkaanvragen van het particuliere netwerk en bestemd voor internet. Een dergelijke wijziging is bedoeld om één openbaar IP-adres te delen op alle computers in het particuliere netwerk.
Vanwege de wijziging van het IP-pakket ziet de ontvanger van het verkeer het openbare IP-adres van de NAT-gateway in plaats van de werkelijke afzender. Wanneer verkeer terugkeert naar de NAT-gateway, zorgt deze ervoor dat deze zonder medeweten van de afzender wordt doorgestuurd naar de beoogde ontvanger. In de meeste scenario's zijn de apparaten die achter zo'n 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 Azure virtuele netwerken waar alle sessiehosts zich bevinden. Wanneer een sessiehost probeert het netwerkadres op internet te bereiken, voert de NAT-gateway (uw eigen of standaardinstelling van Azure) of Azure Load Balancer de adresomzetting uit. Zie SNAT (Source Network Address Translation) 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 aanvraag worden verzonden). Firewalls maken gebruik van verschillende technieken om de gegevensstroom bij te houden om onderscheid te maken tussen gevraagd en ongevraagd verkeer. In de context van TCP houdt de firewall SYN- en ACK-pakketten bij en het proces is eenvoudig. UDP-firewalls gebruiken meestal heuristiek op basis van pakketadressen om verkeer te koppelen aan UDP-stromen en dit toe te staan of te blokkeren. Er zijn veel verschillende NAT-implementaties beschikbaar.
Verbindingsreeks
Alle verbindingen beginnen met het tot stand brengen van een reverse connect-transport op basis van TCP via de Azure Virtual Desktop Gateway. Vervolgens stellen de client en sessiehost het eerste RDP-transport tot stand en beginnen ze hun mogelijkheden uit te wisselen. Als RDP Shortpath voor openbare netwerken is ingeschakeld op de sessiehost, start de sessiehost vervolgens een proces met de naam candidate gathering:
De sessiehost somt alle netwerkinterfaces op die zijn toegewezen aan een sessiehost, inclusief virtuele interfaces zoals VPN en Teredo.
De Windows-service Extern bureaublad-services (TermService) wijst UDP-sockets toe aan elke interface en slaat het IP:Port-paar op in de kandidaattabel als een lokale kandidaat.
De service Extern bureaublad-services gebruikt elke UDP-socket die in de vorige stap is toegewezen om te proberen de Azure Virtual Desktop STUN Server op het openbare internet te bereiken. De 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 in de tabel met kandidaten opgeslagen als een 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 kant uit. Vervolgens verzendt de client de lijst met kandidaten naar de sessiehost.
Nadat de sessiehost en client hun kandidatenlijsten hebben uitgewisseld, proberen beide partijen met elkaar verbinding te maken met behulp van alle verzamelde kandidaten. Deze verbindingspoging is gelijktijdig aan beide zijden. Veel NAT-gateways zijn geconfigureerd om het binnenkomende verkeer naar de socket toe te staan 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 is geblokkeerd, wordt er een verbindingspoging uitgevoerd met behulp van TURN.
Na de eerste pakketuitwisseling kunnen 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 heeft gemaakt, worden alle dynamische virtuele kanalen (DVC's), inclusief externe afbeeldingen, invoer en apparaatomleiding, verplaatst naar het nieuwe transport.
Als uw gebruikers zowel RDP Shortpath voor beheerde netwerken als openbare netwerken voor hen beschikbaar hebben, wordt het eerst gevonden algoritme gebruikt, wat betekent dat de gebruiker de verbinding gebruikt die het eerst tot stand wordt gebracht voor die sessie. Zie voorbeeldscenario 4 voor meer informatie.
Netwerkconfiguratie
Voor de 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 de mate van succes van de directe verbinding. Volg de aanbevelingen om de kans op een directe gegevensstroom te vergroten.
Omdat RDP Shortpath UDP gebruikt om een gegevensstroom tot stand te brengen, zal RDP Shortpath mislukken 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 van Azure Communication Services en Microsoft Teams. Door de aard van de functie is uitgaande connectiviteit van de sessiehosts naar de client vereist. Helaas kunt u in de meeste gevallen niet voorspellen waar uw gebruikers zich bevinden. Daarom raden we u aan om uitgaande UDP-connectiviteit van uw sessiehosts met internet toe te staan. Als u het vereiste aantal poorten wilt verminderen, kunt u het poortbereik beperken dat door clients wordt gebruikt voor de UDP-stroom. Gebruik de volgende tabellen ter referentie bij het configureren van firewalls voor RDP Shortpath.
Als uw omgeving gebruikmaakt van Symmetric NAT, dat wil doen met het toewijzen van één privébron-IP:Poort aan een uniek openbaar doel-IP:Poort, kunt u een relayverbinding met TURN gebruiken. Dit is het geval als u Azure Firewall en Azure NAT-gateway gebruikt. Zie Bronnetwerkadresomzetting met virtuele netwerken voor meer informatie over NAT met Azure virtuele netwerken.
We hebben enkele algemene aanbevelingen voor succesvolle verbindingen met behulp van RDP Shortpath voor openbare netwerken. Zie Algemene aanbevelingen voor meer informatie.
Als gebruikers RDP Shortpath hebben voor zowel beheerde netwerken als openbare netwerken, wordt het eerste gevonden algoritme gebruikt. De gebruiker gebruikt de verbinding die het eerst tot stand wordt gebracht voor die sessie. Zie Voorbeeldscenario's voor meer informatie.
De volgende secties bevatten de bron-, doel- en protocolvereisten voor uw sessiehosts en clientapparaten die moeten worden toegestaan om RDP-shortpath te laten werken.
Opmerking
Microsoft heeft de overgang voltooid van het eerder gedeelde 20.202.0.0/16-subnet naar het nieuwe IP-bereik 51.5.0.0/16 TURN relay in 39 Azure regio's. Dit nieuwe bereik is exclusief bestemd voor Azure Virtual Desktop en Windows 365, waardoor deze wordt gescheiden van de Azure Communication Services-infrastructuur. De upgrade is ontworpen om RDP Shortpath voor openbare netwerken (via TURN/Relay) te verbeteren, waardoor snellere, betrouwbaardere connectiviteit en een verbeterde gebruikerservaring worden geleverd.
Virtueel netwerk van sessiehost
In de volgende tabel worden de bron-, doel- en protocolvereisten voor RDP Shortpath voor het virtuele netwerk van uw sessiehost weergegeven.
| Naam |
Source |
Bronpoort |
Destination |
Doelpoort |
Protocol |
Actie |
| Directe STUN-verbinding |
VM-subnet |
Alle |
Alle |
1024-65535
(standaard 49152-65535) |
UDP |
Toestaan |
| STUN/TURN Relay |
VM-subnet |
Alle |
51.5.0.0/16 |
3478 |
UDP |
Toestaan |
Clientnetwerk
In de volgende tabel worden de bron-, doel- en protocolvereisten voor uw clientapparaten weergegeven.
| Naam |
Source |
Bronpoort |
Destination |
Doelpoort |
Protocol |
Actie |
| Directe STUN-verbinding |
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 relay |
Clientnetwerk |
Alle |
51.5.0.0/16 |
3478 |
UDP |
Toestaan |
Teredo-ondersteuning
Hoewel niet vereist voor RDP Shortpath, voegt Teredo extra NAT-traversal-kandidaten toe en vergroot de kans op een succesvolle RDP Shortpath-verbinding in IPv4-netwerken. Zie Teredo-ondersteuning inschakelen 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 zijde 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 over het algemeen beschikbaar op routers die zich doorgaans in een thuisnetwerk bevinden. UPnP is standaard ingeschakeld op 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 toegang hebben tot Azure Virtual Desktop via internet.
Zorg ervoor dat u geen dubbele NAT- of CGN-configuraties (Carrier-Grade-NAT) gebruikt.
Raad uw gebruikers aan UPnP niet uit te schakelen op hun thuisrouters.
Vermijd het gebruik van cloudpakketinspectieservices.
Vermijd het gebruik van VPN-oplossingen op basis van TCP.
IPv6-connectiviteit of Teredo inschakelen.
Verbindingsbeveiliging
RDP Shortpath breidt rdp multi-transport mogelijkheden uit. Het vervangt het reverse connect-transport niet, 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 reverse connect-sessie. RDP Shortpath wordt tot stand gebracht na verificatie en als dit is gelukt, wordt het transport van de omgekeerde verbinding verwijderd en stroomt al het verkeer via het RDP-shortpath.
RDP Shortpath maakt gebruik van een beveiligde verbinding met 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. Azure Virtual Desktop biedt momenteel geen ondersteuning voor het gebruik van een certificaat dat is uitgegeven door een certificeringsinstantie.
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
Een UDP-verbinding kan alleen tot stand worden gebracht tussen het clientapparaat en de sessiehost via een openbaar netwerk (internet). Er is geen directe verbinding, zoals een VPN, beschikbaar. UDP is toegestaan via een firewall of NAT-apparaat.
Scenario 2
Een firewall of NAT-apparaat blokkeert een directe UDP-verbinding, maar een relayed UDP-verbinding kan worden doorgegeven met 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 elke route evalueren en de route met de laagste latentie kiezen.
In dit voorbeeld wordt een UDP-verbinding met 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
Zowel RDP Shortpath voor openbare netwerken als 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 gelijktijdig pogingen om verbinding te maken met behulp van 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 het eerst tot stand wordt gebracht voor die sessie.
Aangezien het doorlopen van 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 brengt het ICE/STUN-protocol 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 relayed UDP-verbinding kan worden doorgegeven met 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.
Volgende stappen
