Azure Virtual Desktop の RDP Shortpath

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

• ExpressRoute プライベート ピアリング

• サイト間 VPN またはポイント対サイト VPN (IPsec) (Azure VPN Gateway など)

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

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

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

接続シーケンス

すべての接続は、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 の両方を使用できる場合は、最初に見つかったアルゴリズムが使用されます。 ユーザーは、そのセッションのために最初に確立された接続を使用します。

パブリック接続の使用時に 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 によりアドレス変換が実行されます。 さまざまな種類の送信元ネットワーク アドレス変換の詳細については、「送信接続での送信元ネットワーク アドレス変換 (SNAT)を使用する」を参照してください。

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

使用できるさまざまな NAT 実装があります。 ほとんどの場合、NAT ゲートウェイとファイアウォールは、同じ物理または仮想デバイスの機能です。

接続シーケンス

すべての接続は、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) が新しいトランスポートに移動されます。

ユーザーがマネージド ネットワーク用とパブリック ネットワーク用の RDP Shortpath の両方を使用できる場合は、最初に見つかったアルゴリズムが使用されます。つまり、ユーザーはそのセッションに対して最初に確立された接続を使用します。 詳細については、シナリオ例 4 を参照してください。

ネットワーク構成

パブリック ネットワーク用 RDP Shortpath をサポートするには、通常、特定の構成は必要ありません。 セッション ホストとクライアントにより、ネットワーク構成で可能であれば、直接データ フローが自動的に検出されます。 しかし、すべての環境は一意であり、一部のネットワーク構成は直接接続の成功率に悪影響を与える可能性があります。 直接データ フローの可能性を高めるには、推奨事項に従ってください。

RDP Shortpath では UDP を使用してデータ フローが確立されるため、ネットワーク上のファイアウォールにより UDP トラフィックがブロックされると、RDP Shortpath は失敗し、接続は TCP ベースの逆方向接続トランスポートにフォールバックされます。 Azure Virtual Desktop では、Azure Communication Services と Microsoft Teams によって提供される STUN サーバーが使用されます。 この機能の性質上、セッション ホストからクライアントへの送信接続が必要です。 残念ながら、ほとんどの場合、ユーザーがどこにいるかを予測することはできません。 そのため、セッション ホストからインターネットへの送信 UDP 接続を許可することをお勧めします。 必要なポートの数を減らすために、クライアントで UDP フローに使用されるポート範囲を制限できます。 RDP Shortpath 用のファイアウォールを構成する際には、次の表をリファレンスとして使用してください。

環境で対称 NAT (単一のプライベート ソース IP:Port を一意のパブリック宛先 IP:Port にマッピングしたもの) を使用する場合は、TURN との間接接続を使用できます。 これは、Azure Firewall と Azure NAT Gateway を使用する場合に当たります。 Azure 仮想ネットワークでの NAT の詳細については、仮想ネットワークでの送信元ネットワーク アドレス変換に関する記事を参照してください。

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

TURN の可用性

TURN は次の Azure リージョンで使用できます。

セッション ホスト仮想ネットワーク

クライアント ネットワーク

Teredo サポート

RDP Shortpath には必要ありませんが、Teredo ではさらに NAT トラバーサル候補が追加され、IPv4 のみのネットワークでの RDP Shortpath 接続の成功率が高まります。 セッション ホストとクライアントで Teredo を有効にする方法については、「Teredo のサポートを有効にする」を参照してください。

UPnP サポート

直接接続の可能性を高めるために、リモート デスクトップ クライアント側では、RDP Shortpath で UPnP を使用して NAT ルーター上のポート マッピングを構成できます。 UPnP は、Xbox、配信の最適化、Teredo など、さまざまなアプリケーションで使用される標準的なテクノロジです。 UPnP は、通常ホーム ネットワーク上にあるルーターで一般提供されています。 UPnP は、ほとんどのホーム ルーターとアクセス ポイントで既定で有効になっていますが、多くの場合、企業ネットワークでは無効になっています。

一般的な推奨事項

公衆ネットワークに RDP Shortpath を使用する場合の一般的な推奨事項を次に示します。

• ユーザーがインターネット経由で Azure Virtual Desktop にアクセスする場合は、強制トンネリング構成の使用を避けてください。

• ダブル NAT やキャリア グレード NAT (CGN) 構成を使用していないことを確認してください。

• ホーム ルーターで UPnP を無効にしないことをユーザーに推奨します。

• クラウド パケット検査サービスの使用は避けてください。

• TCP ベースの VPN ソリューションの使用を避けてください。

• IPv6 接続または Teredo を有効にしてください。