Krótka ścieżka protokołu RDP dla usługi Azure Virtual Desktop

Ukończone

Protokół RDP Shortpath ustanawia bezpośredni transport oparty na protokole UDP między aplikacją systemu Windows urządzenia lokalnego lub aplikacją pulpitu zdalnego na obsługiwanych platformach i hoście sesji w usłudze Azure Virtual Desktop.

Domyślnie protokół RDP (Remote Desktop Protocol) próbuje ustanowić sesję zdalną przy użyciu protokołu UDP i używa transportu odwrotnego połączenia opartego na protokole TCP jako mechanizmu połączenia rezerwowego. Transport oparty na protokole UDP zapewnia lepszą niezawodność połączeń i bardziej spójne opóźnienie. Transport połączeń odwrotnych oparty na protokole TCP zapewnia najlepszą zgodność z różnymi konfiguracjami sieci i ma wysoki współczynnik powodzenia podczas nawiązywania połączeń RDP.

Ścieżkę RDP można używać na dwa sposoby:

• Sieci zarządzane, w których jest ustanawiana bezpośrednia łączność między klientem a hostem sesji podczas korzystania z połączenia prywatnego, takiego jak wirtualna sieć prywatna (VPN). Połączenie korzystające z sieci zarządzanej jest ustanawiane w jeden z następujących sposobów:

  • Bezpośrednie połączenie UDP między urządzeniem klienckim i hostem sesji, w którym należy włączyć odbiornik RDP Shortpath i zezwolić na port przychodzący na każdym hoście sesji akceptowanie połączeń.
  • Bezpośrednie połączenie UDP między urządzeniem klienckim a hostem sesji przy użyciu protokołu Simple Traversal Underneath NAT (STUN) między klientem a hostem sesji. Porty przychodzące na hoście sesji nie muszą być dozwolone.

• Sieci publiczne, w których jest ustanawiana bezpośrednia łączność między klientem a hostem sesji podczas korzystania z połączenia publicznego. Istnieją dwa typy połączeń podczas korzystania z połączenia publicznego, które są wymienione tutaj w kolejności preferencji:

  • Bezpośrednie połączenie UDP przy użyciu protokołu Simple Traversal Underneath NAT (STUN) między klientem a hostem sesji.
  • Pośrednie połączenie UDP przy użyciu protokołu Traversal using Relay NAT (TURN) z przekaźnikiem między hostem klienta i sesji. Jest to wersja zapoznawcza.

Transport używany do protokołu RDP Shortpath jest oparty na uniwersalnym protokole KONTROLI szybkości (URCP). Platforma URCP rozszerza protokół UDP z aktywnym monitorowaniem warunków sieciowych i zapewnia sprawiedliwe i pełne wykorzystanie linków. Procesor URCP działa z niskim opóźnieniem i poziomami strat zgodnie z potrzebami.

• W wersji zapoznawczej funkcja TURN jest dostępna tylko dla połączeń z hostami sesji w puli hostów weryfikacji. Aby skonfigurować pulę hostów jako środowisko weryfikacji, zobacz Definiowanie puli hostów jako środowiska weryfikacji.
• Funkcja RDP Shortpath dla sieci publicznych z funkcją TURN jest dostępna tylko w chmurze publicznej platformy Azure.

Główne korzyści

Korzystanie z protokołu RDP Shortpath ma następujące kluczowe korzyści:

• Użycie narzędzia URCP w celu ulepszenia protokołu UDP zapewnia najlepszą wydajność dzięki dynamicznemu uczeniu parametrów sieciowych i zapewnieniu protokołu z mechanizmem kontroli szybkości.

• Usunięcie dodatkowych punktów przekazywania skraca czas rundy, co zwiększa niezawodność połączenia i środowisko użytkownika przy użyciu aplikacji wrażliwych na opóźnienia i metod wejściowych.

• Ponadto w przypadku sieci zarządzanych:

  • Protokół RDP Shortpath zapewnia obsługę konfigurowania priorytetu jakości usług (QoS) dla połączeń RDP za pomocą różnicowych znaków punktu kodu usług (DSCP).
  • Transport RDP Shortpath umożliwia ograniczenie ruchu sieciowego wychodzącego przez określenie szybkości ograniczania dla każdej sesji.

Jak działa protokół RDP Shortpath dla sieci zarządzanych

Możesz osiągnąć bezpośrednią łączność wzrokową wymaganą do korzystania z protokołu RDP Shortpath z sieciami zarządzanymi przy użyciu następujących metod.

• Prywatna komunikacja równorzędna usługi ExpressRoute
• Sieć VPN typu lokacja-lokacja lub sieć VPN typu punkt-lokacja (IPsec), taka jak usługa Azure VPN Gateway

Bezpośrednia łączność wzrokowa oznacza, że klient może łączyć się bezpośrednio z hostem sesji bez blokowania przez zapory.

Uwaga

Jeśli używasz innych typów sieci VPN do nawiązywania połączenia z platformą Azure, zalecamy użycie sieci VPN opartej na protokole UDP. Podczas gdy większość rozwiązań sieci VPN opartych na protokole TCP obsługuje zagnieżdżonych protokołu UDP, dodają dziedziczone obciążenie związane z kontrolą przeciążenia TCP, co spowalnia wydajność protokołu RDP.

Aby użyć protokołu RDP Shortpath dla sieci zarządzanych, należy włączyć odbiornik UDP na hostach sesji. Domyślnie używany jest port 3390 , chociaż można użyć innego portu.

Diagram zawiera ogólne omówienie połączeń sieciowych podczas korzystania z protokołu RDP Shortpath dla sieci zarządzanych i hostów sesji dołączonych do domeny usługi Active Directory.

Sekwencja połączeń

Wszystkie połączenia zaczynają się od ustanowienia transportu odwrotnego połączenia opartego na protokole TCP za pośrednictwem bramy usługi Azure Virtual Desktop Gateway. Następnie host klienta i sesji ustanowi początkowy transport RDP i rozpocznij wymianę swoich możliwości. Te możliwości są negocjowane przy użyciu następującego procesu:

1. Host sesji wysyła listę adresów IPv4 i IPv6 do klienta.
2. Klient uruchamia wątek w tle, aby ustanowić równoległy transport oparty na protokole UDP bezpośrednio do jednego z adresów IP hosta sesji.
3. Podczas sondowania podanych adresów IP klient kontynuuje nawiązywanie początkowego połączenia za pośrednictwem transportu odwrotnego połączenia, aby upewnić się, że połączenie użytkownika nie jest opóźnione.
4. Jeśli klient ma bezpośrednie połączenie z hostem sesji, klient ustanawia bezpieczne połączenie przy użyciu protokołu TLS za pośrednictwem niezawodnego protokołu UDP.
5. Po ustanowieniu transportu RDP Shortpath wszystkie dynamiczne kanały wirtualne (DVC), w tym zdalna grafika, dane wejściowe i przekierowywanie urządzeń, są przenoszone do nowego transportu. Jeśli jednak zapora lub topologia sieci uniemożliwia klientowi nawiązanie bezpośredniej łączności UDP, protokół RDP będzie nadal używać transportu odwrotnego połączenia.

Jeśli użytkownicy mają dostęp do sieci zarządzanej za pomocą protokołu RDP Shortpath i sieci publiczne, zostanie użyty pierwszy algorytm. Użytkownik będzie używać niezależnie od tego, które połączenie zostanie ustanowione jako pierwsze dla tej sesji.

Jak działa protokół RDP Shortpath dla sieci publicznych

Aby zapewnić największe prawdopodobieństwo pomyślnego nawiązania połączenia UDP podczas korzystania z połączenia publicznego, istnieją typy połączeń bezpośrednich i pośrednich :

• Bezpośrednie połączenie: STUN służy do ustanawiania bezpośredniego połączenia UDP między klientem a hostem sesji. Aby ustanowić to połączenie, host klienta i sesji musi mieć możliwość łączenia się ze sobą za pośrednictwem publicznego adresu IP i wynegocjowanego portu. Jednak większość klientów nie zna własnego publicznego adresu IP, ponieważ znajduje się za urządzeniem bramy translatora adresów sieciowych (NAT ). STUN to protokół do samodzielnego odnajdywania publicznego adresu IP zza urządzenia bramy translatora adresów sieciowych i klienta w celu określenia własnego publicznego adresu IP.

  Aby klient używał STUN, jego sieć musi zezwalać na ruch UDP. Zakładając, że zarówno klient, jak i host sesji mogą kierować się bezpośrednio do odnalezionego adresu IP i portu innego, komunikacja jest ustanawiana za pomocą bezpośredniego protokołu UDP za pośrednictwem protokołu WebSocket. Jeśli zapory lub inne urządzenia sieciowe blokują połączenia bezpośrednie, zostanie wypróbowane pośrednie połączenie UDP.

• Połączenie pośrednie: funkcja TURN służy do nawiązywania połączenia pośredniego, przekazywania ruchu przez serwer pośredni między klientem a hostem sesji, gdy bezpośrednie połączenie nie jest możliwe. TURN to rozszerzenie funkcji STUN. Użycie funkcji TURN oznacza, że publiczny adres IP i port są znane z wyprzedzeniem, co może być dozwolone za pośrednictwem zapór i innych urządzeń sieciowych.

  Funkcja TURN zwykle autoryzuje dostęp do serwera za pośrednictwem nazwy użytkownika/hasła, a preferowanym trybem operacji jest użycie gniazd UDP. Jeśli zapory lub inne urządzenia sieciowe blokują ruch UDP, połączenie powróci do transportu odwrotnego połączenia TCP.

Po nawiązaniu połączenia interakcyjny establishment łączności (ICE) koordynuje zarządzanie usługami STUN i TURN w celu zoptymalizowania prawdopodobieństwa nawiązania połączenia i zapewnienia, że pierwszeństwo ma preferowane protokoły komunikacyjne sieci.

Każda sesja protokołu RDP domyślnie używa dynamicznie przypisanego portu UDP z zakresu portów efemerycznych (49152 do 65535 ), który domyślnie akceptuje ruch RDP Shortpath. Port 65330 jest ignorowany z tego zakresu, ponieważ jest zarezerwowany do użytku wewnętrznego przez platformę Azure. Można również użyć mniejszego, przewidywalnego zakresu portów. Aby uzyskać więcej informacji, zobacz Ograniczanie zakresu portów używanych przez klientów dla sieci publicznych.

Diagram zawiera ogólne omówienie połączeń sieciowych podczas korzystania z protokołu RDP Shortpath dla sieci publicznych, w których hosty sesji przyłączone do identyfikatora Microsoft Entra.

Translacja adresów sieciowych i zapory

Większość klientów usługi Azure Virtual Desktop działa na komputerach w sieci prywatnej. Dostęp do Internetu jest udostępniany za pośrednictwem urządzenia bramy translatora adresów sieciowych (NAT). W związku z tym brama translatora adresów sieciowych modyfikuje wszystkie żądania sieciowe z sieci prywatnej i kierowane do Internetu. Taka modyfikacja ma na celu udostępnienie jednego publicznego adresu IP na wszystkich komputerach w sieci prywatnej.

Ze względu na modyfikację pakietu IP odbiorca ruchu zobaczy publiczny adres IP bramy translatora adresów sieciowych zamiast rzeczywistego nadawcy. Gdy ruch wraca do bramy translatora adresów sieciowych, zajmie się przekazywaniem go do zamierzonego adresata bez wiedzy nadawcy. W większości scenariuszy urządzenia ukryte za takim translatorem adresów sieciowych nie wiedzą, że odbywa się tłumaczenie i nie zna adresu sieciowego bramy translatora adresów sieciowych.

Translator adresów sieciowych ma zastosowanie do sieci wirtualnych platformy Azure, w których znajdują się wszystkie hosty sesji. Gdy host sesji próbuje uzyskać dostęp do adresu sieciowego w Internecie, brama translatora adresów sieciowych (własna lub domyślna podana przez platformę Azure) lub usługa Azure Load Balancer wykonuje tłumaczenie adresu.

Większość sieci zazwyczaj obejmuje zapory, które sprawdzają ruch i blokują je na podstawie reguł. Większość klientów konfiguruje zapory, aby uniemożliwić połączenia przychodzące (czyli niezamowione pakiety z Internetu wysyłane bez żądania). Zapory stosują różne techniki śledzenia przepływu danych w celu rozróżnienia między niechcianym i niechcianym ruchem. W kontekście protokołu TCP zapora śledzi pakiety SYN i ACK, a proces jest prosty. Zapory UDP zwykle używają heurystyki na podstawie adresów pakietów, aby skojarzyć ruch z przepływami UDP i zezwalać na nie lub blokować.

Sekwencja połączeń

Wszystkie połączenia zaczynają się od ustanowienia transportu odwrotnego połączenia opartego na protokole TCP za pośrednictwem bramy usługi Azure Virtual Desktop Gateway. Następnie host klienta i sesji ustanowi początkowy transport RDP i rozpocznij wymianę swoich możliwości. Jeśli protokół RDP Shortpath dla sieci publicznych jest włączony na hoście sesji, host sesji inicjuje proces nazywany zbieraniem kandydatów:

1. Host sesji wylicza wszystkie interfejsy sieciowe przypisane do hosta sesji, w tym interfejsy wirtualne, takie jak VPN i Teredo.
2. Usługi pulpitu zdalnego systemu Windows (TermService) przydziela gniazda UDP na każdym interfejsie i przechowuje parę IP:Port w tabeli kandydata jako kandydata lokalnego.
3. Usługa usług pulpitu zdalnego używa każdego gniazda UDP przydzielonego w poprzednim kroku, aby spróbować dotrzeć do serwera STUN usługi Azure Virtual Desktop w publicznym Internecie. Komunikacja odbywa się przez wysłanie małego pakietu UDP do portu 3478.
4. Jeśli pakiet osiągnie serwer STUN, serwer STUN odpowiada za pomocą publicznego adresu IP i portu. Te informacje są przechowywane w tabeli kandydatów jako kandydat refleksyjny.
5. Po zebraniu wszystkich kandydatów host sesji używa ustanowionego transportu odwrotnego połączenia, aby przekazać listę kandydatów do klienta.
6. Gdy klient otrzyma listę kandydatów z hosta sesji, klient wykonuje również zbieranie kandydatów po jego stronie. Następnie klient wysyła listę kandydatów do hosta sesji.
7. Po wymienieniu listy kandydatów przez hosta sesji i klienta obie strony próbują połączyć się ze sobą przy użyciu wszystkich zebranych kandydatów. Ta próba połączenia jest równoczesna po obu stronach. Wiele bram translatora adresów sieciowych jest skonfigurowanych tak, aby zezwalać na ruch przychodzący do gniazda zaraz po zainicjowaniu transferu danych wychodzących. Takie zachowanie bram translatora adresów sieciowych jest powodem, dla którego jednoczesne połączenie jest niezbędne. Jeśli funkcja STUN nie powiedzie się, ponieważ zostanie ona zablokowana, zostanie podjęta próba połączenia pośredniego przy użyciu funkcji TURN.
8. Po początkowej wymiany pakietów host klienta i sesji może ustanowić jeden lub wiele przepływów danych. Z tych przepływów danych protokół RDP wybiera najszybszą ścieżkę sieci. Następnie klient ustanawia bezpieczne połączenie przy użyciu protokołu TLS za pośrednictwem niezawodnego protokołu UDP z hostem sesji i inicjuje transport shortpath protokołu RDP.
9. Po ustanowieniu transportu za pomocą protokołu RDP Shortpath wszystkie dynamiczne kanały wirtualne (DVC), w tym zdalna grafika, dane wejściowe i przekierowywanie urządzeń są przenoszone do nowego transportu.