Kommentar
Åtkomst till den här sidan kräver auktorisering. Du kan prova att logga in eller ändra kataloger.
Åtkomst till den här sidan kräver auktorisering. Du kan prova att ändra kataloger.
För att säkerställa optimala prestanda och tillförlitlighet i din Windows 365 distribution är det viktigt att förstå de viktigaste anslutningskraven. Dessa krav är indelade i tre huvudkategorier:
RDP-anslutning (Remote Desktop Protocol) – gäller lika för både molnmiljön och fysiska klientenheter.
Molntjänstanslutning – Omfattar nätverkskrav från själva molndatorn till tjänsten.
Klientenhetsanslutning – Innehåller nätverkskonfigurationen för fysiska slutpunkter som har åtkomst till tjänsten.
Korrekt konfiguration av varje anslutningselement är viktigt för att leverera en sömlös Windows 365 upplevelse. Det här dokumentet fokuserar på att förstå tillgängliga RDP-anslutningsalternativ och hur du optimerar dem för högsta möjliga prestanda och tillförlitlighet.
Obs!
RDP-anslutning kräver särskild uppmärksamhet. Samma konfigurationsprinciper gäller för både molnbaserade och fysiska enheter.
RDP-anslutning
RDP-anslutning är en viktig komponent i Windows 365 upplevelse. Det gör det möjligt för användare att ansluta sömlöst till sina molndatorer och kräver noggrann nätverkskonfiguration för att säkerställa prestanda och tillförlitlighet.
Egenskaper för RDP-trafik
RDP-trafik har flera viktiga element som kräver särskild hänsyn:
Svarstidskänslig: RDP-trafik måste levereras med minimal fördröjning. RDP är skickligt på att hantera utmanande nätverksförhållanden, men optimering för så låg svarstid som möjligt bidrar till att upprätthålla en dynamisk användarupplevelse.
Realtid: I likhet med Microsoft Teams-medietrafik är RDP-trafik i realtid. Fördröjningar kan störa användarsessionen.
Hög volym: RDP-sessioner kan generera stora mängder trafik. Genom att dirigera den här trafiken effektivt och undvika kostsamma åtgärder, till exempel TLS-inspektion, kan du bevara prestanda och förhindra överbelastning av nätverksenheter.
Långlivade: RDP-anslutningar förblir ofta aktiva under längre perioder. Effektiv routning minskar påverkan på enheter som utför NAT (Network Address Translation) och stöder skalbarhet.
För att upprätthålla en högkvalitativ användarupplevelse bör RDP-trafik dirigeras via den mest direkta och effektiva vägen till Microsofts globala infrastruktur. Det är viktigt att undvika onödig inspektion, filtrering eller omvägar.
Viktigt
Om RDP-trafiken inte optimeras kan det leda till försämrad prestanda, sessions instabilitet och dålig tillförlitlighet för slutanvändarna.
Traditionell RDP jämfört med Windows 365 RDP
Windows 365 använder en moderniserad version av Remote Desktop Protocol (RDP), utformad för molnmiljöer och byggd för att ge en säker och sömlös upplevelse över olika nätverksförhållanden. Denna moderna RDP skiljer sig avsevärt från den RDP som används i traditionella fjärrskrivbordsmiljöer.
Traditionell RDP
Traditionell RDP, som ofta används i lokala miljöer, förlitar sig på inkommande anslutningar via TCP-port 3389 (Transmission Control Protocol) för att upprätta fjärrskrivbordssessioner. Den här metoden medför säkerhetsutmaningar eftersom det kräver att inkommande portar öppnas i nätverksperimetern.
Modern RDP i Windows 365
Windows 365 använder en modern, molnbaserad implementering av RDP som skiljer sig avsevärt från traditionella modeller. Det kräver ingen inkommande anslutning och förlitar sig på utgående trafik via följande protokoll och portar, som bör fungera i ett korrekt konfigurerat nätverk:
TCP-port 443
UDP-port 3478
Dessa anslutningar upprättas från både Cloud PC och klientenheten till Microsofts globala anslutningsinfrastruktur. Andra RDP-anslutningsmetoder kan också vara tillgängliga beroende på miljön och beskrivs också i den här artikeln.
Den här moderna RDP-modellen förbättrar säkerheten, förenklar distributionen och stöder tillförlitlig fjärrvisning och indata över olika nätverksförhållanden.
Viktigt
Windows 365 använder inte traditionell RDP. Ingen inkommande anslutning krävs för att få åtkomst till en molndator.
RDP-anslutningsmetoder i Windows 365
Windows 365 stöder flera RDP-anslutningsmetoder för att säkerställa tillförlitliga prestanda, även under utmanande nätverksförhållanden. Dessa metoder kan delas in i alternativ för offentliga och privata nätverksanslutningar.
Anslutningsmetoder för offentligt nätverk
Windows 365 stöder följande alternativ för offentlig anslutning. Dessa metoder är standard för tjänsten:
TCP-baserad omvänd anslutning: Det här är den primära metoden för alla anslutningar. Den använder utgående RDP via TCP-port 443 för att upprätta sessionen.
Vidarebefordrad UDP-baserad RDP-kortväg: Den här metoden använder utgående RDP via UDP-port 3478 och ansluter via Microsofts reläinfrastruktur för bättre medieprestanda.
Direkt UDP-baserad RDP-kortväg: Det här alternativet upprättar en direkt en-till-en-anslutning över UDP, vilket minskar svarstiden och förbättrar svarstiden. Den här metoden använder en STUN-server för att försöka hitta en fungerande direktanslutningssökväg mellan användaren och deras molndator
Private Network Connectivity-metod
- Direkt UDP över privata nätverk Aktiverar en en-till-en UDP-anslutning via ett privat nätverk. Den här metoden gäller endast för distributioner som använder Azure Nätverksanslutning (ANC). Den här metoden kan tekniskt sett vara möjlig via VPN-länkar, men det är osannolikt att den kommer att väljas som ett transportalternativ genom Windows 365 på grund av låga prestanda.
Obs!
Microsoft väljer automatiskt den mest optimala metoden baserat på nätverksförhållanden och distributionstyp. Ingen manuell konfiguration krävs för de flesta scenarier. Windows 365 stöder flera RDP-anslutningsmetoder för att säkerställa tillförlitliga prestanda, även under utmanande nätverksförhållanden.
RDP-anslutning för offentligt nätverk
TCP-baserad omvänd anslutning
Reverse Connect är standardmetoden som används för RDP-anslutningar i Windows 365. Den initierar utgående anslutning via TCP-port 443 och kräver ingen lyssnare på varken klientsidan eller Cloud PC-sidan. Den här metoden förenklar distributionen och förbättrar säkerheten genom att eliminera behovet av inkommande anslutningar och används för varje anslutning oavsett vilken metod som används.
Så här fungerar Reverse Connect
Installation av fjärrskrivbordsagent: Under etableringen installeras fjärrskrivbordsagenten på molndatorn för att hantera anslutningen.
Permanent signalsession: Vid start upprättar RD-agenten en beständig, utgående TLS-krypterad signalsession till Windows 365 infrastruktur. Den här processen är automatisk och kräver ingen manuell konfiguration.
Användarinloggning: På den fysiska klientenheten loggar användaren in med en klient som stöds, till exempel Windows App.
Autentisering: Microsoft Entra ID autentiserar användaren och returnerar en token som räknar upp användarens tillgängliga resurser.
Tokenverifiering: Klienten skickar token till feedprenumerationstjänsten, som verifierar den.
Resursuppräkning: Tjänsten returnerar en lista över tillgängliga molndatorer för användaren i form av digitalt signerade anslutningskonfigurationer.
Lagring av anslutningskonfiguration: Klienten lagrar dessa konfigurationer som
.rdpfiler för varje resurs.Initiering av anslutning: När användaren väljer en molndator ansluter klienten till Azure Front Door (AFD) via en anycast-lyssnare. Den närmaste AFD-noden väljs automatiskt baserat på nätverkets utgående trafik.
Gatewayval: AFD utvärderar svarstiden till alla tillgängliga gatewayer och väljer den som har lägst svarstid och minst aktiva anslutningar.
Säker gatewayanslutning: Klienten ansluter till den valda gatewayen med en säker TLS 1.3-anslutning. Gatewayen verifierar begäran och kontaktar den asynkrona meddelandekön.
Orchestration för asynkron meddelandekö: Asynkron meddelandekö identifierar cloud pc-målet och använder den befintliga signalkanalen för att initiera sessionen.
Anslutning till molndator: Fjärrskrivbordsstacken på molndatorn initierar en utgående TLS 1.3-anslutning till samma gatewayinstans.
DataRelä: När båda slutpunkterna är anslutna vidarebefordrar gatewayen data mellan dem och utgör den grundläggande reverse connect-transporten med hjälp av en kapslad tunnel och den högsta ömsesidigt stödda TLS-versionen (upp till TLS 1.3).
RDP-handskakning Klienten påbörjar RDP-handskakningen för att upprätta sessionen.
Diagram 1: Omvänd anslutning av RDP över TCP-port 443
Direkt UDP-baserad RDP-kortväg (med STUN)
Windows 365 använder även UDP-baserad RDP-anslutning för att förbättra sessionsprestanda, tillförlitlighet och dataflöde. När en TCP-baserad reverse connect-session har upprättats försöker Windows 365 uppgradera transporten till UDP med någon av två metoder:
Direkt RDP-kortväg: Upprättar en en-till-en UDP-anslutning med hjälp av STUN för att underlätta.
Vidarebefordrad RDP-kortväg: Använder TURN för att vidarebefordra UDP-trafik via en känd IP-adress och port.
Så här fungerar Direct UDP Shortpath
Inledande TCP-anslutning: RDP-sessionen börjar över en TCP-baserad reverse connect-transport via gatewayen enligt beskrivningen i det här dokumentet.
Skapa UDP Socket: Om RDP Shortpath är aktiverat på Cloud PC (aktiverat som standard) skapar tjänsten UDP-socketar i alla fungerande nätverksgränssnitt.
STUN-identifiering: Cloud PC försöker ansluta till en Windows 365 STUN-server på UDP-port 3478. Den här tillfälliga anslutningen identifierar nat-enhetens externa IP-adress och port. Ingen RDP-trafik dirigeras via STUN-servern.
Kandidatutbyte: Cloud PC delar sin kandidat-IP- och portinformation med klienten via den etablerade TCP-sessionen. Klienten skickar också en egen kandidatlista.
Anslutningsförsök: Båda slutpunkterna försöker upprätta en direkt UDP-anslutning samtidigt. Eftersom båda initierar utgående trafik lyckas den här metoden ofta även genom restriktiva brandväggar med en NAT-typ som stöds.
Transportutvärdering: Om direktanslutningen lyckas och bedöms vara den snabbaste sökvägen växlar alla dynamiska virtuella kanaler, till exempel grafik, indata och omdirigering av enheter, till den nya UDP-transporten.
Flytta till TURN: Om det inte går att upprätta STUN-baserad anslutning försöker systemet ansluta till TURN-servrar på UDP-port 3478. Detta möjliggör vidarebefordrad UDP-anslutning, som har en högre framgångsgrad för olika nätverksförhållanden på grund av dess förmåga att arbeta på alla NAT-typer och kända IP-undernät & port.
Obs!
Den här anslutningsmetoden passerar inte STUN-servern. STUN-servern används endast under den inledande anslutningsfasen för att identifiera NAT-konfigurationen på båda sidor och aktivera en en-till-en-anslutning.
UDP-baserad RDP Shortpath förbättrar prestanda och tillförlitlighet. Den försöker automatiskt efter TCP-baserad omvänd anslutning och kräver ingen manuell konfiguration förutom trafikoptimering.
Diagram 2: RDP-anslutning med RDP-kortväg med STUN
Kända utmaningar med Direct RDP Shortpath (använda STUN)
Direct RDP Shortpath förlitar sig på STUN för att upprätta en en-till-en UDP-anslutning. Även om den här metoden ger betydande prestandafördelar jämfört med TCP-baserad RDP-anslutning kanske den inte lyckas i vissa nätverksmiljöer på grund av begränsningar i NAT-beteende och brandväggskonfigurationer. För att den här anslutningsmodellen ska lyckas måste NAT-typen i nätverken för både den fysiska enheten och molndatorn vara av en typ som stöds.
Det är också ofta svårt att identifiera de IP-adresser som krävs för den här typen av anslutning i förväg, till exempel när du konfigurerar en VPN- eller SWG-förbikoppling (Secure Web Gateway) för fjärranvändare.
Scenarier där Direct RDP Shortpath kan misslyckas
Direktanslutning kanske inte fungerar under följande förhållanden, varav många är vanliga i företagsnätverk:
Dubbel NAT: Trafik som dirigeras via en säker webbgateway (SWG) eller proxy tillämpar till exempel NAT (Network Address Translation) två gånger, en gång på Azure utgående och igen vid VPN- eller SWG-slutpunkten.
Internetproxy eller inspektionsenheter: Routning via proxyservrar eller enheter som inspekterar trafik kan störa STUN-baserad anslutning. Det kan vara svårt att kringgå dessa enheter på grund av bristande förkunskaper om NAT IP-information.
Symmetrisk NAT: Symmetrisk NAT på cloud pc- eller klientsidan förhindrar lyckade STUN-förhandlingar, vilket är vanligt i företagsnätverk. Azure NAT Gateway använder den här NAT-typen precis som många andra vanliga NAT-enheter för företag.
Begränsad UDP-åtkomst: Nätverk som blockerar eller begränsar UDP-trafik, eller begränsar åtkomsten till specifika portar eller IP-intervall, förhindrar direktanslutning och är vanliga i företagsnätverk. Det är svårt att kringgå den här begränsningen på grund av bristen på förkunskaper om de portar och IP-adresser som används för anslutningen.
CARRIER GRADE NAT (CGN): När flera nätverk delar en offentlig IP-adress kan STUN inte upprätta en unik sökväg.
På grund av dessa begränsningar kan du behandla den här metoden som en metod för bästa förmåga och undvika att investera betydande ansträngningar för att få den att fungera. Prioritera i stället optimering av vidarebefordrad UDP via TURN, som fungerar tillförlitligt i nästan alla nätverksförhållanden.
Läs mer om RDP-kortsökväg här.
Tips
Använd verktyget avdnettest för att kontrollera nat-typen som används i nätverksmiljön.
Användning av vidarebefordrad RDP-kortväg
På grund av dessa begränsningar är Direct RDP Shortpath en anslutningsmodell med bästa förmåga. Om det inte kan upprättas återgår Windows 365 automatiskt till Relayed RDP Shortpath, som använder TURN-servrar och har en betydligt högre framgångsgrad. Den här metoden fungerar tillförlitligt eftersom undernätet och portkraven för utgående trafik är kända i förväg och därför kan öppnas och optimeras enkelt.
Obs!
Vidarebefordrad RDP-kortväg garanterar konsekvent anslutning över ett bredare utbud av nätverksförhållanden och kräver inte heller någon inkommande åtkomst.
Vidarebefordrad UDP-baserad RDP-kortväg (med TURN)
Reläad RDP Shortpath är en tillförlitlig metod för UDP-baserad RDP-anslutning när det inte går att dirigera Shortpath. Den här metoden använder globalt distribuerade TURN-servrar i Microsofts infrastruktur för att vidarebefordra RDP-trafik mellan klienten och Cloud PC. Den här anslutningsmodellen fungerar automatiskt och kräver ingen annan konfiguration än optimering av den trafik som krävs. Det är viktigt att den här anslutningsmetoden konfigureras och optimeras i dina nätverksmiljöer.
Viktiga fördelar
Kringgår NAT-begränsningar: Till skillnad från STUN-baserade direktanslutningar påverkas inte TURN-reläer av dubbla NAT-, symmetriska NAT- eller brandväggsbegränsningar.
Global räckvidd: TURN-servrar distribueras i över 47 regioner över hela världen, vilket gör att trafik kan vidarebefordras via en plats nära användaren för optimala prestanda.
Förutsägbar konfiguration: Vidarebefordrad trafik använder kända IP-undernät och portar, vilket möjliggör brandväggs- och nätverksoptimering, inklusive proxy, säker webbgateway (SWG) och VPN-förbikoppling.
Så här fungerar relayed RDP Shortpath
TCP-baserad omvänd anslutning: RDP-sessionen börjar via TCP-port 443 med metoden Reverse Connect.
Direct RDP Shortpath-försök: Systemet försöker upprätta en direkt UDP-anslutning med hjälp av STUN.
Konfigurera TURN-anslutning: Om direktanslutningen misslyckas försöker både klienten och Cloud PC utgående anslutningar till TURN-infrastrukturen på UDP-port 3478, specifikt för det dedikerade undernätet 51.5.0.0/16.
Transportutvärdering: Om den vidarebefordrade anslutningen lyckas och bedöms vara den snabbaste sökvägen växlar alla dynamiska virtuella kanaler, till exempel grafik, indata och omdirigering av enheter, till den nya transporten.
TCP Persistence: Om ingen UDP-metod lyckas fortsätter RDP-sessionen över den befintliga TCP-anslutningen.
RDP Multipath: Med RDP Multipath upprättas flera UDP-anslutningar för sömlös fortsatt anslutning om det uppstår problem på den aktiva sökvägen.
Diagram 3: Alla offentliga RDP-alternativ
Obs!
Vidarebefordrad RDP Shortpath aktiveras automatiskt och kräver ingen manuell konfiguration. Det säkerställer konsekvent anslutning i en mängd olika nätverksmiljöer. Mer information om RDP-kortsökväg för offentliga nätverk finns här.
RDP-anslutning för privat nätverk
RDP-kortväg för hanterade nätverk
Windows 365 stöder en fjärde RDP-anslutningsmetod för hanterade, privata nätverk. Det här alternativet är endast tillgängligt i specifika distributionsscenarier och erbjuder direkt UDP-anslutning mellan klientenheten och Cloud PC.
Viktigt
Den här metoden krävs inte för att uppnå högpresterande anslutning till tjänsten. De primära metoderna och standardmetoderna är de offentliga metoder som beskrivs i den här artikeln.
Tillgänglighetsvillkor
RDP Shortpath för hanterade nätverk stöds endast när:
Distributionen använder Azure Nätverksanslutning (ANC). Den här anslutningsmetoden är inte tillgänglig för Microsoft-värdbaserade nätverksdistributioner.
Det finns direkt siktlinje mellan den fysiska enheten och molndatorn, via ExpressRoute eller plats-till-plats-VPN.
Nätverkssökvägen tillåter att trafik passerar. Brandväggsregler måste tillåta de portar, protokoll och IP-intervall som krävs.
Anslutningsmetoder
Den här anslutningen kan upprättas på något av två sätt:
RDP Shortpath-lyssnare: När den är konfigurerad lyssnar Cloud PC på UDP-port 3390 efter inkommande anslutningar.
ICE/STUN-identifiering: Om lyssnarmetoden inte är genomförbar används ICE/STUN för att identifiera tillgängliga IP-adresser och förhandla fram en dynamisk port. Portintervallet kan konfigureras om det behövs.
När UDP-anslutningen har upprättats tas den TCP-baserade offentliga sökvägen bort och sessionen fortsätter över det privata nätverket.
Mer information finns i dokumentationen om RDP Shortpath för privata nätverk
Diagram 4: RDP-kortväg för privata nätverk
Obs!
Den här metoden ger direktanslutning i hanterade nätverksmiljöer men kräver specifika konfigurations- och nätverksvillkor. Den offentliga TCP-baserade metoden krävs fortfarande inledningsvis för att upprätta den här typen av anslutning.
RDP Multipath
RDP Multipath är en innovativ anslutningsförbättring för Windows 365 som förbättrar sessionstillförlitligheten och prestandan genom intelligent hantering av flera nätverksvägar. Den bygger på RDP Shortpath och använder Interactive Connectivity Establishment (ICE) för att identifiera och utvärdera flera UDP-vägar i realtid, inklusive de som använder STUN- och TURN-protokoll.
Den här funktionen säkerställer att om den aktiva sökvägen blir instabil eller misslyckas växlar systemet automatiskt till en säkerhetskopieringssökväg utan att avbryta användarsessionen. Multipath-routning är särskilt fördelaktigt i miljöer med varierande nätverksförhållanden, vilket ger en smidigare och mer motståndskraftig fjärrskrivbordsupplevelse.
Fullständig information finns i RDP Multipath-dokumentationen.
Sammanfattning av RDP-anslutningsmetod
Följande tabell är en sammanfattning av de RDP-metoder som är tillgängliga för säker anslutning till din molndator.
Kontrollera att du kontrollerar om det finns fullständiga anslutningskrav på sidan Nätverkskrav .
| RDP-metod | Protokoll/port | FQDN | IP | Offentlig/privat nätverksmetod | Kommentar |
|---|---|---|---|---|---|
| TCP RDP (omvänd anslutning) | TCP/443 | *.wvd.microsoft.com | 40.64.144.0/20 omfattar RDP-anslutningselementet i den här domänen, men inte allt som matchar den | Offentlig | TCP-baserad RDP som vidarebefordras via Microsofts globala RDP-gatewayinfrastruktur – Inledande anslutningsmetod som används i samtliga fall. |
| Indirekt UDP RDP (RDP via TURN) | UDP/3478 | Saknas | 51.5.0.0/16 | Offentlig | UDP-baserad RDP vidarebefordras via Microsofts globala TURN-infrastruktur. Fungerar i alla nätverksscenarion om nödvändiga slutpunkter är tillgängliga. |
| Dirigera RDP med STUN | UDP/1024-65535 (standard 49152-65535) | Saknas | 51.5.0.0/16 för STUN-element. Offentlig IP-adress för NAT som används på vardera sidan av anslutningen | Offentlig | Inte möjligt i alla nätverksscenarier. Kräver öppen åtkomst till alla offentliga IP-adresser om NAT IP inte är känt i förväg. |
| RDP Shortpath för hanterade nätverk | UDP/3390 (kan konfigureras) | Saknas | Privata IP-adresser för fysisk klient och molndator | Privat | Kräver direkt siktlinje mellan fysisk enhet och Cloud PC. Endast möjligt med ANC-distributioner. |
| RDP Shortpath för hanterade nätverk med ICE/STUN | UDP/1024-65535 (standard 49152-65535) | Saknas | 51.5.0.0/16 för STUN och sedan privat IP för fysisk enhet och Cloud PC | Privat | Kräver åtkomst till STUN-serverintervallet och även direkt siktlinje mellan fysisk enhet och Cloud PC. Endast möjligt med ANC-distributioner |
Viktigt
IP-undernätet 40.64.144.0/20 används endast för den TCP-baserade RDP-anslutningen. Domain.wvd.microsoft.com innehåller även trafik som inte matchar det här undernätet. Därför använder du IP-intervallet för regler för förbikoppling och optimering. Kontrollera samtidigt att *.wvd.microsoft.com fortsätter att använda en sökväg som inte är beroende av IP-matchning, till exempel en proxy, så att all nödvändig trafik kan nå tjänsten.
Identifiera vilken RDP-transport som används.
Mer information om hur du identifierar vilken transportmetod som används för en viss anslutning finns i artikeln "Kontrollera att RDP Shortpath fungerar"