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

Protokół RDP Shortpath ustanawia 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) rozpoczyna transport odwrotnego połączenia opartego na protokole TCP, a następnie próbuje ustanowić sesję zdalną przy użyciu protokołu UDP. Jeśli połączenie UDP zakończy się powodzeniem, połączenie TCP spadnie, w przeciwnym razie połączenie TCP jest używane jako mechanizm 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:

1. 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 usługa Azure ExpressRoute lub wirtualna sieć prywatna (VPN) typu lokacja-lokacja. Połączenie korzystające z sieci zarządzanej jest ustanawiane w jeden z następujących sposobów:

   1. 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ń.

   2. 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.

2. 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:

   1. Bezpośrednie połączenie UDP przy użyciu protokołu Simple Traversal Underneath NAT (STUN) między klientem a hostem sesji.

   2. Przekaźnikowe połączenie UDP przy użyciu protokołu Traversal using Relay NAT (TURN) między klientem a hostem sesji.

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.

Ważne

• Krótka ścieżka protokołu RDP dla sieci publicznych za pośrednictwem usługi STUN dla usługi Azure Virtual Desktop jest dostępna w chmurze publicznej platformy Azure i w chmurze Azure Government.
• Krótka ścieżka protokołu RDP dla sieci publicznych za pośrednictwem funkcji TURN dla usługi Azure Virtual Desktop 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.

• Większa przepływność.

• W przypadku korzystania z funkcji STUN usunięcie dodatkowych punktów przekaźnika skraca czas rundy, co zwiększa niezawodność połączenia oraz środowisko użytkownika z aplikacjami wrażliwymi na opóźnienia i metodami wejściowymi.

• 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

Aby dowiedzieć się, jak działa protokół RDP Shortpath dla sieci zarządzanych i sieci publicznych, wybierz każdą z poniższych kart.

Sieci zarządzane

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.

Na poniższym diagramie przedstawiono ogólne omówienie połączeń sieciowych w przypadku 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.

Sieci publiczne

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 przekazywanych :

• 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ą bezpośrednie połączenia, zostanie wypróbowane przekazane połączenie UDP.

• Połączenie przekazywane: funkcja TURN służy do nawiązywania połączenia, 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.

  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.

Napiwek

Krótka ścieżka protokołu RDP dla sieci publicznych będzie działać automatycznie bez dodatkowej konfiguracji, zapewniając sieci i zapory zezwalają na ruch przez i ustawienia transportu RDP w systemie operacyjnym Windows dla hostów sesji i klientów używają ich wartości domyślnych.

Na poniższym diagramie przedstawiono 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 Entra firmy Microsoft.

Dostępność przekaźnika TURN

Przekaźnik TURN jest dostępny w następujących regionach świadczenia usługi Azure:

• Australia Południowo-Wschodnia
• Indie Środkowe
• East US
• Wschodnie stany USA 2
• Francja Środkowa
• Japonia Zachodnia
• Europa Północna

• South Central US
• Southeast Asia
• Południowe Zjednoczone Królestwo
• Zachodnie Zjednoczone Królestwo
• West Europe
• Zachodnie stany USA
• Zachodnie stany USA 2

Przekaźnik TURN jest wybierany na podstawie fizycznej lokalizacji urządzenia klienckiego. Jeśli na przykład urządzenie klienckie znajduje się w Wielkiej Brytanii, wybrano przekaźnik TURN w regionie Południowo-Zachodnim Wielkiej Brytanii lub Wielkiej Brytanii. Jeśli urządzenie klienckie jest dalekie od przekaźnika TURN, połączenie UDP może wrócić do protokołu TCP.

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. Aby uzyskać więcej informacji na temat różnych typów translacji adresów sieciowych źródła, zobacz Używanie źródłowego tłumaczenia adresów sieciowych (SNAT) dla połączeń wychodzących.

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ć. Dostępnych jest wiele różnych implementacji translatora adresów sieciowych.

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 z przekaźnikiem 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.

Jeśli użytkownicy mają zarówno protokół RDP Shortpath dla sieci zarządzanej, jak i sieci publiczne dostępne dla nich, zostanie użyty pierwszy znaleziony algorytm, co oznacza, że użytkownik będzie używać niezależnie od tego, które połączenie zostanie ustanowione jako pierwsze dla tej sesji. Aby uzyskać więcej informacji, zobacz przykładowy scenariusz 4.

Konfiguracja sieci

Aby obsługiwać protokół RDP Shortpath dla sieci publicznych, zazwyczaj nie potrzebujesz żadnej konkretnej konfiguracji. Host sesji i klient automatycznie odnajdą bezpośredni przepływ danych, jeśli jest to możliwe w konfiguracji sieci. Jednak każde środowisko jest unikatowe, a niektóre konfiguracje sieci mogą negatywnie wpłynąć na szybkość powodzenia bezpośredniego połączenia. Postępuj zgodnie z zaleceniami , aby zwiększyć prawdopodobieństwo bezpośredniego przepływu danych.

Ponieważ protokół RDP Shortpath używa protokołu UDP do ustanowienia przepływu danych, jeśli zapora w sieci blokuje ruch UDP, shortpath protokołu RDP zakończy się niepowodzeniem, a połączenie powróci do transportu odwrotnego połączenia opartego na protokole TCP. Usługa Azure Virtual Desktop używa serwerów STUN udostępnianych przez usługi Azure Communication Services i microsoft Teams. Ze względu na charakter funkcji wymagana jest łączność wychodząca z hostów sesji do klienta. Niestety nie można przewidzieć, gdzie znajdują się użytkownicy w większości przypadków. W związku z tym zalecamy umożliwienie wychodzącej łączności UDP z hostów sesji do Internetu. Aby zmniejszyć liczbę wymaganych portów, można ograniczyć zakres portów używany przez klientów dla przepływu UDP. Skorzystaj z poniższych tabel, aby uzyskać informacje referencyjne podczas konfigurowania zapór dla protokołu RDP Shortpath.

Jeśli środowisko używa symetrycznego translatora adresów sieciowych, które jest mapowaniem pojedynczego źródła prywatnego IP:Port do unikatowego publicznego docelowego adresu IP:Port, możesz użyć połączenia przekazywanego z funkcją TURN. Tak będzie w przypadku korzystania z usług Azure Firewall i Azure NAT Gateway. Aby uzyskać więcej informacji na temat translatora adresów sieciowych w sieciach wirtualnych platformy Azure, zobacz Source Network Address Translation with virtual networks (Translacja adresów sieciowych źródła za pomocą sieci wirtualnych).

Mamy kilka ogólnych zaleceń dotyczących pomyślnych połączeń przy użyciu protokołu RDP Shortpath dla sieci publicznych. Aby uzyskać więcej informacji, zobacz Ogólne zalecenia.

Jeśli użytkownicy mają dostęp do protokołu RDP Shortpath zarówno dla sieci zarządzanej, jak i sieci publicznych, zostanie użyty pierwszy znaleziony algorytm. Użytkownik będzie używać niezależnie od tego, które połączenie zostanie ustanowione jako pierwsze dla tej sesji. Aby uzyskać więcej informacji, zobacz Przykładowe scenariusze.

Poniższe sekcje zawierają wymagania dotyczące źródła, miejsca docelowego i protokołu dla hostów sesji i urządzeń klienckich, które muszą być dozwolone, aby program RDP Shortpath działał.

Uwaga

W przypadku przekaźnika połączenia z usługą TURN podsieć 20.202.0.0/16 IP jest współużytkowana z usługami Azure Communication Services. Jednak usługi Azure Virtual Desktop i Windows 365 zostaną zastąpione 51.5.0.0/16usługą , która jest przeznaczona wyłącznie dla tych usług. Zalecamy skonfigurowanie obu zakresów w środowisku sieciowym teraz w celu zapewnienia bezproblemowego przejścia.

Jeśli chcesz poczekać na użycie dedykowanej podsieci, wykonaj kroki opisane w temacie Konfigurowanie ustawień sieci puli hostów i ustaw skrót protokołu RDP dla sieci publicznej (za pośrednictwem funkcji TURN/relay) na wartość Wyłączone. Alternatywnie można wyłączyć protokół UDP na urządzeniu lokalnym, ale spowoduje to wyłączenie protokołu UDP dla wszystkich połączeń. Aby wyłączyć protokół UDP na urządzeniu lokalnym, wykonaj kroki opisane w artykule Sprawdź, czy protokół UDP jest włączony na urządzeniach klienckich z systemem Windows, ale ustaw opcję Wyłącz klienta UDP na wartość Włączone. Jeśli zablokujesz zakres 20.202.0.0/16 adresów IP w sieci i używasz aplikacji sieci VPN, może to spowodować problemy z rozłączeniem.

Sieć wirtualna hosta sesji

W poniższej tabeli przedstawiono wymagania dotyczące źródła, miejsca docelowego i protokołu dla protokołu RDP Shortpath dla sieci wirtualnej hosta sesji.

Nazwisko	Lokalizacja źródłowa	Port źródłowy	Element docelowy	Port docelowy	Protokół	Akcja
Bezpośrednie połączenie STUN	Podsieć maszyny wirtualnej	Dowolne	Dowolne	1024-65535 (domyślnie 49152-65535)	UDP	Zezwalaj
Infrastruktura STUN/TURN	Podsieć maszyny wirtualnej	Dowolne	20.202.0.0/16	3478	UDP	Zezwalaj
Przekaźnik TURN	Podsieć maszyny wirtualnej	Dowolne	51.5.0.0/16	3478	UDP	Zezwalaj

Sieć kliencka

W poniższej tabeli przedstawiono wymagania dotyczące źródła, miejsca docelowego i protokołu dla urządzeń klienckich.

Nazwisko	Lokalizacja źródłowa	Port źródłowy	Element docelowy	Port docelowy	Protokół	Akcja
Bezpośrednie połączenie STUN	Sieć kliencka	Dowolne	Publiczne adresy IP przypisane do bramy translatora adresów sieciowych lub usługi Azure Firewall (udostępniane przez punkt końcowy STUN)	1024-65535 (domyślnie 49152-65535)	UDP	Zezwalaj
Infrastruktura STUN/przekaźnik TURN	Sieć kliencka	Dowolne	20.202.0.0/16	3478	UDP	Zezwalaj
Przekaźnik TURN	Sieć kliencka	Dowolne	51.5.0.0/16	3478	UDP	Zezwalaj

Obsługa platformy Teredo

Chociaż nie jest to wymagane w przypadku protokołu RDP Shortpath, Teredo dodaje dodatkowe kandydatów nat przechodzenia i zwiększa prawdopodobieństwo pomyślnego połączenia RDP Shortpath w sieciach tylko do protokołu IPv4. Aby dowiedzieć się, jak włączyć usługę Teredo na hostach i klientach sesji, zobacz Włączanie obsługi teredo.

Obsługa protokołu UPnP

Aby zwiększyć prawdopodobieństwo bezpośredniego połączenia, po stronie klienta pulpitu zdalnego protokół RDP Shortpath może użyć protokołu UPnP do skonfigurowania mapowania portów na routerze TRANSLATOR adresów sieciowych. UPnP to standardowa technologia używana przez różne aplikacje, takie jak Xbox, Optymalizacja dostarczania i Teredo. Protokół UPnP jest ogólnie dostępny na routerach zwykle w sieci domowej. Funkcja UPnP jest domyślnie włączona na większości routerów domowych i punktów dostępu, ale często jest wyłączona w sieci firmowej.

Zalecenia ogólne

Poniżej przedstawiono kilka ogólnych zaleceń dotyczących korzystania z protokołu RDP Shortpath dla sieci publicznych:

• Unikaj używania konfiguracji tunelowania wymuszonego, jeśli użytkownicy uzyskują dostęp do usługi Azure Virtual Desktop za pośrednictwem Internetu.

• Upewnij się, że nie używasz podwójnych konfiguracji translatora adresów sieciowych ani translatora adresów sieciowych (CGN, Carrier-Grade-NAT).

• Zalecamy użytkownikom, że nie wyłączają protokołu UPnP na routerach domowych.

• Unikaj korzystania z usług inspekcji pakietów w chmurze.

• Unikaj korzystania z rozwiązań sieci VPN opartych na protokole TCP.

• Włącz łączność IPv6 lub Teredo.

Zabezpieczenia połączeń

Protokół RDP Shortpath rozszerza możliwości transportu wielotransportowego RDP. Nie zastępuje transportu odwrotnego połączenia, ale uzupełnia go. Początkowa obsługa brokera sesji jest zarządzana za pośrednictwem usługi Azure Virtual Desktop i transportu odwrotnego połączenia. Wszystkie próby połączenia są ignorowane, chyba że są zgodne z pierwszą sesją połączenia odwrotnego. Krótka ścieżka protokołu RDP jest ustanawiana po uwierzytelnieniu, a jeśli zostanie pomyślnie nawiązana, transport odwrotnego połączenia zostanie porzucony i cały ruch przepływa przez ścieżkę krótką protokołu RDP.

Protokół RDP Shortpath używa bezpiecznego połączenia przy użyciu protokołu TLS za pośrednictwem niezawodnego protokołu UDP między klientem a hostem sesji przy użyciu certyfikatów hosta sesji. Domyślnie certyfikat używany do szyfrowania RDP jest generowany samodzielnie przez system operacyjny podczas wdrażania. Można również wdrożyć centralnie zarządzane certyfikaty wystawione przez urząd certyfikacji przedsiębiorstwa. Aby uzyskać więcej informacji na temat konfiguracji certyfikatów, zobacz Konfiguracje certyfikatów odbiornika pulpitu zdalnego.

Uwaga

Zabezpieczenia oferowane przez protokół RDP Shortpath są takie same jak w przypadku transportu odwrotnego połączenia TCP.

Przykładowe scenariusze

Poniżej przedstawiono przykładowe scenariusze pokazujące sposób oceniania połączeń w celu określenia, czy skrót protokołu RDP jest używany w różnych topologiach sieci.

Scenariusz 1

Połączenie UDP można ustanowić tylko między urządzeniem klienckim a hostem sesji za pośrednictwem sieci publicznej (Internet). Bezpośrednie połączenie, takie jak sieć VPN, nie jest dostępne. Protokół UDP jest dozwolony za pośrednictwem zapory lub urządzenia NAT.

Scenariusz 2

Zapora lub urządzenie NAT blokuje bezpośrednie połączenie UDP, ale przekazywane połączenie UDP można przekazać za pomocą funkcji TURN między urządzeniem klienckim a hostem sesji za pośrednictwem sieci publicznej (Internet). Inne bezpośrednie połączenie, takie jak sieć VPN, nie jest dostępne.

Scenariusz 3

Połączenie UDP można ustanowić między urządzeniem klienckim a hostem sesji za pośrednictwem sieci publicznej lub za pośrednictwem bezpośredniego połączenia sieci VPN, ale protokół RDP Shortpath dla sieci zarządzanych nie jest włączony. Gdy klient inicjuje połączenie, protokół ICE/STUN może zobaczyć wiele tras i oceni każdą trasę i wybierze tę z najniższym opóźnieniem.

W tym przykładzie połączenie UDP korzystające z protokołu RDP Shortpath dla sieci publicznych za pośrednictwem bezpośredniego połączenia sieci VPN zostanie wykonane, ponieważ ma najmniejsze opóźnienie, jak pokazano w zielonej linii.

Scenariusz 4

Włączono zarówno protokół RDP Shortpath dla sieci publicznych, jak i sieci zarządzanych. Połączenie UDP można ustanowić między urządzeniem klienckim a hostem sesji za pośrednictwem sieci publicznej lub za pośrednictwem bezpośredniego połączenia sieci VPN. Gdy klient inicjuje połączenie, istnieją jednoczesne próby nawiązania połączenia przy użyciu protokołu RDP Shortpath dla sieci zarządzanych za pośrednictwem portu 3390 (domyślnie) i protokołu RDP Shortpath dla sieci publicznych za pośrednictwem protokołu ICE/STUN. Zostanie użyty algorytm znaleziony jako pierwszy, a użytkownik użyje niezależnie od tego, które połączenie zostanie ustanowione jako pierwsze dla tej sesji.

Ponieważ przejście przez sieć publiczną ma więcej kroków, na przykład urządzenia NAT, modułu równoważenia obciążenia lub serwera STUN, prawdopodobnie pierwszy znaleziony algorytm wybierze połączenie przy użyciu protokołu RDP Shortpath dla sieci zarządzanych i zostanie ustanowiony jako pierwszy.

Scenariusz 5

Połączenie UDP można ustanowić między urządzeniem klienckim a hostem sesji za pośrednictwem sieci publicznej lub za pośrednictwem bezpośredniego połączenia sieci VPN, ale protokół RDP Shortpath dla sieci zarządzanych nie jest włączony. Aby zapobiec używaniu określonej trasy przez ICE/STUN, administrator może zablokować jedną z tras dla ruchu UDP. Zablokowanie trasy gwarantuje, że pozostała ścieżka jest zawsze używana.

W tym przykładzie protokół UDP jest blokowany w bezpośrednim połączeniu sieci VPN, a protokół ICE/STUN ustanawia połączenie za pośrednictwem sieci publicznej.

Scenariusz 6

Skonfigurowano zarówno protokół RDP Shortpath dla sieci publicznych, jak i sieci zarządzanych, jednak nie można ustanowić połączenia UDP przy użyciu bezpośredniego połączenia sieci VPN. Zapora lub urządzenie NAT blokuje również bezpośrednie połączenie UDP przy użyciu sieci publicznej (Internet), ale przekazywane połączenie UDP może być przekazywane przy użyciu funkcji TURN między urządzeniem klienckim a hostem sesji za pośrednictwem sieci publicznej (Internet).

Scenariusz 7

Skonfigurowano zarówno protokół RDP Shortpath dla sieci publicznych, jak i sieci zarządzanych, jednak nie można ustanowić połączenia UDP. W tym przypadku shortpath protokołu RDP zakończy się niepowodzeniem, a połączenie powróci do transportu odwrotnego połączenia opartego na protokole TCP.

Następne kroki

• Dowiedz się, jak skonfigurować krótką ścieżkę protokołu RDP.
• Dowiedz się więcej o łączności sieciowej usługi Azure Virtual Desktop, zobacz Understanding Azure Virtual Desktop network connectivity (Informacje o łączności sieciowej usługi Azure Virtual Desktop).
• Informacje o opłatach za sieć ruchu wychodzącego platformy Azure.
• Aby dowiedzieć się, jak oszacować przepustowość używaną przez protokół RDP, zobacz Wymagania dotyczące przepustowości protokołu RDP.