Användning av RDP Shortpath för offentliga nätverk med TURN för Azure Virtual Desktop är för närvarande i förhandsversion. Juridiska villkor för Azure-funktioner i betaversion, förhandsversion eller som av någon annan anledning inte har gjorts allmänt tillgängliga ännu finns i kompletterande användningsvillkor för Microsoft Azure-förhandsversioner.
Anslut ioner till Azure Virtual Desktop använder TCP (Transmission Control Protocol) eller UDP (User Datagram Protocol). RDP Shortpath är en funktion i Azure Virtual Desktop som upprättar en direkt UDP-baserad transport mellan en Windows Remote Desktop-klient och sessionsvärd som stöds. Som standard försöker RDP (Remote Desktop Protocol) upprätta en anslutning med UDP och använder en TCP-baserad omvänd anslutningstransport som reservanslutningsmekanism. TCP-baserad reverse connect-transport ger bästa möjliga kompatibilitet med olika nätverkskonfigurationer och har en hög framgångsgrad för att upprätta RDP-anslutningar. UDP-baserad transport ger bättre anslutningstillförlitlighet och mer konsekvent svarstid.
RDP Shortpath kan användas på två sätt:
Hanterade nätverk, där direktanslutning upprättas mellan klienten och sessionsvärden när du använder en privat anslutning, till exempel ett virtuellt privat nätverk (VPN).
Offentliga nätverk, där direktanslutning upprättas mellan klienten och sessionsvärden när du använder en offentlig anslutning. Det finns två anslutningstyper när du använder en offentlig anslutning, som anges här i prioritetsordning:
En direkt UDP-anslutning med hjälp av protokollet Simple Traversal Under NAT (STUN) mellan en klient och sessionsvärd.
En indirekt UDP-anslutning med hjälp av protokollet Traversal Using Relay NAT (TURN) med ett relä mellan en klient och sessionsvärd. Det här är en förhandsversion.
Transporten som används för RDP Shortpath baseras på URCP (Universal Rate Control Protocol). URCP förbättrar UDP med aktiv övervakning av nätverksvillkoren och ger rättvis och fullständig länkanvändning. URCP fungerar vid låga fördröjnings- och förlustnivåer efter behov.
Viktigt!
Under förhandsversionen är TURN endast tillgängligt för anslutningar till sessionsvärdar i en valideringsvärdpool. Information om hur du konfigurerar värdpoolen som en valideringsmiljö finns i Definiera värdpoolen som en valideringsmiljö.
RDP Shortpath för offentliga nätverk med TURN är endast tillgängligt i det offentliga Azure-molnet.
Viktiga fördelar
Att använda RDP Shortpath har följande viktiga fördelar:
Att använda URCP för att förbättra UDP ger bästa prestanda genom att dynamiskt lära sig nätverksparametrar och tillhandahålla protokollet med en hastighetskontrollmekanism.
Borttagningen av extra reläpunkter minskar tur och retur-tiden, vilket förbättrar anslutningens tillförlitlighet och användarupplevelse med svarstidskänsliga program och indatametoder.
Dessutom för hanterade nätverk:
RDP Shortpath ger stöd för att konfigurera QoS-prioritet (Quality of Service) för RDP-anslutningar via DSCP-märken (Differentiated Services Code Point).
Med RDP Shortpath-transport kan du begränsa utgående nätverkstrafik genom att ange en begränsningsfrekvens för varje session.
Så här fungerar RDP Shortpath
Om du vill veta hur RDP Shortpath fungerar för hanterade nätverk och offentliga nätverk väljer du var och en av följande flikar.
Plats-till-plats- eller punkt-till-plats-VPN (IPsec), till exempel Azure VPN Gateway
Att ha direkt anslutning till siktlinjen innebär att klienten kan ansluta direkt till sessionsvärden utan att blockeras av brandväggar.
Kommentar
Om du använder andra VPN-typer för att ansluta till Azure rekommenderar vi att du använder ett UDP-baserat VPN. Även om de flesta TCP-baserade VPN-lösningar stöder kapslad UDP lägger de till ärvda kostnader för TCP-överbelastningskontroll, vilket minskar RDP-prestanda.
Om du vill använda RDP Shortpath för hanterade nätverk måste du aktivera en UDP-lyssnare på sessionsvärdarna. Som standard används port 3390 , även om du kan använda en annan port.
Följande diagram ger en översikt på hög nivå över nätverksanslutningarna när du använder RDP Shortpath för hanterade nätverk och sessionsvärdar som är anslutna till en Active Directory-domän.
Anslut ionssekvens
Alla anslutningar börjar med att upprätta en TCP-baserad omvänd anslutningstransport över Azure Virtual Desktop Gateway. Sedan upprättar klient- och sessionsvärden den första RDP-transporten och börjar utbyta sina funktioner. Dessa funktioner förhandlas med hjälp av följande process:
Sessionsvärden skickar listan över sina IPv4- och IPv6-adresser till klienten.
Klienten startar bakgrundstråden för att upprätta en parallell UDP-baserad transport direkt till en av sessionsvärdens IP-adresser.
Medan klienten söker efter de angivna IP-adresserna fortsätter den att upprätta den första anslutningen via den omvända anslutningstransporten för att säkerställa att det inte finns någon fördröjning i användaranslutningen.
Om klienten har en direkt anslutning till sessionsvärden upprättar klienten en säker anslutning med hjälp av TLS över tillförlitlig UDP.
När RDP Shortpath-transporten har upprättats flyttas alla dynamiska virtuella kanaler (DVC), inklusive fjärrgrafik, indata och omdirigering av enheter, till den nya transporten. Men om en brandvägg eller nätverkstopologi hindrar klienten från att upprätta en direkt UDP-anslutning fortsätter RDP med en omvänd anslutningstransport.
Om dina användare har både RDP Shortpath för hanterat nätverk och offentliga nätverk tillgängliga för dem, kommer den först funna algoritmen att användas. Användaren använder den anslutning som upprättas först för den sessionen.
För att ge bästa möjliga chans att en UDP-anslutning lyckas när du använder en offentlig anslutning finns det direkta och indirekta anslutningstyper:
Direktanslutning: STUN används för att upprätta en direkt UDP-anslutning mellan en klient och sessionsvärd. För att upprätta den här anslutningen måste klienten och sessionsvärden kunna ansluta till varandra via en offentlig IP-adress och förhandlad port. De flesta klienter känner dock inte till sin egen offentliga IP-adress eftersom de sitter bakom en NAT-gatewayenhet (Network Address Translation ). STUN är ett protokoll för självidentifiering av en offentlig IP-adress bakom en NAT-gatewayenhet och klienten för att fastställa sin egen offentliga IP-adress.
För att en klient ska kunna använda STUN måste nätverket tillåta UDP-trafik. Förutsatt att både klient- och sessionsvärden kan dirigeras direkt till den andras identifierade IP-adress och port upprättas kommunikationen med direkt UDP via WebSocket-protokollet. Om brandväggar eller andra nätverksenheter blockerar direkta anslutningar provas en indirekt UDP-anslutning.
Indirekt anslutning: TURN används för att upprätta en indirekt anslutning som vidarebefordrar trafik via en mellanliggande server mellan en klient och sessionsvärd när en direkt anslutning inte är möjlig. TURN är ett tillägg av STUN. Användning av TURN innebär att den offentliga IP-adressen och porten är känd i förväg, vilket kan tillåtas via brandväggar och andra nätverksenheter.
TURN auktoriserar vanligtvis åtkomst till servern via användarnamn/lösenord och det önskade driftsättet är att använda UDP-socketar. Om brandväggar eller andra nätverksenheter blockerar UDP-trafik återgår anslutningen till en TCP-baserad omvänd anslutningstransport.
När en anslutning upprättas samordnar Interactive Anslut ivity Establishment (ICE) hanteringen av STUN och TURN för att optimera sannolikheten för att en anslutning upprättas och se till att prioritet ges till föredragna nätverkskommunikationsprotokoll.
Varje RDP-session använder en dynamiskt tilldelad UDP-port från ett tillfälliga portintervall (49152 till 65535 som standard) som accepterar RDP Shortpath-trafiken. Port 65330 ignoreras från det här intervallet eftersom den är reserverad för användning internt av Azure. Du kan också använda ett mindre, förutsägbart portintervall. Mer information finns i Begränsa det portintervall som används av klienter för offentliga nätverk.
Dricks
RDP Shortpath för offentliga nätverk fungerar automatiskt utan någon ytterligare konfiguration, förutsatt att nätverk och brandväggar tillåter trafik via och RDP-transportinställningar i Windows-operativsystemet för sessionsvärdar och klienter använder sina standardvärden.
Följande diagram ger en översikt på hög nivå över nätverksanslutningarna när du använder RDP Shortpath för offentliga nätverk där sessionsvärdar är anslutna till Microsoft Entra-ID.
Översättning av nätverksadresser och brandväggar
De flesta Azure Virtual Desktop-klienter körs på datorer i det privata nätverket. Internetåtkomst tillhandahålls via en NAT-gatewayenhet (Network Address Translation). Nat-gatewayen ändrar därför alla nätverksbegäranden från det privata nätverket och är avsedda för Internet. En sådan ändring avser att dela en enda offentlig IP-adress på alla datorer i det privata nätverket.
På grund av ändring av IP-paket ser mottagaren av trafiken den offentliga IP-adressen för NAT-gatewayen i stället för den faktiska avsändaren. När trafiken kommer tillbaka till NAT-gatewayen är det noga med att vidarebefordra den till den avsedda mottagaren utan avsändarens vetskap. I de flesta fall är enheterna som är dolda bakom en sådan NAT inte medvetna om att översättningen sker och inte känner till NAT-gatewayens nätverksadress.
NAT gäller för de virtuella Azure-nätverk där alla sessionsvärdar finns. När en sessionsvärd försöker nå nätverksadressen på Internet utför NAT Gateway (antingen din egen eller standard som tillhandahålls av Azure) eller Azure Load Balancer adressöversättningen. Mer information om olika typer av källnätverksadressöversättning finns i Använda SNAT (Source Network Address Translation) för utgående anslutningar.
De flesta nätverk innehåller vanligtvis brandväggar som inspekterar trafik och blockerar den baserat på regler. De flesta kunder konfigurerar sina brandväggar för att förhindra inkommande anslutningar (det vill: oönskade paket från Internet som skickas utan begäran). Brandväggar använder olika tekniker för att spåra dataflödet för att skilja mellan begärd och oönskad trafik. I samband med TCP spårar brandväggen SYN- och ACK-paket, och processen är enkel. UDP-brandväggar använder vanligtvis heuristik baserat på paketadresser för att associera trafik med UDP-flöden och tillåta eller blockera den.
Det finns många olika NAT-implementeringar tillgängliga. I de flesta fall är NAT-gateway och brandvägg funktioner för samma fysiska eller virtuella enhet.
Anslut ionssekvens
Alla anslutningar börjar med att upprätta en TCP-baserad omvänd anslutningstransport över Azure Virtual Desktop Gateway. Sedan upprättar klient- och sessionsvärden den första RDP-transporten och börjar utbyta sina funktioner. Om RDP Shortpath för offentliga nätverk är aktiverat på sessionsvärden initierar sessionsvärden sedan en process som kallas kandidatinsamling:
Sessionsvärden räknar upp alla nätverksgränssnitt som tilldelats en sessionsvärd, inklusive virtuella gränssnitt som VPN och Teredo.
Windows-tjänsten Remote Desktop Services (TermService) allokerar UDP-socketar i varje gränssnitt och lagrar IP:Port-paret i kandidattabellen som en lokal kandidat.
Tjänsten Fjärrskrivbordstjänster använder varje UDP-socket som allokerades i föregående steg för att försöka nå Azure Virtual Desktop STUN-servern på det offentliga Internet. Kommunikationen sker genom att skicka ett litet UDP-paket till port 3478.
Om paketet når STUN-servern svarar STUN-servern med den offentliga IP-adressen och porten. Den här informationen lagras i kandidattabellen som en reflexiv kandidat.
När sessionsvärden har samlat alla kandidater använder sessionsvärden den etablerade omvända anslutningstransporten för att skicka kandidatlistan till klienten.
När klienten tar emot listan över kandidater från sessionsvärden utför klienten även kandidatinsamling på sin sida. Sedan skickar klienten sin kandidatlista till sessionsvärden.
När sessionsvärden och klienten har bytt ut sina kandidatlistor försöker båda parter få kontakt med varandra med hjälp av alla insamlade kandidater. Det här anslutningsförsöket är samtidigt på båda sidor. Många NAT-gatewayer har konfigurerats för att tillåta inkommande trafik till socketen så snart den utgående dataöverföringen initierar den. Det här beteendet för NAT-gatewayer är anledningen till att den samtidiga anslutningen är nödvändig. Om STUN misslyckas på grund av att det är blockerat görs ett indirekt anslutningsförsök med HJÄLP av TURN.
Efter det första paketutbytet kan klient- och sessionsvärden upprätta ett eller flera dataflöden. Från dessa dataflöden väljer RDP den snabbaste nätverkssökvägen. Klienten upprättar sedan en säker anslutning med TLS över tillförlitlig UDP med sessionsvärden och initierar RDP Shortpath-transport.
När RDP har etablerat RDP Shortpath-transporten flyttas alla dynamiska virtuella kanaler (DVC), inklusive fjärrgrafik, indata och omdirigering av enheter till den nya transporten.
Om dina användare har både RDP Shortpath för hanterat nätverk och offentliga nätverk tillgängliga för dem, kommer den först funna algoritmen att användas, vilket innebär att användaren använder den anslutning som upprättas först för den sessionen. Mer information finns i exempelscenario 4.
Viktigt!
När du använder en TCP-baserad transport sker utgående trafik från sessionsvärden till klienten via Azure Virtual Desktop Gateway. Med RDP Shortpath för offentliga nätverk med STUN upprättas utgående trafik direkt mellan sessionsvärden och klienten via Internet. Detta tar bort ett hopp som förbättrar svarstiden och slutanvändarupplevelsen. Men på grund av ändringar i dataflödet mellan sessionsvärden och klienten där gatewayen inte längre används debiteras standardavgifter för azure-utgående nätverk utöver per prenumeration för den förbrukade Internetbandbredden. Mer information om hur du beräknar bandbredden som används av RDP finns i KRAV för RDP-bandbredd.
Konfiguration av nätverk
För att stödja RDP Shortpath för offentliga nätverk behöver du vanligtvis ingen särskild konfiguration. Sessionsvärden och -klienten identifierar automatiskt direktdataflödet om det är möjligt i nätverkskonfigurationen. Varje miljö är dock unik och vissa nätverkskonfigurationer kan påverka direktanslutningens framgångshastighet negativt. Följ rekommendationerna för att öka sannolikheten för ett direkt dataflöde.
Eftersom RDP Shortpath använder UDP för att upprätta ett dataflöde, om en brandvägg i nätverket blockerar UDP-trafik, misslyckas RDP Shortpath och anslutningen återgår till TCP-baserad omvänd anslutningstransport. Azure Virtual Desktop använder STUN-servrar som tillhandahålls av Azure Communication Services och Microsoft Teams. Med funktionens natur krävs utgående anslutning från sessionsvärdarna till klienten. Tyvärr kan du inte förutsäga var användarna finns i de flesta fall. Därför rekommenderar vi att du tillåter utgående UDP-anslutning från sessionsvärdarna till Internet. Om du vill minska antalet portar som krävs kan du begränsa det portintervall som används av klienter för UDP-flödet. Använd följande tabeller som referens när du konfigurerar brandväggar för RDP Shortpath.
Om din miljö använder symmetrisk NAT, som är mappningen av en enskild privat käll-IP :Port till en unik offentlig mål-IP :Port, kan du använda en indirekt anslutning med TURN. Detta gäller om du använder Azure Firewall och Azure NAT Gateway. Mer information om NAT med virtuella Azure-nätverk finns i Källnätverksadressöversättning med virtuella nätverk.
Där användare har RDP Shortpath för både hanterade nätverk och offentliga nätverk är tillgängliga för dem, kommer den första algoritmen som hittas att användas. Användaren använder den anslutning som upprättas först för den sessionen. Mer information finns i Exempelscenarier.
TURN-tillgänglighet (förhandsversion)
TURN är tillgängligt i följande Azure-regioner:
Australien, sydöstra
Indien, centrala
East US
USA, östra 2
Frankrike, centrala
Japan, västra
Europa, norra
USA, södra centrala
Sydostasien
Storbritannien, södra
Storbritannien, västra
Europa, västra
USA, västra
USA, västra 2
Virtuellt sessionsvärdnätverk
Name
Source
Källport
Mål
Målport
Protokoll
Åtgärd
RDP Shortpath Server-slutpunkt
Undernät för virtuell dator
Valfri
Valfri
1024-65535 (standard 49152-65535)
UDP
Tillåt
STUN/TURN UDP
Undernät för virtuell dator
Alla
20.202.0.0/16
3478
UDP
Tillåt
STUN/TURN TCP
Undernät för virtuell dator
Alla
20.202.0.0/16
443
TCP
Tillåt
Klientnätverk
Name
Source
Källport
Mål
Målport
Protokoll
Åtgärd
RDP Shortpath Server-slutpunkt
Klientnätverk
Alla
Offentliga IP-adresser tilldelade till NAT Gateway eller Azure Firewall (tillhandahålls av STUN-slutpunkten)
1024-65535 (standard 49152-65535)
UDP
Tillåt
STUN/TURN UDP
Klientnätverk
Alla
20.202.0.0/16
3478
UDP
Tillåt
STUN/TURN TCP
Klientnätverk
Alla
20.202.0.0/16
443
TCP
Tillåt
Teredo-stöd
Teredo krävs inte för RDP Shortpath, men lägger till extra NAT-bläddringar och ökar risken för en lyckad RDP Shortpath-anslutning i IPv4-nätverk. Information om hur du aktiverar Teredo på sessionsvärdar och -klienter finns i Teredo-supporten.
UPnP-stöd
För att förbättra risken för en direktanslutning kan RDP Shortpath på sidan av Fjärrskrivbordsklienten använda UPnP för att konfigurera en portmappning på NAT-routern. UPnP är en standardteknik som används av olika program, till exempel Xbox, Leveransoptimering och Teredo. UPnP är allmänt tillgängligt på routrar som vanligtvis finns i ett hemnätverk. UPnP är aktiverat som standard på de flesta hemroutrar och åtkomstpunkter, men är ofta inaktiverat i företagsnätverk.
Allmänna rekommendationer
Här följer några allmänna rekommendationer när du använder RDP Shortpath för offentliga nätverk:
Undvik att använda konfigurationer för tvingad tunneltrafik om användarna får åtkomst till Azure Virtual Desktop via Internet.
Kontrollera att du inte använder dubbla NAT- eller CARRIER-GRADE-NAT-konfigurationer (CGN).
Rekommendera dina användare att de inte inaktiverar UPnP på sina hemroutrar.
Undvik att använda cloud packet-inspection Services.
Undvik att använda TCP-baserade VPN-lösningar.
Aktivera IPv6-anslutning eller Teredo.
Anslutningssäkerhet
RDP Shortpath utökar RDP-funktioner för flera transporter. Den ersätter inte den omvända anslutningstransporten utan kompletterar den. Inledande sessionsutjämning hanteras via Azure Virtual Desktop-tjänsten och omvänd anslutningstransport. Alla anslutningsförsök ignoreras om de inte matchar den omvända anslutningssessionen först. RDP Shortpath upprättas efter autentisering, och om den har upprättats tas den omvända anslutningstransporten bort och alla trafikflöden över RDP Shortpath.
RDP Shortpath använder en säker anslutning med hjälp av TLS över tillförlitlig UDP mellan klienten och sessionsvärden med hjälp av sessionsvärdens certifikat. Som standard genereras certifikatet som används för RDP-kryptering av operativsystemet själv under distributionen. Du kan också distribuera centralt hanterade certifikat som utfärdats av en företagscertifikatutfärdare. Mer information om certifikatkonfigurationer finns i Certifikatkonfigurationer för lyssnarcertifikat för fjärrskrivbord.
Kommentar
Säkerheten som erbjuds av RDP Shortpath är densamma som den som erbjuds av TCP:s omvända anslutningstransport.
Exempelscenarier
Här följer några exempelscenarier som visar hur anslutningar utvärderas för att avgöra om RDP Shortpath används i olika nätverkstopologier.
Scenario 1
En UDP-anslutning kan bara upprättas mellan klientenheten och sessionsvärden via ett offentligt nätverk (Internet). En direktanslutning, till exempel ett VPN, är inte tillgänglig. UDP tillåts via brandvägg eller NAT-enhet.
Scenario 2
En brandvägg eller NAT-enhet blockerar en direkt UDP-anslutning, men en indirekt UDP-anslutning kan vidarebefordras med hjälp av TURN mellan klientenheten och sessionsvärden via ett offentligt nätverk (Internet). En annan direktanslutning, till exempel ett VPN, är inte tillgänglig.
Scenario 3
En UDP-anslutning kan upprättas mellan klientenheten och sessionsvärden via ett offentligt nätverk eller via en direkt VPN-anslutning, men RDP Shortpath för hanterade nätverk är inte aktiverat. När klienten initierar anslutningen kan ICE/STUN-protokollet se flera vägar och utvärdera varje väg och välja den med lägst svarstid.
I det här exemplet görs en UDP-anslutning med RDP Shortpath för offentliga nätverk via den direkta VPN-anslutningen eftersom den har den lägsta svarstiden, vilket visas av den gröna linjen.
Scenario 4
Både RDP Shortpath för offentliga nätverk och hanterade nätverk är aktiverade. En UDP-anslutning kan upprättas mellan klientenheten och sessionsvärden via ett offentligt nätverk eller via en direkt VPN-anslutning. När klienten initierar anslutningen görs samtidiga försök att ansluta med RDP Shortpath för hanterade nätverk via port 3390 (som standard) och RDP Shortpath för offentliga nätverk via ICE/STUN-protokollet. Den första hittade algoritmen används och användaren använder den anslutning som upprättas först för den sessionen.
Eftersom det finns fler steg i ett offentligt nätverk, till exempel en NAT-enhet, en lastbalanserare eller en STUN-server, är det troligt att algoritmen som först hittades väljer anslutningen med RDP Shortpath för hanterade nätverk och upprättas först.
Scenario 5
En UDP-anslutning kan upprättas mellan klientenheten och sessionsvärden via ett offentligt nätverk eller via en direkt VPN-anslutning, men RDP Shortpath för hanterade nätverk är inte aktiverat. För att förhindra att ICE/STUN använder en viss väg kan en administratör blockera någon av vägarna för UDP-trafik. Om du blockerar en väg ser du till att den återstående sökvägen alltid används.
I det här exemplet blockeras UDP på den direkta VPN-anslutningen och ICE/STUN-protokollet upprättar en anslutning via det offentliga nätverket.
Scenario 6
Både RDP Shortpath för offentliga nätverk och hanterade nätverk har konfigurerats, men det gick inte att upprätta en UDP-anslutning med direkt VPN-anslutning. En brandvägg eller NAT-enhet blockerar också en direkt UDP-anslutning med hjälp av det offentliga nätverket (Internet), men en indirekt UDP-anslutning kan vidarebefordras med hjälp av TURN mellan klientenheten och sessionsvärden via ett offentligt nätverk (Internet).
Scenario 7
Både RDP Shortpath för offentliga nätverk och hanterade nätverk har konfigurerats, men det gick inte att upprätta en UDP-anslutning. I det här fallet misslyckas RDP Shortpath och anslutningen återgår till TCP-baserad omvänd anslutningstransport.
