Krótka ścieżka protokołu RDP dla usługi Azure Virtual Desktop
Artykuł
Ważne
Używanie protokołu RDP Shortpath dla sieci publicznych z funkcją TURN dla usługi Azure Virtual Desktop jest obecnie w wersji zapoznawczej. Zobacz Dodatkowe warunki użytkowania wersji zapoznawczych platformy Microsoft Azure, aby zapoznać się z postanowieniami prawnymi dotyczącymi funkcji platformy Azure, które są w wersji beta lub wersji zapoznawczej albo w inny sposób nie zostały jeszcze wydane jako ogólnie dostępne.
Połączenie iony do usługi Azure Virtual Desktop używają protokołu TCP (Transmission Control Protocol) lub protokołu UDP (User Datagram Protocol). RDP Shortpath to funkcja usługi Azure Virtual Desktop, która ustanawia bezpośredni transport oparty na protokole UDP między obsługiwanym klientem pulpitu zdalnego systemu Windows i hostem sesji. Domyślnie protokół RDP (Remote Desktop Protocol) próbuje nawiązać połączenie przy użyciu protokołu UDP i używa transportu odwrotnego połączenia opartego na protokole TCP jako mechanizmu połączenia rezerwowego. 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. Transport oparty na protokole UDP zapewnia lepszą niezawodność połączeń i bardziej spójne opóźnienie.
Ś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).
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.
Ważne
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
Aby dowiedzieć się, jak działa protokół RDP Shortpath dla sieci zarządzanych i sieci publicznych, wybierz każdą z poniższych kart.
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.
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łączenie ion
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:
Host sesji wysyła listę adresów IPv4 i IPv6 do klienta.
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.
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.
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.
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.
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 interaktywne Połączenie ivity Establishment (ICE) koordynuje zarządzanie 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.
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. W większości przypadków brama translatora adresów sieciowych i zapora to funkcje tego samego urządzenia fizycznego lub wirtualnego.
Sekwencja Połączenie ion
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:
Host sesji wylicza wszystkie interfejsy sieciowe przypisane do hosta sesji, w tym interfejsy wirtualne, takie jak VPN i Teredo.
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.
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.
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.
Po zebraniu wszystkich kandydatów host sesji używa ustanowionego transportu odwrotnego połączenia, aby przekazać listę kandydatów do klienta.
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.
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.
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.
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.
Ważne
W przypadku korzystania z transportu opartego na protokole TCP ruch wychodzący z hosta sesji do klienta odbywa się za pośrednictwem bramy usługi Azure Virtual Desktop. W przypadku protokołu RDP Shortpath dla sieci publicznych korzystających z funkcji STUN ruch wychodzący jest ustanawiany bezpośrednio między hostem sesji a klientem przez Internet. Spowoduje to usunięcie przeskoku, który poprawia opóźnienie i środowisko użytkownika końcowego. Jednak ze względu na zmiany przepływu danych między hostem sesji a klientem, w którym brama nie jest już używana, będą naliczane standardowe opłaty za sieć wychodzącą platformy Azure dodatkowo naliczane za subskrypcję dla użytej przepustowości internetowej. Aby dowiedzieć się więcej na temat szacowania przepustowości używanej przez protokół RDP, zobacz Wymagania dotyczące przepustowości protokołu RDP.
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, czyli mapowania pojedynczego prywatnego źródła IP:Port na unikatowy publiczny docelowy adres IP:Port, możesz użyć połączenia pośredniego 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).
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.
Dostępność turn (wersja zapoznawcza)
Funkcja TURN jest dostępna 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
Sieć wirtualna hosta sesji
Nazwisko
Lokalizacja źródłowa
Port źródłowy
Element docelowy
Port docelowy
Protokół
Akcja
Punkt końcowy serwera RDP Shortpath
Podsieć maszyny wirtualnej
Dowolne
Dowolne
1024-65535 (domyślnie 49152-65535)
UDP
Zezwalaj
STUN/TURN UDP
Podsieć maszyny wirtualnej
Dowolne
20.202.0.0/16
3478
UDP
Zezwalaj
STUN/TURN TCP
Podsieć maszyny wirtualnej
Dowolne
20.202.0.0/16
443
TCP
Zezwalaj
Sieć kliencka
Nazwisko
Lokalizacja źródłowa
Port źródłowy
Element docelowy
Port docelowy
Protokół
Akcja
Punkt końcowy serwera RDP Shortpath
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
STUN/TURN UDP
Sieć kliencka
Dowolne
20.202.0.0/16
3478
UDP
Zezwalaj
STUN/TURN TCP
Sieć kliencka
Dowolne
20.202.0.0/16
443
TCP
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ć teredo na hostach sesji i klientach, zobacz Obsługa 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 pośrednie 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 pośrednie połączenie UDP może być przekazywane za pomocą 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.
