Azure Virtual Desktop の RDP Shortpath

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

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

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

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

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

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

接続シーケンス

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

1. セッション ホストは、IPv4 アドレスと IPv6 アドレスの一覧をクライアントに送信します。

2. クライアントはバックグラウンド スレッドを開始し、セッション ホストの IP アドレスのいずれかに対して直接、並列 UDP ベースのトランスポートを確立します。

3. クライアントは指定された IP アドレスをプローブしていますが、ユーザー接続に遅延が生じないように、リバース接続トランスポート経由で初期接続を確立し続けます。

4. クライアントがセッション ホストに直接接続している場合、クライアントは信頼できる UDP 経由で TLS を使用してセキュリティで保護された接続を確立します。

5. RDP Shortpath トランスポートを確立すると、リモート グラフィックス、入力、デバイス リダイレクトを含むすべての動的仮想チャネル (DVC) が新しいトランスポートに移動されます。 ただし、ファイアウォールまたはネットワーク トポロジによってクライアントが直接 UDP 接続を確立できなくなる場合、RDP は逆接続トランスポートで続行されます。

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

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

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

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

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

  ファイアウォールまたはその他のネットワーク デバイスが UDP トラフィックをブロックする場合、接続は TCP ベースの逆接続トランスポートにフォールバックします。

接続が確立されている場合、対話型接続確立 (ICE) は STUN と TURN の管理を調整して、接続が確立される可能性を最適化し、優先するネットワーク通信プロトコルに優先順位が与えられていることを確認します。

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

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

TURN リレーの可用性

TURN リレーは、ACS TURN Relay (20.202.0.0/16) を使用して、次の Azure リージョンで使用できます。

TURN リレーは、クライアント デバイスの物理的な場所に基づいて選択されます。 たとえば、クライアント デバイスが英国にある場合、英国南部または英国西部リージョンの TURN リレーが選択されます。 クライアント デバイスが TURN リレーから遠い場合、UDP 接続が TCP にフォールバックする可能性があります。

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

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

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

NAT は、すべてのセッション ホストが存在する Azure Virtual Networks に適用されます。 セッション ホストがインターネット上のネットワーク アドレスに到達しようとすると、NAT ゲートウェイ (Azure によって提供される独自または既定のいずれか) またはAzure Load Balancerがアドレス変換を実行します。 さまざまな種類の送信元ネットワーク アドレス変換の詳細については、「 送信接続にソース ネットワーク アドレス変換 (SNAT) を使用する」を参照してください。

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

接続シーケンス

すべての接続は、まず、Azure Virtual Desktop Gateway 経由で 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 経由で TLS を使用してセキュリティで保護された接続を確立し、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 のファイアウォールを構成する場合は、次の表を参考にしてください。

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

パブリック ネットワーク用の RDP Shortpath を使用した接続の成功に関する一般的な推奨事項がいくつかあります。 詳細については、「 一般的な推奨事項」を参照してください。

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

次のセクションには、RDP Shortpath を機能させるために許可する必要があるセッション ホストとクライアント デバイスのソース、宛先、プロトコルの要件が含まれています。

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

次の表では、セッション ホスト仮想ネットワークの RDP Shortpath のソース、宛先、プロトコルの要件について詳しくは、次の表をご覧ください。

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

次の表では、クライアント デバイスのソース、宛先、プロトコルの要件について詳しくは、次の表をご覧ください。

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 にアクセスする場合は、強制トンネリング構成を使用しないでください。

• double NAT または Carrier-Grade-NAT (CGN) 構成を使用していないことを確認します。

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

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

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

• IPv6 接続またはTeredoを有効にします。