Azure Virtual Desktop の RDP Shortpath

完了

RDP Shortpath を使うと、ローカル デバイスの Windows アプリまたはサポートされているプラットフォーム上のリモート デスクトップ アプリと、Azure Virtual Desktop のセッション ホストとの間に UDP ベースの直接のトランスポートを確立できます。

既定では、リモート デスクトップ プロトコル (RDP) は UDP を使ってリモート セッションの確立を試み、フォールバック接続メカニズムとして TCP ベースのリバース接続トランスポートを使います。 UDP ベースのトランスポートにより、接続の信頼性と待ち時間の一貫性が向上します。 TCP ベースのリバース接続トランスポートでは、さまざまなネットワーク構成との最適な互換性が提供され、RDP 接続の確立が成功する確率が高くなります。

RDP Shortpath は、次の 2 つの方法で使用できます。

• マネージド ネットワーク: 仮想プライベート ネットワーク (VPN) などのプライベート接続を使用するときに、クライアントとセッション ホストの間で直接接続が確立されます。 マネージド ネットワークを使用した接続は、次のいずれかの方法で確立されます。

  • クライアント デバイスとセッション ホスト間の "直接" UDP 接続。RDP Shortpath リスナーを有効にし、各セッション ホストの受信ポートで接続を受け入れるようにする必要があります。
  • クライアントとセッション ホストの間で Simple Traversal Underneath NAT (STUN) プロトコルを使用するクライアント デバイスとセッション ホスト間の "直接" UDP 接続。 セッション ホスト上の受信ポートを許可する必要はありません。

• 公衆ネットワーク: パブリック接続を使うと、クライアントとセッション ホストの間で直接接続が確立されます。 パブリック接続には 2 つの種類があり、以下ではそれを優先順に示します。

  • クライアントとセッション ホストの間で Simple Traversal Underneath NAT (STUN) プロトコルを使用する "直接" UDP 接続。
  • クライアントとセッション ホストの間で Traversal Using Relay NAT (TURN) プロトコルとリレーを使用する "間接" UDP 接続。 これはプレビュー段階です。

RDP Shortpath に使用されるトランスポートは、Universal Rate Control Protocol (URCP) に基づいています。 URCP では、ネットワークの状態をアクティブに監視することで UDP を強化し、公平で完全なリンク使用率を実現します。 URCP は、必要に応じて低遅延および低損失レベルで動作します。

• プレビュー期間中、TURN は検証ホスト プール内のセッション ホストへの接続にのみ使用できます。 ホスト プールを検証環境として構成するには、検証環境としてホスト プールを定義する方法に関する記事を参照してください。
• TURN を使用したパブリック ネットワーク用 RDP Shortpath は、Azure パブリック クラウドでのみ使用できます。

主な利点

RDP Shortpath を使用することには、次の主な利点があります。

• URCP を使用して UDP を拡張すると、ネットワーク パラメーターを動的に学習し、レート制御メカニズムを備えたプロトコルを提供することにより、最高のパフォーマンスが達成されます。

• 余分なリレー ポイントを削除することでラウンド トリップ時間が短縮され、待機時間の影響を受けやすいアプリケーションと入力方式で接続の信頼性とユーザー エクスペリエンスが向上します。

• さらに、マネージド ネットワークの場合:

  • RDP Shortpath を使用すると、DSCP (Differentiated Services Code Point) マークを使用した RDP 接続に対するサービスの品質 (QoS) 優先度の構成がサポートされます。
  • RDP Shortpath トランスポートを使用して、各セッションのスロットル率を指定することで、送信ネットワーク トラフィックを制限することができます。

マネージド ネットワーク用 RDP Shortpath の仕組み

マネージド ネットワークで RDP Shortpath を使用するために必要な直接通信経路接続を実現するには、次の方法を使用できます。

• ExpressRoute プライベート ピアリング
• サイト間 VPN またはポイント対サイト VPN (IPsec) (Azure VPN Gateway など)

直接通信経路接続を持つことは、クライアントがファイアウォールにブロックされることなく、セッション ホストに直接接続できることを意味します。

注意

他の VPN の種類を使用して Azure に接続する場合は、UDP ベースの VPN を使用することをお勧めします。 ほとんどの TCP ベースの VPN ソリューションでは、入れ子になった UDP がサポートされていますが、TCP 輻輳制御の継承されたオーバーヘッドが追加されるため、RDP のパフォーマンスが低下します。

マネージド ネットワークに RDP Shortpath を使用するには、セッション ホストで UDP リスナーを有効にする必要があります。 既定では、ポート 3390 が使用されますが、別のポートを使用することもできます。

この図は、Active Directory ドメインに参加しているマネージド ネットワークとセッション ホストに RDP Shortpath を使用する場合のネットワーク接続の概要を示しています。

接続シーケンス

すべての接続は、Azure Virtual Desktop ゲートウェイ経由で TCP ベースの逆方向接続トランスポートを確立することによって開始されます。 その後、クライアントとセッション ホストで最初の RDP トランスポートが確立され、それらの機能の交換が開始されます。 これらの機能は、次のプロセスを使用してネゴシエートされます。

1. セッション ホストにより、IPv4 と IPv6 のアドレスの一覧がクライアントに送信されます。
2. クライアントでは、バックグラウンド スレッドが開始され、セッション ホストの IP アドレスの 1 つに対して、UDP ベースの並列トランスポートが直接確立されます。
3. クライアントでは、指定された IP アドレスを調査している間、逆方向接続トランスポートを介して初期接続の確立を続行し、ユーザー接続の遅延が発生しないようにします。
4. クライアントにセッション ホストへの直接接続がある場合は、クライアントによって信頼性の高い UDP 経由の TLS を使用した安全な接続が確立されます。
5. RDP Shortpath トランスポートを確立すると、リモート グラフィックス、入力、デバイス リダイレクトを含むすべての動的仮想チャネル (DVC) が新しいトランスポートに移動されます。 ただし、ファイアウォールまたはネットワーク トポロジにより、クライアントで直接 UDP 接続を確立できない場合、RDP では逆方向接続トランスポートを続行します。

ユーザーがマネージド ネットワーク用とパブリック ネットワーク用の RDP Shortpath の両方を使用できる場合は、最初に見つかったアルゴリズムが使用されます。 ユーザーは、そのセッションのために最初に確立された接続を使用します。

パブリック ネットワーク用 RDP Shortpath のしくみ

パブリック接続の使用時に UDP 接続が成功する可能性を最大限に高めるため、"直接" と "間接" の接続の種類があります。

• 直接接続: クライアントとセッション ホスト間の直接 UDP 接続を確立するには、STUN が使われます。 この接続を確立するには、クライアントとセッション ホストが、パブリック IP アドレスとネゴシエートされたポートを介して相互に接続できる必要があります。 ただし、ほとんどのクライアントは、ネットワーク アドレス変換 (NAT) ゲートウェイ デバイスの内側に配置されているため、自分のパブリック IP アドレスを知りません。 STUN は、NAT ゲートウェイ デバイスの内側からパブリック IP アドレスを自己検出するためのプロトコルであり、クライアントが自分の公開 IP アドレスを確認できます。

  クライアントが STUN を使うには、そのネットワークで UDP トラフィックが許可されている必要があります。 クライアント ホストとセッション ホストの両方が、検出された他の IP アドレスとポートに直接ルーティングできるとすると、WebSocket プロトコル経由で直接 UDP を使って通信が確立されます。 ファイアウォールまたは他のネットワーク デバイスが直接接続をブロックしている場合は、間接 UDP 接続が試行されます。

• 間接接続: 直接接続が使用できない場合に、クライアントとセッション ホストの間の中間サーバー経由でトラフィックを中継して、間接接続を確立するには、TURN が使われます。 TURN は STUN の拡張機能です。 TURN を使うということは、パブリック IP アドレスとポートが事前にわかっていることを意味し、これはファイアウォールや他のネットワーク デバイスを使って実現できます。

  TURN は通常、ユーザー名とパスワードを使ってサーバーへのアクセスを承認し、その優先される動作モードは UDP ソケットを使用することです。 ファイアウォールまたは他のネットワーク デバイスで UDP トラフィックがブロックされている場合、接続は TCP ベースのリバース接続トランスポートにフォールバックします。

接続の確立時には、対話型接続確立 (ICE) によって STUN と TURN の管理が調整されて、接続が確立される可能性が最適化され、優先されるネットワーク通信プロトコルが確実に優先されます。

各 RDP セッションでは、RDP Shortpath トラフィックを受け入れる一時的なポート範囲 (既定では 49152 - 65535) から動的に割り当てられた UDP ポートが使用されます。 ポート 65330 は、Azure による内部的な使用のために予約されているので、この範囲からは無視されます。 より小さい予測可能なポート範囲を使用することもできます。 詳細については、公衆ネットワークでクライアントによって使用されるポート範囲の制限に関する記事を参照してください。

この図は、セッション ホストが Microsoft Entra ID に参加しているパブリック ネットワークに RDP Shortpath を使用する場合のネットワーク接続の概要を示しています。

ネットワーク アドレス変換とファイアウォール

ほとんどの Azure Virtual Desktop クライアントは、プライベート ネットワーク上のコンピューターで実行されます。 インターネット アクセスは、ネットワーク アドレス変換 (NAT) ゲートウェイ デバイスを介して提供されます。 そのため、NAT ゲートウェイにより、プライベート ネットワークからインターネット宛てのすべてのネットワーク要求が変更されます。 このような変更は、プライベート ネットワーク上のすべてのコンピューターで 1 つのパブリック IP アドレスを共有することを意図しています。

IP パケットの変更により、トラフィックの受信者には、実際の送信者ではなく NAT ゲートウェイのパブリック IP アドレスが表示されます。 トラフィックが NAT ゲートウェイに戻ったら、送信者に気付かれずに目的の受信者に転送するように注意します。 ほとんどのシナリオでは、このような NAT の背後に隠れているデバイスで、変換が行われているのが認識されず、NAT ゲートウェイのネットワーク アドレスがわかりません。

NAT は、すべてのセッション ホストが存在する Azure Virtual Networks に適用されます。 セッション ホストがインターネット上のネットワーク アドレスに到達しようとすると、(独自または Azure によって提供される既定の) NAT Gateway または Azure Load Balancer によりアドレス変換が実行されます。

通常、ほとんどのネットワークには、トラフィックを検査し、ルールに基づいてブロックするファイアウォールが含まれています。 ほとんどのお客様は、受信接続 (つまり、要求なしで送信されるインターネットからの要請されていないパケット) を防ぐためにファイアウォールを構成します。 ファイアウォールでは、要請されたトラフィックと要請されていないトラフィックを区別するために、さまざまな手法を使用してデータ フローを追跡します。 TCP のコンテキストでは、ファイアウォールにより SYN および ACK パケットが追跡され、そのプロセスは簡単です。 UDP ファイアウォールでは通常、パケット アドレスに基づくヒューリスティックを使用して、トラフィックを UDP フローに関連付け、許可またはブロックします。

接続シーケンス

すべての接続は、Azure Virtual Desktop ゲートウェイ経由で TCP ベースの逆方向接続トランスポートを確立することによって開始されます。 その後、クライアントとセッション ホストで最初の RDP トランスポートが確立され、それらの機能の交換が開始されます。 公衆ネットワーク用の RDP Shortpath がセッション ホストで有効になっている場合、セッション ホストにより "候補収集" というプロセスが開始されます。

1. セッション ホストで、VPN や Teredo などの仮想インターフェイスを含め、セッション ホストに割り当てられているすべてのネットワーク インターフェイスが列挙されます。
2. Windows サービスの "リモート デスクトップ サービス" (TermService) では、各インターフェイスに UDP ソケットを割り当て、IP:Port ペアを "ローカル候補" として候補テーブルに格納します。
3. リモート デスクトップ サービスでは、前の手順で割り当てた各 UDP ソケットを使用して、パブリック インターネット上の Azure Virtual Desktop STUN サーバーに到達しようとします。 通信は、ポート 3478 に小さな UDP パケットを送信することによって行われます。
4. パケットが STUN サーバーに到達すると、STUN サーバーはパブリック IP とポートで応答します。 この情報は、''再帰候補'' として候補テーブルに格納されます。
5. セッション ホストですべての候補が収集された後、セッション ホストでは確立された逆方向接続トランスポートを使用して、候補リストをクライアントに渡します。
6. クライアントでは、セッション ホストから候補リストを受け取ると、クライアント側で候補の収集も実行します。 その後、クライアントはその候補リストをセッション ホストに送信します。
7. セッション ホストとクライアントが候補リストを交換した後、両者は収集されたすべての候補を使用して相互に接続しようとします。 この接続試行は両側で同時に行われます。 NAT ゲートウェイの多くは、送信データ転送によってソケットが初期化されるとすぐに、そのソケットへの受信トラフィックを許可するように構成されます。 NAT ゲートウェイのこの動作が、同時接続が不可欠な理由です。 ブロックされたために STUN が失敗した場合は、TURN を使って間接接続が試みられます。
8. 最初のパケット交換の後、クライアントとセッション ホストは 1 つまたは複数のデータ フローを確立できます。 これらのデータ フローから、RDP によって最速のネットワーク パスが選択されます。 次に、クライアントでセッション ホストとの間で信頼性の高い UDP 経由の TSL を使用したセキュリティ保護された接続が確立され、RDP Shortpath トランスポートが開始されます。
9. RDP で RDP Shortpath トランスポートが確立された後、リモート グラフィックス、入力、デバイス リダイレクトを含むすべての動的仮想チャネル (DVC) が新しいトランスポートに移動されます。