Krótka ścieżka RDP ustanawia transport oparty na protokole UDP między urządzeniem lokalnym, aplikacją aplikacja dla systemu Windows lub aplikacją pulpitu zdalnego na obsługiwanych platformach i hostem sesji w usłudze Azure Virtual Desktop. Domyślnie protokół RDP (Remote Desktop Protocol) inicjuje transport odwrotnego połączenia oparty na protokole TCP, a następnie próbuje ustanowić sesję zdalną przy użyciu protokołu UDP. Jeśli połączenie UDP zostanie pomyślnie nawiązane, połączenie TCP zostanie przerwane. W przeciwnym razie połączenie TCP będzie używane jako rezerwowy mechanizm połączenia.
Transport oparty na protokole UDP zapewnia lepszą niezawodność połączenia i bardziej spójne opóźnienia. Transport odwrotnego łączenia oparty na protokole TCP zapewnia najlepszą zgodność z różnymi konfiguracjami sieci i ma wysoki wskaźnik powodzenia przy ustanawianiu połączeń RDP.
Krótka ścieżka RDP może być używana na dwa sposoby:
Sieci zarządzane, w których bezpośrednia łączność jest ustanawiana między klientem i hostem sesji podczas korzystania z połączenia prywatnego, takiego jak usługa ExpressRoute platformy Azure lub wirtualna sieć prywatna (VPN) typu lokacja-lokacja. Połączenie za pomocą sieci zarządzanej jest ustanawiane na jeden z następujących sposobów:
Bezpośrednie połączenie UDP między urządzeniem klienckim a hostem sesji, w którym trzeba włączyć odbiornik krótkiej ścieżki RDP i zezwolić portowi przychodzącemu na każdym hoście sesji na akceptowanie połączeń.
Bezpośrednie połączenie UDP między urządzeniem klienckim a hostem sesji przy użyciu protokołu STUN (Simple Traversal Underneath Translator International) między klientem a hostem sesji. Porty przychodzące na hoście sesji nie muszą być dozwolone.
Sieci publiczne, w których podczas korzystania z połączenia publicznego ustanawiana jest bezpośrednia łączność między klientem a hostem sesji. W przypadku korzystania z połączenia publicznego istnieją dwa typy połączeń, wymienione poniżej w kolejności preferencji:
Bezpośrednie połączenie UDP między klientem a hostem sesji przy użyciu protokołu STUN (Simple Traversal Underneath NAT).
Połączenie przekazywane UDP między klientem a hostem sesji przy użyciu protokołu TURN (Traversal Using Relay NAT).
Transport używany dla krótkiej ścieżki RDP jest oparty na protokole URCP (Universal Rate Control Protocol). URCP zwiększa UDP dzięki aktywnemu monitorowaniu warunków sieciowych i zapewnia uczciwe i pełne wykorzystanie łącza. URCP działa z niskimi opóźnieniami i stratami w zależności od potrzeb.
Ważna
-
Chmura platformy Azure: Krótka ścieżka RDP RDP dla sieci publicznych za pośrednictwem STUN i TURN jest ogólnie dostępna.
-
Chmura platformy Azure dla administracji publicznej: Krótka ścieżka RDP za pośrednictwem STUN i TURN jest dostępna w publicznej wersji zapoznawczej z **dedykowanymi serwerami o zakresie adresów IP **20.140.236.0/22. Klienci mogą wypróbować tę funkcję dla hosta sesji w pierścieniu weryfikacji.
Kluczowe korzyści
Korzystanie z krótkiej ścieżki RDP ma następujące zalety:
Wykorzystanie URCP do zwiększenia UDP pozwala osiągnąć najlepszą wydajność poprzez dynamiczne uczenie się parametrów sieci i zapewnienie protokołowi mechanizmu kontroli szybkości.
Większa przepływność.
Podczas korzystania ze STUN usunięcie dodatkowych punktów przekaźnikowych skraca czas rundy poprawia niezawodność połączenia i komfort użytkowania aplikacji wrażliwych na opóźnienia i metod wprowadzania.
Ponadto w przypadku sieci zarządzanych:
Krótka ścieżka RDP umożliwia konfigurowanie priorytetu usługi Quality of Service (QoS) dla połączeń RDP za pomocą znaczników DSCP (Differentiated Services Code Point).
Krótka ścieżka RDP umożliwia ograniczanie wychodzącego ruchu sieciowego przez określenie szybkości ograniczania dla każdej sesji.
Jak działa Krótka ścieżka RDP
Aby dowiedzieć się, jak działa Krótka ścieżka RDP w przypadku sieci zarządzanych i publicznych, wybierz każdą z następujących kart.
Korzystając z następujących metod, można uzyskać bezpośrednią łączność w zasięgu wzroku wymaganą do korzystania z krótkiej ścieżki RDP w sieciach zarządzanych.
Bezpośrednia łączność w zasięgu wzroku oznacza, że klient może łączyć się bezpośrednio z hostem sesji bez blokowania przez zapory.
Uwaga
Jeśli korzystasz z innych typów sieci VPN do łączenia się z platformą Azure, zalecamy korzystanie z sieci VPN opartej na protokole UDP. Większość rozwiązań VPN opartych na protokole TCP obsługuje zagnieżdżony protokół UDP, ale dodają one dziedziczony narzut związany z kontrolą przeciążenia TCP, co spowalnia wydajność protokołu RDP.
Aby używać krótkiej ścieżki RDP dla sieci zarządzanych, należy włączyć odbiornik UDP na hostach sesji. Domyślnie jest używany port 3390 , chociaż możesz użyć innego portu.
Poniższy diagram zawiera ogólne omówienie połączeń sieciowych w przypadku używania krótkiej ścieżki RDP dla zarządzanych sieci i hostów sesji przyłączonych do domeny Active Directory.
Sekwencja połączeń
Wszystkie połączenia rozpoczynają się od ustanowienia transportu odwrotnego połączenia opartego na protokole TCP za pośrednictwem bramy usługi Azure Virtual Desktop Gateway. Następnie klient i host sesji ustanawiają początkowy transport RDP i rozpoczynają wymianę swoich możliwości. Te możliwości są negocjowane przy użyciu następującego procesu:
Host sesji wysyła do klienta listę swoich adresów IPv4 i IPv6.
Klient uruchamia wątek w tle w celu ustanowienia równoległego transportu opartego na protokole UDP bezpośrednio do jednego z adresów IP hosta sesji.
Podczas gdy klient sonduje podane adresy IP, kontynuuje nawiązywanie połączenia początkowego za pośrednictwem transportu odwrotnego, aby upewnić się, że nie wystąpią opóźnienia w nawiązaniu połączenia użytkownika.
Jeśli klient ma bezpośrednie połączenie z hostem sesji, ustanawia bezpieczne połączenie przy użyciu protokołu TLS za pośrednictwem niezawodnego protokołu UDP.
Po ustanowieniu transportu krótkiej ścieżki RDP wszystkie dynamiczne kanały wirtualne (DVC), w tym zdalna grafika, dane wejściowe i przekierowanie 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 kontynuuje transport odwrotny.
Jeśli użytkownicy mają dostęp zarówno do krótkiej ścieżki RDP dla sieci zarządzanej, jak i do sieci publicznych, zostanie użyty algorytm, który został znaleziony jako pierwszy. Użytkownik użyje połączenia, które zostanie ustanowione jako pierwsze dla danej sesji.
Aby zapewnić największe szanse powodzenia połączenia UDP podczas korzystania z połączenia publicznego, istnieją połączenia bezpośrednie i przekazywane :
Połączenie bezpośrednie: STUN służy do nawiązywania bezpośredniego połączenia UDP między klientem a hostem sesji. Aby ustanowić to połączenie, klient i host sesji muszą mieć możliwość łączenia się ze sobą za pośrednictwem publicznego adresu IP i wynegocjowanego portu. Jednak większość klientów nie zna swojego publicznego adresu IP, ponieważ pracują za urządzeniem bramy translatora adresów sieciowych (NAT). STUN jest protokołem służącym do samodzielnego wykrywania publicznego adresu IP zza urządzenia bramy translatora adresów sieciowych i klienta w celu określenia własnego publicznego adresu IP.
Aby klient mógł używać STUN, jego sieć musi zezwalać na ruch UDP. Przy założeniu, że zarówno klient, jak i host sesji mogą bezpośrednio kierować ruch do odnalezionego adresu IP i portu drugiej strony, komunikacja jest nawiązywana 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, próbowane jest połączenie przekazywane UDP.
Połączenie przekazywane: TURN służy do nawiązywania połączenia, przekazując ruch przez serwer pośredni między klientem a hostem sesji, gdy bezpośrednie połączenie nie jest możliwe. TURN jest rozszerzeniem STUN. Użycie TURN oznacza, że publiczny adres IP i port są znane z góry, co może być dozwolone przez zapory sieciowe i inne urządzenia sieciowe.
Jeśli zapory lub inne urządzenia sieciowe blokują ruch UDP, nastąpi powrót do transportu odwrotnego opartego na protokole TCP.
Gdy połączenie jest nawiązywane, Interactive Connectivity Establishment (ICE) koordynuje zarządzanie STUN i TURN w celu optymalizacji prawdopodobieństwa nawiązania połączenia i zapewnienia pierwszeństwa preferowanym protokołom komunikacji sieciowej.
Każda sesja RDP używa dynamicznie przypisywanego portu UDP z zakresu portów efemerycznych (domyślnie od 49152 do 65535), który akceptuje ruch krótkiej ścieżki RDP. Port 65330 jest ignorowany w tym zakresie, ponieważ jest zarezerwowany do użytku wewnętrznego przez platformę Azure. Możesz również użyć mniejszego, przewidywalnego zakresu portów. Aby uzyskać więcej informacji, zobacz Ograniczanie zakresu portów używanych przez klientów sieci publicznych.
Porada
Krótka ścieżka RDP dla sieci publicznych będzie działać automatycznie bez żadnej dodatkowej konfiguracji, pod warunkiem, że sieci i zapory zezwalają na ruch przechodzący, a ustawienia transportu RDP w systemie operacyjnym Windows dla hostów sesji i klientów używają wartości domyślnych.
Poniższy diagram zawiera ogólne omówienie połączeń sieciowych podczas korzystania z krótkiej ścieżki RDP dla sieci publicznych, w których hosty sesji są połączone z usługą Microsoft Entra ID.
Dostępność przekaźnika TURN
Przekazywanie TURN jest dostępne w następujących regionach platformy Azure z usługą ACS TURN Relay (51.5.0.0/16):
- Australia Środkowa
- Australia Wschodnia
- Australia Południowo-Wschodnia
- Brazylia Południowa
- Kanada Środkowa
- Kanada Wschodnia
- Indie Środkowe
- Środkowe stany USA
- Wschodnie stany USA
- Wschodnie stany USA 2
- Francja Środkowa
- Niemcy Środkowo-Zachodnie
- Izrael Środkowy
- Japonia Wschodnia
- Japonia Zachodnia
- Korea Środkowa
- Korea Południowa
- Meksyk środkowy
- Północno-środkowe stany USA
- Europa Północna
- Norwegia Zachodnia
- Republika Południowej Afryki Północna
- Republika Południowej Afryki (Zachodnia)
- Południowo-środkowe stany USA
- Azja Południowo-Wschodnia
- Indie Południowe
- Hiszpania Środkowa
- Szwajcaria Północna
- Tawain Północ
- Tawain Północno-Wschodni
- Środkowe Zjednoczone Emiraty Arabskie
- Północne Zjednoczone Emiraty Arabskie
- Południowe Zjednoczone Królestwo
- Zachodnie Zjednoczone Królestwo
- Środkowo-zachodnie stany USA
- Europa Zachodnia
- Zachodnie stany USA
- Zachodnie stany USA 2
- Zachodnie stany USA 3
Przekaźnik TURN jest wybierany na podstawie fizycznej lokalizacji urządzenia klienckiego. Na przykład jeśli urządzenie klienckie znajduje się w Zjednoczonym Królestwie, zostanie wybrany przekaźnik TURN w regionie Południowe Zjednoczone Królestwo lub Zachodnie Zjednoczone Królestwo. Jeśli urządzenie klienckie znajduje się daleko od przekaźnika TURN, połączenie UDP może wrócić do protokołu TCP.
Translacja adresów sieciowych i zapory sieciowe
Większość klientów usługi Azure Virtual Desktop działa na komputerach w sieci prywatnej. Dostęp do Internetu jest zapewniany przez urządzenie bramy translacji adresów sieciowych (NAT). Dlatego brama translatora adresów sieciowych modyfikuje wszystkie żądania sieciowe z sieci prywatnej kierowane do Internetu. Taka modyfikacja ma na celu udostępnienie jednego publicznego adresu IP na wszystkich komputerach w sieci prywatnej.
Z powodu modyfikacji pakietów IP adresat ruchu zobaczy publiczny adres IP bramy translatora adresów sieciowych zamiast rzeczywistego nadawcy. Gdy ruch wróci do bramy translatora adresów sieciowych, zadba ona o przekazanie go do zamierzonego adresata bez wiedzy nadawcy. W większości scenariuszy urządzenia ukryte za takim translatorem adresów sieciowych nie są świadome zachodzącej translacji i nie znają adresu sieciowego bramy translatora adresów sieciowych.
Translator NAT ma zastosowanie do sieci wirtualnych platformy Azure, w których znajdują się wszystkie hosty sesji. Gdy host sesji próbuje nawiązać połączenie z adresem sieciowym w Internecie, brama translatora adresów (własna lub domyślnie dostarczona przez platformę Azure) lub usługa Azure Load Balancer wykonuje translację adresów. Aby uzyskać więcej informacji na temat różnych typów źródłowej translacji adresów sieciowych, zobacz Używanie źródłowej translacji adresów sieciowych (SNAT) dla połączeń wychodzących.
Większość sieci zazwyczaj zawiera zapory, które sprawdzają ruch i blokują go na podstawie reguł. Większość klientów konfiguruje swoje zapory w taki sposób, aby uniemożliwiać połączenia przychodzące (czyli niechciane pakiety z Internetu wysyłane bez żądania). Zapory wykorzystują różne techniki śledzenia przepływu danych w celu odróżnienia ruchu zamawianego od niechcianego. W kontekście TCP zapora śledzi pakiety SYN i ACK, a proces jest prosty. Zapory UDP zwykle używają algorytmów heurystycznych opartych na adresach pakietów do kojarzenia ruchu z przepływami UDP i zezwalania na niego lub blokowania go. Dostępnych jest wiele różnych implementacji NAT.
Sekwencja połączeń
Wszystkie połączenia rozpoczynają się od ustanowienia transportu odwrotnego połączenia opartego na protokole TCP za pośrednictwem bramy usługi Azure Virtual Desktop Gateway. Następnie klient i host sesji ustanawiają początkowy transport RDP i rozpoczynają wymianę swoich możliwości. Jeśli na hoście sesji jest włączona krótka ścieżka RDP dla sieci publicznych, 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) przydzielają gniazda UDP na każdym interfejsie i przechowują parę IP:Port w tabeli kandydackiej jako lokalny kandydat.
Usługa usług pulpitu zdalnego używa każdego gniazda UDP przydzielonego w poprzednim kroku, aby spróbować nawiązać połączenie z serwerem STUN usługi Azure Virtual Desktop w publicznym Internecie. Komunikacja odbywa się poprzez wysłanie małego pakietu UDP na port 3478.
Jeśli pakiet dotrze do serwera STUN, serwer STUN odpowiada za pomocą publicznego adresu IP i portu. Te informacje są przechowywane w tabeli kandydatów jako sugestie refleksyjne.
Gdy host sesji zbierze wszystkich kandydatów, host sesji używa ustanowionego transportu odwrotnego połączenia, aby przekazać listę kandydatów klientowi.
Gdy klient otrzymuje listę kandydatów od hosta sesji, klient wykonuje również zbieranie kandydatów po swojej stronie. Następnie klient wysyła swoją listę kandydatów do hosta sesji.
Po tym, jak gospodarz sesji i klient wymienią się listami kandydatów, obie strony próbują połączyć się ze sobą za pomocą wszystkich zebranych kandydatów. Ta próba połączenia jest jednoczesna po obu stronach. Wiele bram translatora adresów sieciowych jest skonfigurowanych tak, aby umożliwić ruch przychodzący do gniazda zaraz po zainicjowaniu wychodzącego transferu danych. Takie zachowanie bram translatora adresów sieciowych jest powodem, dla którego równoczesne połączenie jest niezbędne. Jeśli STUN zakończy się niepowodzeniem, ponieważ jest zablokowany, podejmowana jest próba połączenia przekaźnikowego za pomocą TURN.
Po początkowej wymianie pakietów klient i host sesji mogą ustanowić jeden lub wiele przepływów danych. Protokół RDP wybiera najszybszą ścieżkę sieciową spośród tych przepływów danych. Następnie klient ustanawia bezpieczne połączenie z hostem sesji przy użyciu protokołu TLS za pośrednictwem niezawodnego protokołu UDP i inicjuje transport krótkiej ścieżki RDP.
Po ustanowieniu przez protokół RDP transportu krótkiej ścieżki RDP 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ą dostęp zarówno do krótkiej ścieżki RDP dla sieci zarządzanej, jak i do sieci publicznych, zostanie użyty algorytm znaleziony jako pierwszy, co oznacza, że użytkownik użyje tego połączenia, które zostanie ustanowione jako pierwsze w tej sesji. Aby uzyskać więcej informacji, zobacz przykładowy scenariusz 4.
Konfiguracja sieci
Do obsługi krótkiej ścieżki RDP dla sieci publicznych nie jest zazwyczaj potrzebna żadna szczególna konfiguracja. Host sesji i klient automatycznie wykryją bezpośredni przepływ danych, jeśli jest to możliwe w konfiguracji sieci. Każde środowisko jest jednak unikatowe i niektóre konfiguracje sieci mogą mieć negatywny wpływ na szybkość powodzenia połączenia bezpośredniego. Postępuj zgodnie z zaleceniami , aby zwiększyć prawdopodobieństwo bezpośredniego przepływu danych.
Ponieważ krótka ścieżka RDP używa protokołu UDP do ustanawiania przepływu danych, jeśli zapora w sieci blokuje ruch UDP, krótka ścieżka RDP nie powiedzie się, a połączenie zostanie przywrócone do transportu odwrotnego opartego na protokole TCP. Usługa Azure Virtual Desktop korzysta z serwerów STUN dostarczanych przez usługi Azure Communication Services i Microsoft Teams. Ze względu na charakter tej funkcji wymagana jest łączność wychodząca z hostów sesji do klienta. Niestety, w większości przypadków nie można przewidzieć, gdzie znajdują się użytkownicy. W związku z tym zalecamy, aby zezwolić na wychodzącą łączność UDP z hostów sesji do Internetu. Aby zmniejszyć liczbę wymaganych portów, można ograniczyć zakres portów używanych przez klientów na potrzeby przepływu UDP. Podczas konfigurowania zapór dla protokołu Krótka ścieżka RDP należy korzystać z poniższych tabel w celach informacyjnych.
Jeśli Twoje środowisko korzysta z symetrycznego translatora adresów sieciowych, czyli mapowania pojedynczego prywatnego źródłowego adresu IP:Port na unikatowy publiczny adres IP:Port, możesz użyć połączenia przekazywanego z funkcją TURN. Dzieje się tak w przypadku używania bramy Azure Firewall i Azure translatora adresów sieciowych. Aby uzyskać więcej informacji na temat translatora NAT z Azure sieciami wirtualnymi, zobacz Źródłowa translacja adresów sieciowych z sieciami wirtualnymi.
Mamy kilka ogólnych zaleceń dotyczących pomyślnych połączeń przy użyciu krótkiej ścieżki RDP dla sieci publicznych. Aby uzyskać więcej informacji, zobacz Zalecenia ogólne.
Jeśli użytkownicy mają dostęp do krótkiej ścieżki RDP zarówno dla sieci zarządzanych, jak i sieci publicznych, zostanie użyty pierwszy znaleziony algorytm. Użytkownik użyje połączenia, które zostanie ustanowione jako pierwsze dla danej 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 działała krótka ścieżka RDP.
Uwaga
Firma Microsoft zakończyła przejście z wcześniej udostępnionej podsieci 20.202.0.0/16 do nowego zakresu adresów IP przekazywania 51.5.0.0/16 TURN w 39 regionach platformy Azure. Ta nowa gama jest przeznaczona wyłącznie dla usług Azure Virtual Desktop i Windows 365, oddzielając je od infrastruktury usług Azure Communication Services. Aktualizacja ma na celu ulepszenie krótkiej ścieżki RDP dla sieci publicznych (za pośrednictwem TURN/Relay), zapewniając szybszą i bardziej niezawodną łączność oraz lepsze środowisko użytkownika.
Uwaga
Połączenia oparte na architekturze TURN są podatne na zrywanie połączeń podczas aktualizacji przekaźnika TURN. Te aktualizacje występują zazwyczaj w planowanych oknach konserwacji, ale czasami mogą wystąpić poza planowanym oknem z powodu pilnych poprawek infrastruktury platformy Azure.
We wszystkich powyższych scenariuszach klient automatycznie łączy się ponownie w ciągu kilku sekund.
Sieć wirtualna hosta sesji
W poniższej tabeli wyszczególniono wymagania dotyczące źródła, miejsca docelowego i protokołu dotyczące Krótka ścieżka RDP dla sieci wirtualnej hosta sesji.
| Name (Nazwa) |
Źródło |
Port źródłowy |
Destination (Miejsce docelowe) |
Port docelowy |
Protocol (Protokół) |
Akcja |
| Bezpośrednie połączenie STUN |
Podsieć maszyny wirtualnej |
Dowolna |
Dowolna |
1024-65535
(domyślnie 49152-65535) |
UDP |
Zezwalaj |
| Przekaźnik ogłuszenia/skrętu |
Podsieć maszyny wirtualnej |
Dowolna |
51.5.0.0/16 |
3478 |
UDP |
Zezwalaj |
Sieć kliencka
W poniższej tabeli wyszczególniono wymagania dotyczące źródła, miejsca docelowego i protokołu dla urządzeń klienckich.
| Name (Nazwa) |
Źródło |
Port źródłowy |
Destination (Miejsce docelowe) |
Port docelowy |
Protocol (Protokół) |
Akcja |
| Bezpośrednie połączenie STUN |
Sieć kliencka |
Dowolna |
Publiczne adresy IP przypisane do bramy translatora NAT lub usługi Azure Firewall (dostarczane przez punkt końcowy STUN) |
1024-65535
(domyślnie 49152-65535) |
UDP |
Zezwalaj |
| Przekaźnik OGŁUSZENIA/SKRĘTU |
Sieć kliencka |
Dowolna |
51.5.0.0/16 |
3478 |
UDP |
Zezwalaj |
Ważna
Zakres adresów IP dedykowanego przekaźnika TURN dla usługi Azure Government to 20.140.236.0/22. Krótka ścieżka RDP za pośrednictwem TURN jest obecnie w publicznej wersji zapoznawczej w usłudze Azure Government. Klienci mogą wypróbować tę funkcję, korzystając z pierścienia weryfikacji.
Sieć wirtualna hosta sesji
W poniższej tabeli wyszczególniono wymagania dotyczące źródła, miejsca docelowego i protokołu dotyczące Krótka ścieżka RDP dla sieci wirtualnej hosta sesji.
| Name (Nazwa) |
Źródło |
Port źródłowy |
Destination (Miejsce docelowe) |
Port docelowy |
Protocol (Protokół) |
Akcja |
| Bezpośrednie połączenie STUN |
Podsieć maszyny wirtualnej |
Dowolna |
Dowolna |
1024-65535
(domyślnie: 49152-65535) |
UDP |
Zezwalaj |
| Przekaźnik OGŁUSZENIA/SKRĘTU |
Podsieć maszyny wirtualnej |
Dowolna |
20.140.236.0/22 |
3478 |
UDP |
Zezwalaj |
Sieć kliencka
W poniższej tabeli wyszczególniono wymagania dotyczące źródła, miejsca docelowego i protokołu dla urządzeń klienckich.
| Name (Nazwa) |
Źródło |
Port źródłowy |
Destination (Miejsce docelowe) |
Port docelowy |
Protocol (Protokół) |
Akcja |
| Bezpośrednie połączenie STUN |
Sieć kliencka |
Dowolna |
Publiczne adresy IP przypisane do bramy translatora NAT lub usługi Azure Firewall (dostarczane przez punkt końcowy STUN) |
1024-65535
(domyślnie: 49152-65535) |
UDP |
Zezwalaj |
| Przekaźnik OGŁUSZENIA/SKRĘTU |
Sieć kliencka |
Dowolna |
20.140.236.0/22 |
3478 |
UDP |
Zezwalaj |
Obsługa protokołu Teredo
Chociaż protokół Teredo nie jest wymagany w przypadku krótkiej ścieżki RDP, dodaje dodatkowe sugestie przechodzenia między protokołami NAT i zwiększa szansę pomyślnego połączenia Krótka ścieżka RDP w sieciach obsługujących tylko protokół IPv4. Aby dowiedzieć się, jak włączyć protokół Teredo na hostach i klientach sesji, zobacz Włączanie obsługi protokołu Teredo.
Obsługa protokołu UPnP
Aby zwiększyć szanse na bezpośrednie połączenie, po stronie klienta usług pulpitu zdalnego Krótka ścieżka RDP protokołu RDP może używać protokołu UPnP do konfigurowania mapowania portów routera NAT. 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 znajdujących się zazwyczaj w sieci domowej. Protokół UPnP jest domyślnie włączony w większości routerów domowych i punktów dostępu, ale często jest wyłączony w sieciach firmowych.
Zalecenia ogólne
Poniżej przedstawiono kilka ogólnych zaleceń dotyczących korzystania z krótkiej ścieżki RDP w sieciach publicznych:
Należy unikać korzystania z konfiguracji tunelowania wymuszanego, jeśli użytkownicy uzyskują dostęp do usługi Azure Virtual Desktop przez Internet.
Upewnij się, że nie używasz konfiguracji z podwójnym translatorem NAT lub translacją NAT klasy operatorskiej (CGN).
Zaproponuj użytkownikom, aby nie wyłączali protokołu UPnP na routerach domowych.
Unikaj korzystania z usług inspekcji pakietów w chmurze.
Nie korzystaj z rozwiązań VPN opartych na protokole TCP.
Włącz łączność IPv6 lub Teredo.
Bezpieczeństwo połączenia
Krótka ścieżka RDP rozszerza możliwości wielotransportowe protokołu RDP. Nie zastępuje on transportu odwrotnego połączenia, ale go uzupełnia. Zarządzanie brokerem sesji początkowych odbywa się za pośrednictwem usługi Azure Virtual Desktop i transportu odwrotnego połączenia. Wszystkie próby nawiązania połączenia są ignorowane, o ile najpierw nie zostaną dopasowane do sesji połączenia odwrotnego. Krótka ścieżka RDP jest ustanawiana po uwierzytelnieniu, a jeśli zostanie pomyślnie ustanowiona, transport odwrotnego połączenia zostanie porzucony, a cały ruch będzie przepływał przez krótką ścieżkę RDP.
Krótka ścieżka RDP używa bezpiecznego połączenia przy użyciu protokołu TLS przez niezawodne połączenie UDP między klientem i hostem sesji przy użyciu certyfikatów hosta sesji. Domyślnie certyfikat używany do szyfrowania protokołu RDP jest generowany samodzielnie przez system operacyjny podczas wdrażania. Obecnie usługa Azure Virtual Desktop nie obsługuje korzystania z certyfikatu wystawionego przez urząd certyfikacji.
Przykładowe scenariusze
Poniżej przedstawiono kilka przykładowych scenariuszy pokazujących, jak są oceniane połączenia w celu podjęcia decyzji, czy należy użyć krótkiej ścieżki RDP w różnych topologiach sieci.
Scenariusz 1
Połączenie UDP można ustanowić tylko między urządzeniem klienckim i hostem sesji za pośrednictwem sieci publicznej (Internetu). Połączenie bezpośrednie, takie jak VPN, nie jest dostępne. Protokół UDP jest dozwolony przez zaporę lub urządzenie NAT.
Scenariusz 2
Zapora lub urządzenie translatora adresów sieciowych blokuje bezpośrednie połączenie UDP, ale przekazywane połączenie UDP może być przekazywane przy użyciu instrukcji TURN między urządzeniem klienckim a hostem sesji za pośrednictwem sieci publicznej (Internetu). Inne połączenie bezpośrednie, takie jak VPN, nie jest dostępne.
Scenariusz 3
Połączenie UDP może zostać ustanowione między urządzeniem klienckim a hostem sesji za pośrednictwem sieci publicznej lub bezpośredniego połączenia VPN, ale krótka ścieżka RDP protokołu RDP dla sieci zarządzanych nie jest włączona. Gdy klient inicjuje połączenie, protokół ICE/STUN może zobaczyć wiele tras i oceni każdą trasę i wybierze tę o najmniejszym opóźnieniu.
W tym przykładzie połączenie UDP z użyciem krótkiej ścieżki RDP dla sieci publicznych za pośrednictwem bezpośredniego połączenia VPN zostanie nawiązane, ponieważ ma najmniejsze opóźnienie, co wskazuje zielona linia.
Scenariusz 4
Włączone są zarówno krótkie ścieżki RDP dla sieci publicznych, jak i sieci zarządzanych. Połączenie UDP może zostać ustanowione między urządzeniem klienckim a hostem sesji za pośrednictwem sieci publicznej lub bezpośredniego połączenia VPN. Gdy klient inicjuje połączenie, podejmowane są równoczesne próby nawiązania połączenia przy użyciu krótkiej ścieżki RDP dla sieci zarządzanych przez port 3390 (domyślnie) i przy użyciu krótkiej ścieżki RDP dla sieci publicznych za pośrednictwem protokołu ICE/STUN. Zostanie użyty algorytm znaleziony jako pierwszy, a użytkownik użyje połączenia, które zostanie ustanowione jako pierwsze dla tej sesji.
Ponieważ korzystanie z sieci publicznej ma więcej kroków, na przykład urządzenie NAT, moduł równoważenia obciążenia lub serwer STUN, jest prawdopodobne, że pierwszy znaleziony algorytm wybierze połączenie przy użyciu krótkiej ścieżki RDP dla sieci zarządzanych i zostanie ustanowiony jako pierwszy.
Scenariusz 5
Połączenie UDP może zostać ustanowione między urządzeniem klienckim a hostem sesji za pośrednictwem sieci publicznej lub bezpośredniego połączenia VPN, ale krótka ścieżka RDP protokołu RDP dla sieci zarządzanych nie jest włączona. Aby uniemożliwić ICE/STUN korzystanie z określonej trasy, administrator może zablokować jedną z tras dla ruchu UDP. Zablokowanie trasy spowodowałoby, że pozostała ścieżka byłaby zawsze używana.
W tym przykładzie protokół UDP jest blokowany w bezpośrednim połączeniu VPN, a protokół ICE/STUN ustanawia połączenie przez sieć publiczną.
Scenariusz 6
Skonfigurowano zarówno krótką ścieżkę RDP dla sieci publicznych, jak i sieci zarządzanych, jednak nie można ustanowić połączenia UDP przy użyciu bezpośredniego połączenia VPN. Zapora lub urządzenie translatora adresów sieciowych również blokuje bezpośrednie połączenie UDP przy użyciu sieci publicznej (Internetu), natomiast przekazywane połączenie UDP może być przekazywane przy użyciu instrukcji TURN między urządzeniem klienckim a hostem sesji przez sieć publiczną (Internet).
Scenariusz 7
Skonfigurowano zarówno krótką ścieżkę RDP dla sieci publicznych, jak i sieci zarządzanych, jednak nie można ustanowić połączenia UDP. W takim przypadku Krótka ścieżka RDP RDP zakończy się niepowodzeniem i połączenie zostanie przywrócone do transportu odwrotnego opartego na protokole TCP.
Następne kroki
