Topologia sieci i łączność dla usługi Azure Virtual Desktop

Projekt i implementacja funkcji sieciowych platformy Azure w usłudze Azure Virtual Desktop ma kluczowe znaczenie dla strefy docelowej usługi Azure Virtual Desktop. Ten artykuł opiera się na kilku przewodnikach Cloud Adoption Framework dla zasad architektury strefy docelowej w skali przedsiębiorstwa oraz zalecenia dotyczące zarządzania topologią sieci i łącznością na dużą skalę.

Podstawy projektowania obejmują:

• Integracja hybrydowa na potrzeby łączności między środowiskami lokalnymi, wielochmurowymi i brzegowymi oraz użytkownikami globalnymi. Aby uzyskać więcej informacji, zobacz Obsługa skali przedsiębiorstwa dla hybrydowych i wielochmurowych.
• Wydajność i niezawodność na dużą skalę w celu zapewnienia spójnego, małego opóźnienia i skalowalności obciążeń.
• Zabezpieczenia sieciowe oparte na zerowym zaufaniu, które ułatwiają zabezpieczanie obwodów sieci i przepływów ruchu. Aby uzyskać więcej informacji, zobacz Strategie zabezpieczeń sieci na platformie Azure.
• Rozszerzalność w celu łatwego rozszerzania śladu sieciowego bez konieczności przeróbki projektowej.

Składniki i pojęcia dotyczące sieci

• Usługa Azure Virtual Network to podstawowy blok konstrukcyjny dla sieci prywatnych na platformie Azure. Dzięki usłudze Virtual Network wiele typów zasobów platformy Azure, takich jak usługa Azure Virtual Machines, może komunikować się ze sobą, z Internetem i lokalnymi centrami danych. Sieć wirtualna jest podobna do tradycyjnej sieci działającej we własnym centrum danych. Jednak sieć wirtualna oferuje korzyści infrastruktury platformy Azure dotyczące skalowania, dostępności i izolacji.
• Topologia sieci piasty i szprych to typ architektury sieci, w której sieć wirtualna piasty pełni rolę centralnego punktu łączności z kilkoma sieciami wirtualnymi szprych. Centrum może być również punktem łączności z lokalnymi centrami danych. Sieci wirtualne będące szprychami są równorzędne z piastą i ułatwiają izolowanie obciążeń.
• Azure Virtual WAN to usługa sieciowa, która łączy funkcje sieciowe, zabezpieczeń i routingu w jednym interfejsie operacyjnym.
• Wirtualne urządzenie sieciowe (WUS) to urządzenie sieciowe, które obsługuje funkcje takie jak łączność, dostarczanie aplikacji, optymalizacja sieci rozległej (WAN) i zabezpieczenia. Urządzenia WUS obejmują usługę Azure Firewall i usługę Azure Load Balancer.
• W scenariuszu wymuszonego tunelowania cały ruch związany z Internetem pochodzący z maszyn wirtualnych platformy Azure jest kierowany lub wymuszany, aby przejść przez urządzenie inspekcji i inspekcji. Nieautoryzowany dostęp do Internetu może potencjalnie prowadzić do ujawnienia informacji lub innych rodzajów naruszeń zabezpieczeń bez inspekcji ruchu lub inspekcji.
• Sieciowe grupy zabezpieczeń służą do filtrowania ruchu sieciowego do i z zasobów platformy Azure w sieci wirtualnej platformy Azure. Sieciowa grupa zabezpieczeń zawiera reguły zabezpieczeń, które zezwalają na lub blokują przychodzący ruch sieciowy lub wychodzący ruch sieciowy dla kilku typów zasobów platformy Azure.
• Grupy zabezpieczeń aplikacji umożliwiają skonfigurowanie zabezpieczeń sieci jako naturalnego rozszerzenia struktury aplikacji. Grupy zabezpieczeń aplikacji umożliwiają grupowanie maszyn wirtualnych i definiowanie zasad zabezpieczeń sieci opartych na tych grupach. Zasady zabezpieczeń można używać ponownie na dużą skalę bez konieczności ręcznego obsługiwania jawnych adresów IP.
• Trasy zdefiniowane przez użytkownika mogą służyć do zastępowania domyślnych tras systemowych platformy Azure. Możesz również użyć tras zdefiniowanych przez użytkownika, aby dodać dodatkowe trasy do tabeli tras podsieci.
• Remote Desktop Protocol Shortpath (RDP Shortpath) to funkcja usługi Azure Virtual Desktop oparta na uniwersalnym protokole kontroli szybkości (URCP). Protokół RDP Shortpath ustanawia bezpośredni transport oparty na protokole UDP (User Datagram Protocol) między obsługiwanym klientem pulpitu zdalnego systemu Windows i hostami sesji usługi Azure Virtual Desktop. Platforma URCP rozszerza połączenia UDP, zapewniając aktywne monitorowanie warunków sieciowych i możliwości jakości usług (QoS).
• Usługa Azure Private Link z usługą Azure Virtual Desktop (wersja zapoznawcza) umożliwia używanie prywatnego punktu końcowego na platformie Azure do łączenia hostów sesji z usługą Azure Virtual Desktop. Za pomocą usługi Private Link ruch między siecią wirtualną a usługą Azure Virtual Desktop jest przesyłany w sieci szkieletowej firmy Microsoft. W związku z tym nie musisz łączyć się z publicznym Internetem, aby uzyskać dostęp do usług Azure Virtual Desktop.

Scenariusze sieciowe

Aby ustanowić strefę docelową usługi Azure Virtual Desktop, projekt i implementacja możliwości sieciowych ma kluczowe znaczenie. Produkty i usługi sieciowe platformy Azure obsługują szeroką gamę możliwości. Wybrana architektura i sposób struktury usług zależą od obciążeń, ładu i wymagań organizacji.

Następujące kluczowe wymagania i zagadnienia wpływają na decyzje dotyczące wdrażania usługi Azure Virtual Desktop:

• Wymagania dotyczące ruchu przychodzącego i wychodzącego w Internecie.
• Użycie urządzenia WUS w bieżącej architekturze.
• Łączność usługi Azure Virtual Desktop ze standardową siecią wirtualną koncentratora lub koncentratorem usługi Virtual WAN.
• Model połączenia hosta sesji. Można użyć modelu natywnego lub ścieżki RDP Shortpath.
• Wymagania dotyczące inspekcji ruchu dla:
  • Ruch wychodzący z Internetu z usługi Azure Virtual Desktop.
  • Ruch przychodzący z Internetu do usługi Azure Virtual Desktop.
  • Ruch usługi Azure Virtual Desktop do lokalnych centrów danych.
  • Ruch usługi Azure Virtual Desktop do innych wystąpień sieci wirtualnej.
  • Ruch w sieci wirtualnej usługi Azure Virtual Desktop.

Najbardziej typowym scenariuszem sieciowym usługi Azure Virtual Desktop jest topologia piasty i szprych z łącznością hybrydową.

Scenariusz 1. Piasta i szprychy z łącznością hybrydową

W tym scenariuszu jest używany standardowy model połączenia hosta sesji.

Profil klienta

Ten scenariusz jest idealny, jeśli:

• Nie potrzebujesz inspekcji ruchu między sieciami usługi Azure Virtual Desktop i innymi sieciami wirtualnymi platformy Azure.
• Nie potrzebujesz inspekcji ruchu między sieciami usługi Azure Virtual Desktop i lokalnymi centrami danych.
• Nie potrzebujesz inspekcji ruchu ruchu wychodzącego z sieci usługi Azure Virtual Desktop.
• Nie musisz kontrolować publicznych adresów IP używanych podczas tłumaczenia adresów sieciowych (SNAT) źródłowego dla wychodzących połączeń internetowych usługi Azure Virtual Desktop.
• Nie wymuszasz ruchu wewnętrznego usługi Azure Virtual Desktop.
• Masz wstępnie istniejącą łączność hybrydową ze środowiskami lokalnymi za pośrednictwem usługi Azure ExpressRoute lub wirtualnej sieci prywatnej (VPN) typu lokacja-lokacja (S2S).
• Masz wstępnie istniejące serwery niestandardowe usług domena usługi Active Directory Services (AD DS) i systemu nazw domen (DNS).
• Usługa Azure Virtual Desktop jest używana przy użyciu standardowego modelu połączenia, a nie krótkiej ścieżki protokołu RDP.

Składniki architektury

Ten scenariusz można zaimplementować za pomocą następujących elementów:

• Serwery usług AD DS i niestandardowe serwery DNS.
• Sieciowe grupy zabezpieczeń.
• Azure Network Watcher.
• Wychodzący Internet za pośrednictwem domyślnej ścieżki sieci wirtualnej platformy Azure.
• Usługa ExpressRoute lub brama sieci wirtualnej sieci VPN na potrzeby łączności hybrydowej z systemami lokalnymi.
• Prywatna strefa DNS platformy Azure.
• Prywatne punkty końcowe platformy Azure.
• Konta magazynu usługi Azure Files.
• Azure Key Vault.

Pobierz plik programu Visio z pełną architekturą odporną na błędy usługi Azure Virtual Desktop w wielu regionach.

Kwestie wymagające rozważenia

• Ten scenariusz nie obsługuje bezpośredniej łączności sieciowej między klientem a hostem sesji publicznej lub prywatnej. W tym scenariuszu nie można użyć ścieżki RDP Shortpath.
• Brama płaszczyzny sterowania usługi Azure Virtual Desktop, która używa publicznego punktu końcowego, zarządza połączeniami klientów. W związku z tym klienci usługi Azure Virtual Desktop mogą tworzyć połączenia wychodzące z wymaganymi adresami URL usługi Azure Virtual Desktop. Aby uzyskać więcej informacji na temat wymaganych adresów URL, zobacz sekcję Internet tego artykułu i Wymagane adresy URL dla usługi Azure Virtual Desktop.
• Nie są potrzebne żadne publiczne adresy IP ani inne publiczne ścieżki przychodzące do hostów sesji. Ruch od klientów do hostów sesji przepływa przez bramę płaszczyzny sterowania usługi Azure Virtual Desktop.
• Nie ma komunikacji równorzędnej sieci wirtualnych między szprychami usługi Azure Virtual Desktop. Cały ruch przechodzi przez centrum łączności.
• Wychodzące połączenia internetowe z hostów sesji usługi Azure Virtual Desktop przechodzą przez domyślny proces translacji adresów sieciowych (NAT) dla ruchu wychodzącego platformy Azure. Używane są dynamiczne publiczne adresy IP platformy Azure. Klienci nie mają kontroli nad używanymi wychodzącym publicznymi adresami IP.
• Połączenia z hostów sesji do kont magazynu usługi Azure Files są ustanawiane przy użyciu prywatnych punktów końcowych.
• Prywatne strefy DNS platformy Azure służą do rozpoznawania prywatnych przestrzeni nazw punktów końcowych dla następujących usług:
  • Konta magazynu usługi Azure Files, które używają nazwy privatelink.file.core.windows.net
  • Magazyny kluczy, które używają nazwy privatelink.vaultcore.azure.net
• Filtrowanie sieci nie jest wymuszane w tym scenariuszu. Jednak sieciowe grupy zabezpieczeń są umieszczane we wszystkich podsieciach, aby można było monitorować ruch i uzyskiwać szczegółowe informacje. W usłudze Network Watcher do tych celów są używane funkcje analizy ruchu i rejestrowania przepływów sieciowych grup zabezpieczeń.

Scenariusz 2: Piasta i szprychy z łącznością hybrydową za pośrednictwem sieci zarządzanych przy użyciu protokołu RDP Shortpath

Aby uzyskać szczegółowe wskazówki dotyczące wdrażania, zobacz Łączność krótka protokołu RDP dla sieci zarządzanych.

Profil klienta

Ten scenariusz jest idealny, jeśli:

• Chcesz ograniczyć liczbę połączeń za pośrednictwem Internetu z hostami sesji usługi Azure Virtual Desktop.
• Masz wstępnie istniejącą łączność hybrydową ze środowiska lokalnego do platformy Azure za pośrednictwem usługi ExpressRoute lub połączenia typu lokacja-lokacja (P2S).
• Masz bezpośrednią łączność sieciową między klientami RDP i hostami usługi Azure Virtual Desktop. Zazwyczaj w tym scenariuszu jest używana jedna z następujących konfiguracji:
  • Sieci lokalne kierowane do sieci platformy Azure usługi Azure Virtual Desktop
  • Połączenia sieci VPN klienta kierowane do sieci wirtualnych usługi Azure Virtual Desktop platformy Azure
• Należy ograniczyć użycie przepustowości hostów maszyn wirtualnych za pośrednictwem sieci prywatnych, takich jak sieć VPN lub usługa ExpressRoute.
• Chcesz określić priorytet ruchu usługi Azure Virtual Desktop w sieci.
• Nie potrzebujesz inspekcji ruchu między sieciami usługi Azure Virtual Desktop i innymi sieciami wirtualnymi platformy Azure.
• Nie potrzebujesz inspekcji ruchu między sieciami usługi Azure Virtual Desktop i lokalnymi centrami danych.
• Masz wstępnie istniejące serwery niestandardowe usług AD DS lub DNS.

Składniki architektury

Ten scenariusz można zaimplementować za pomocą następujących elementów:

• Usługa ExpressRoute lub brama sieci wirtualnej sieci VPN na potrzeby łączności hybrydowej ze środowiskami lokalnymi z wystarczającą przepustowością.
• Serwery usług AD DS i niestandardowe serwery DNS.
• Sieciowe grupy zabezpieczeń.
• Wychodzący Internet za pośrednictwem domyślnej ścieżki sieci wirtualnej platformy Azure.
• Obiekty zasad grupy domeny (GPO) lub lokalne obiekty zasad grupy.
• Konta magazynu usługi Azure Files.
• Prywatne punkty końcowe platformy Azure.
• Prywatna strefa DNS platformy Azure.

Kwestie wymagające rozważenia

• Łączność hybrydowa musi być dostępna za pośrednictwem sieci VPN lub usługi ExpressRoute z bezpośrednim połączeniem sieciowym klienta RDP z prywatnymi hostami maszyn wirtualnych na porcie 3390.

Uwaga

W przypadku sieci zarządzanych można zmienić domyślny port UDP.

• Aby włączyć protokół UDP za pośrednictwem sieci zarządzanych, należy użyć obiektu zasad grupy domeny lub lokalnego obiektu zasad grupy.
• Łączność hybrydowa musi mieć wystarczającą przepustowość, aby umożliwić bezpośrednie połączenia UDP z hostami maszyn wirtualnych.
• Łączność hybrydowa musi mieć routing bezpośredni, aby umożliwić nawiązywanie połączeń z hostami maszyn wirtualnych.
• Brama płaszczyzny sterowania usługi Azure Virtual Desktop, która używa publicznego punktu końcowego, zarządza połączeniami klientów. W związku z tym klienci usługi Azure Virtual Desktop mogą tworzyć połączenia wychodzące z wymaganymi adresami URL usługi Azure Virtual Desktop. Aby uzyskać więcej informacji na temat wymaganych adresów URL, zobacz sekcję Internet tego artykułu i Wymagane adresy URL dla usługi Azure Virtual Desktop.
• Nie są potrzebne żadne publiczne adresy IP ani inne publiczne ścieżki przychodzące do hostów sesji. Ruch od klientów do hostów sesji przepływa przez bramę płaszczyzny sterowania usługi Azure Virtual Desktop.
• Wychodzące połączenie internetowe z hostów sesji usługi Azure Virtual Desktop przechodzi przez domyślny proces translatora adresów sieciowych wychodzących platformy Azure. Używane są dynamiczne publiczne adresy IP platformy Azure. Klienci nie mają kontroli nad używanymi wychodzącym publicznymi adresami IP.
• Połączenia z hostów sesji do kont magazynu usługi Azure Files są ustanawiane przy użyciu prywatnych punktów końcowych.
• Prywatne strefy DNS platformy Azure są używane do rozpoznawania przestrzeni nazw prywatnego punktu końcowego.
• Filtrowanie sieci nie jest wymuszane w tym scenariuszu. Jednak sieciowe grupy zabezpieczeń są umieszczane we wszystkich podsieciach, aby można było monitorować ruch i uzyskiwać szczegółowe informacje. W usłudze Network Watcher do tych celów są używane funkcje analizy ruchu i rejestrowania przepływów sieciowych grup zabezpieczeń.

Uwaga

Obecnie usługa Azure Virtual Desktop nie obsługuje jednocześnie korzystania z usługi Private Link i protokołu RDP Shortpath.

Scenariusz 3. Piasta i szprychy z sieciami publicznymi przy użyciu protokołu RDP Shortpath

Aby uzyskać szczegółowe wskazówki dotyczące wdrażania, zobacz RDP Shortpath connectivity for public networks (Łączność krótka protokołu RDP dla sieci publicznych).

Profil klienta

Ten scenariusz jest idealny, jeśli:

• Połączenia klienta usługi Azure Virtual Desktop przechodzą przez publiczny Internet. Typowe scenariusze obejmują użytkowników służbowych, użytkowników biura zdalnego, którzy nie są połączeni z sieciami firmowymi i zdalnymi użytkownikami wykonawcy.
• Masz połączenia o dużym opóźnieniu lub niskiej przepustowości z hostami sesji usługi Azure Virtual Desktops.
• Należy ograniczyć użycie przepustowości hostów sesji usługi Azure Virtual Desktop za pośrednictwem zasad sieci QoS.
• Chcesz określić priorytet ruchu usługi Azure Virtual Desktop w sieci za pośrednictwem zasad QoS.
• Połączenia RDP klienta zaczynają się od sieci z niespójną przepustowością i szybkością.
• Masz bezpośrednią łączność wychodzącą z hostów sesji usługi Azure Virtual Desktop. Nie używasz routingu tunelu wymuszonego za pośrednictwem sieci lokalnych.
• Nie potrzebujesz inspekcji ruchu między sieciami usługi Azure Virtual Desktop i innymi sieciami wirtualnymi platformy Azure.
• Nie potrzebujesz inspekcji ruchu między sieciami usługi Azure Virtual Desktop i lokalnymi centrami danych.
• Masz wstępnie istniejące serwery niestandardowe usług AD DS lub DNS.

Składniki architektury

Ten scenariusz można zaimplementować za pomocą następujących elementów:

• Usługa ExpressRoute lub brama sieci wirtualnej sieci VPN na potrzeby łączności hybrydowej ze środowiskami lokalnymi. Ta konfiguracja jest odpowiednia, gdy istnieje wystarczająca przepustowość do obsługi połączeń z aplikacjami lokalnymi, danymi lub połączeniami usług AD DS. Nie zalecamy używania wymuszonego tunelowania do wysyłania ruchu usługi Azure Virtual Desktop przez routery lokalne.
• Serwery usług AD DS i niestandardowe serwery DNS.
• Sieciowe grupy zabezpieczeń.
• Network Watcher.
• Wychodzący Internet za pośrednictwem domyślnej ścieżki sieci wirtualnej platformy Azure.
• Obiekty zasad grupy domeny lub lokalne obiekty zasad grupy.
• Konta magazynu usługi Azure Files.
• Prywatne punkty końcowe platformy Azure.
• Prywatna strefa DNS platformy Azure.

Kwestie wymagające rozważenia

• Zezwalaj na następujące typy połączeń:

  • Połączenia UDP ruchu wychodzącego z hostów sesji usługi Azure Virtual Desktop do narzędzi przechodzenia sesji usługi Azure Virtual Desktop dla translatora adresów sieciowych (STUN) i przechodzenia przy użyciu usługi translatora adresów sieciowych usługi Relay (TURN) na porcie 3478
  • Połączenia UDP z klientów RDP w zakresie portów 49152–65535

  Ustawienie, które konfiguruje te połączenia, jest domyślnie włączone i utrzymuje ten sam poziom szyfrowania co połączenie odwrotne protokołu Transmission Control Protocol (TCP). Aby uzyskać informacje na temat ograniczania zakresów portów klienta protokołu RDP, zobacz Ograniczanie zakresu portów podczas korzystania z protokołu RDP Shortpath dla sieci publicznych.

• Brama płaszczyzny sterowania usługi Azure Virtual Desktop, która używa publicznego punktu końcowego, zarządza połączeniami klientów. W związku z tym klienci usługi Azure Virtual Desktop mogą tworzyć połączenia wychodzące z wymaganymi adresami URL usługi Azure Virtual Desktop. Aby uzyskać więcej informacji na temat wymaganych adresów URL, zobacz sekcję Internet tego artykułu i Wymagane adresy URL dla usługi Azure Virtual Desktop.

• Routery konsumentów, które zazwyczaj znajdują się w sieciach użytkowników domowych, powinny mieć włączoną funkcję Universal Plug and Play (UPnP).

• Nie są potrzebne żadne publiczne adresy IP ani inne publiczne ścieżki przychodzące do hostów sesji. Ruch od klientów do hostów sesji przepływa przez bramę płaszczyzny sterowania usługi Azure Virtual Desktop.

• Wychodzące połączenie internetowe z hostów sesji usługi Azure Virtual Desktop przechodzi przez domyślny proces translatora adresów sieciowych wychodzących platformy Azure. Używane są dynamiczne publiczne adresy IP platformy Azure. Klienci nie mają kontroli nad używanymi wychodzącym publicznymi adresami IP.

• Należy skonfigurować wyróżniający punkt kodu usług (DSCP) oznaczania na hostach sesji. Użyj lokalnych obiektów zasad grupy lub obiektów zasad grupy domeny dla tej konfiguracji. W przypadku korzystania ze znaczników DSCP urządzenia sieciowe mogą stosować zasady QoS dla ruchu usługi Azure Virtual Desktop. Aby uzyskać więcej informacji, zobacz Implementowanie jakości usług (QoS) dla usługi Azure Virtual Desktop.

• Połączenia z hostów sesji do kont magazynu usługi Azure Files są ustanawiane przy użyciu prywatnych punktów końcowych.

• Prywatne strefy DNS platformy Azure są używane do rozpoznawania przestrzeni nazw prywatnego punktu końcowego.

• Filtrowanie sieci nie jest wymuszane w tym scenariuszu. Jednak sieciowe grupy zabezpieczeń są umieszczane we wszystkich podsieciach, aby można było monitorować ruch i uzyskiwać szczegółowe informacje. W usłudze Network Watcher do tych celów są używane funkcje analizy ruchu i rejestrowania przepływów sieciowych grup zabezpieczeń.

Ogólne zagadnienia i zalecenia dotyczące projektowania

W poniższych sekcjach przedstawiono ogólne zagadnienia dotyczące projektowania i zalecenia dotyczące topologii i łączności sieci usługi Azure Virtual Desktop.

Topologia sieci piasty i szprychy a topologia sieci wirtualnej sieci WAN

Usługa Virtual WAN obsługuje łączność tranzytową między siecią VPN i usługą ExpressRoute , ale nie obsługuje topologii piasty i szprych.

Usługi zarządzania tożsamościami

Wymagania dotyczące łączności usług tożsamości na hostach sesji usługi Azure Virtual Desktop zależą od modelu tożsamości.

• W przypadku maszyn wirtualnych dołączonych do usługi Microsoft Entra Domain Services: sieci usługi Azure Virtual Desktop muszą mieć łączność z siecią, w której jest hostowana usługa tożsamości.
• W przypadku maszyn wirtualnych dołączonych do usługi Microsoft Entra ID: hosty sesji usługi Azure Virtual Desktop tworzą połączenia wychodzące z publicznymi punktami końcowymi identyfikatora Entra firmy Microsoft. W związku z tym nie są wymagane żadne konfiguracje łączności prywatnej.

DNS

Hosty sesji usługi Azure Virtual Desktop mają te same wymagania dotyczące rozpoznawania nazw co inne obciążenia infrastruktury jako usługi (IaaS). W związku z tym wymagana jest łączność z niestandardowymi serwerami DNS lub dostępem za pośrednictwem łącza sieci wirtualnej do prywatnych stref DNS platformy Azure. Dodatkowe prywatne strefy DNS platformy Azure są wymagane do hostowania prywatnych przestrzeni nazw punktów końcowych niektórych usług typu platforma jako usługa (PaaS), takich jak konta magazynu i usługi zarządzania kluczami.

Aby uzyskać więcej informacji, zobacz Konfiguracja usługi DNS prywatnego punktu końcowego platformy Azure.

Aby ułatwić użytkownikom końcowym konfigurację klienta usługi Azure Virtual Desktop, w tym subskrypcję kanału informacyjnego usług pulpitu zdalnego (RDS), najlepiej skonfigurować odnajdywanie wiadomości e-mail. Należy skonfigurować odnajdywanie wiadomości e-mail w publicznej domenie DNS, a następnie subskrybować kanał informacyjny usług pulpitu zdalnego. Aby uzyskać więcej informacji, zobacz Konfigurowanie odnajdywania wiadomości e-mail w celu subskrybowania kanału informacyjnego usług pulpitu zdalnego.

Przepustowość i opóźnienie

Usługa Azure Virtual Desktop używa protokołu RDP. Aby dowiedzieć się więcej na temat protokołu RDP, zobacz Wymagania dotyczące przepustowości protokołu RDP (Remote Desktop Protocol).

Opóźnienie połączenia różni się w zależności od lokalizacji użytkowników i maszyn wirtualnych. Usługi Azure Virtual Desktop są stale wdrażane w nowych lokalizacjach geograficznych, aby zwiększyć opóźnienie. Aby zminimalizować opóźnienie środowiska klientów usługi Azure Virtual Desktop, użyj narzędzia do szacowania środowiska usługi Azure Virtual Desktop. To narzędzie udostępnia przykłady czasu rundy (RTT) od klientów. Te informacje umożliwiają umieszczenie hostów sesji w regionie znajdującym się najbliżej użytkowników końcowych i najniższym RTT. Aby uzyskać informacje na temat interpretowania wyników z narzędzia do szacowania, zobacz Analizowanie jakości połączenia w usłudze Azure Virtual Desktop.

QoS z protokołem RDP Shortpath

Protokół RDP Shortpath dla sieci zarządzanych zapewnia bezpośredni transport oparty na protokole UDP między klientem usług pulpitu zdalnego a hostem sesji. Krótka ścieżka protokołu RDP dla sieci zarządzanych umożliwia skonfigurowanie zasad QoS dla danych protokołu RDP. Funkcja QoS w usłudze Azure Virtual Desktop umożliwia ruch RDP w czasie rzeczywistym, który jest wrażliwy na opóźnienia sieci w celu "cięcia w kolejce" przed mniej poufnym ruchem.

Shortpath protokołu RDP można używać na dwa sposoby:

• W sieciach zarządzanych, w których jest ustanawiana bezpośrednia łączność między klientem a hostem sesji podczas korzystania z połączenia prywatnego, takiego jak połączenie usługi ExpressRoute lub sieć VPN.
• W sieciach publicznych, w których jest ustanawiana bezpośrednia łączność między klientem a hostem sesji podczas korzystania z połączenia publicznego. Przykładami połączeń publicznych są sieci domowe, sieci kawiarni i sieci hotelowe. Istnieją dwa możliwe typy połączeń podczas korzystania z połączenia publicznego:

  • Bezpośrednie połączenie UDP między klientem a hostem sesji używającym protokołu STUN.

  • Pośrednie połączenie UDP korzystające z protokołu TURN z przekaźnikiem między klientem RDP a hostem sesji. Ta opcja jest używana, jeśli brama lub router nie zezwala na bezpośrednie połączenia UDP.

    Uwaga

    Używanie protokołu RDP Shortpath dla sieci publicznych z funkcją TURN dla usługi Azure Virtual Desktop jest obecnie w wersji zapoznawczej. Aby uzyskać więcej informacji, zobacz RDP Shortpath for Azure Virtual Desktop (Krótka ścieżka protokołu RDP dla usługi Azure Virtual Desktop).

Ścieżka RDP 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, który jest oparty na protokole TCP. Wszystkie próby połączenia są ignorowane, chyba że są zgodne z pierwszą sesją połączenia odwrotnego.

Protokół RDP Shortpath, który jest oparty na protokole UDP, jest ustanawiany po uwierzytelnieniu. Jeśli ścieżka krótka protokołu RDP została pomyślnie ustanowiona, transport odwrotnego połączenia zostanie porzucony. Następnie cały ruch przepływa przez jedną z metod krótkiej ścieżki protokołu RDP, które wymieniono wcześniej w tej sekcji.

Aby uzyskać więcej informacji, zobacz Implementowanie jakości usług (QoS) dla usługi Azure Virtual Desktop.

Internet

Zasoby obliczeniowe i klienci usługi Azure Virtual Desktop wymagają dostępu do określonych publicznych punktów końcowych, więc potrzebują połączeń powiązanych z Internetem. Scenariusze sieciowe, takie jak wymuszone tunelowanie w celu zwiększenia bezpieczeństwa i filtrowania, są obsługiwane w przypadku spełnienia wymagań usługi Azure Virtual Desktop.

Aby zrozumieć wymagania dotyczące hostów sesji usługi Azure Virtual Desktop i urządzeń klienckich, zobacz Wymagane adresy URL dla usługi Azure Virtual Desktop.

Wymagania dotyczące portów i protokołów

Modele połączeń usługi Azure Virtual Desktop używają następujących portów i protokołów:

• Model standardowy: 443/TCP
• Model shortpath protokołu RDP: 443/TCP i 3390/UDP lub 3478/UDP dla protokołu STUN lub TURN

Ciągłość działania i odzyskiwanie po awarii

W przypadku ciągłości działania i odzyskiwania po awarii wymagana jest pewna konfiguracja sieci. W szczególności, aby wdrożyć i odzyskać zasoby w środowisku docelowym, użyj jednej z następujących konfiguracji:

• Konfiguracja sieci z tymi samymi możliwościami co sieć w środowisku źródłowym
• Konfiguracja sieci, która ma łączność z tożsamościami i usługami DNS

Następne kroki

Dowiedz się więcej o organizacji zasobów dla scenariusza w skali przedsiębiorstwa usługi Azure Virtual Desktop.

Organizacja zasobów