Krótka ścieżka protokołu RDP dla przykładowych scenariuszy usługi Azure Virtual Desktop
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 zostanie nawiązane połączenie UDP z protokołem RDP Shortpath dla sieci publicznych za pośrednictwem bezpośredniego połączenia sieci VPN, 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. Pierwszy znaleziony algorytm jest używany do i użytkownik będzie używać 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.
