RDP Shortpath は、サポートされているプラットフォーム上のローカル デバイス Windows アプリ またはリモート デスクトップ アプリと、Azure Virtual Desktop のセッション ホストとの間で UDP ベースのトランスポートを確立します。 既定では、リモート デスクトップ プロトコル (RDP) は TCP ベースの逆引き接続トランスポートを開始し、UDP を使用してリモート セッションの確立を試行します。 UDP 接続が成功すると TCP 接続が切断され、それ以外の場合、TCP 接続はフォールバック接続メカニズムとして使用されます。
UDP ベースのトランスポートでは、接続の信頼性が向上し、待機時間の一貫性が向上します。 TCP ベースの逆引き接続トランスポートは、さまざまなネットワーク構成との互換性が最適であり、RDP 接続確立の成功率が高くなります。
RDP Shortpath には、次の 2 つの方法があります。
マネージド ネットワーク。Azure ExpressRoute やサイト間の仮想プライベート ネットワーク (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は、必要に応じて低遅延および損失レベルで動作します。
重要
-
Azure クラウド: STUN および TURN 経由のパブリック ネットワーク用の RDP Shortpath が一般提供になりました。
-
Azure cloud for Government: STUN および TURN 経由の RDP Shortpath は、**IP 範囲**20.140.236.0/22 の専用サーバーでパブリック プレビューで利用できます。 お客様は、検証リングでセッション ホストの機能を試すことができます。
主な利点
RDP Shortpath を使用すると、次の主な利点があります。
RDP Shortpath のしくみ
マネージド ネットワークとパブリック ネットワークで RDP Shortpath がどのように機能するかについては、次の各タブを選択します。
次の方法を使用して、マネージド ネットワークで RDP Shortpath を使用するために必要な直接見通し接続を実現できます。
見通し下で直接接続できるということは、クライアントがファイアウォールによってブロックされることなくセッション ホストに直接接続できることを意味します。
注:
他の種類の VPN を使用して Azure に接続する場合は、UDP ベースの VPN を使用することをお勧めします。 ほとんどの TCP ベースの VPN ソリューションでは入れ子になった UDP がサポートされますが、TCP の輻輳制御に継承されたオーバーヘッドが追加され、RDP のパフォーマンスが低下します。
マネージド ネットワークで RDP Shortpath を使用するには、セッション ホストで UDP リスナーを有効にする必要があります。 既定では、ポート 3390 が使用されますが、別のポートを使用することもできます。
次の図は、Active Directory ドメインに参加しているマネージド ネットワークおよびセッション ホストに RDP Shortpath を使用する場合のネットワーク接続の概要を示しています。
接続シーケンス
すべての接続は、Azure Virtual Desktop Gateway 経由で TCP ベースの逆引き接続トランスポートを確立することから始まります。 次に、クライアントとセッション ホストは最初の RDP トランスポートを確立し、機能の交換を開始します。 これらの機能は、次のプロセスを使用してネゴシエートされます。
セッション ホストは、IPv4 アドレスと IPv6 アドレスの一覧をクライアントに送信します。
クライアントはバックグラウンド スレッドを開始して、セッション ホストのいずれかの IP アドレスへの直接の並列 UDP ベースのトランスポートを確立します。
クライアントは、指定された IP アドレスをプローブしている間、ユーザー接続に遅延がないように、逆接続トランスポートを介して初期接続を確立し続けます。
クライアントがセッション ホストに直接接続している場合、クライアントは、信頼性の高い UDP 経由の TLS を使用してセキュリティで保護された接続を確立します。
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 ベースの逆引き接続トランスポートにフォール バックします。
接続が確立されると、Interactive Connectivity Establishment (ICE) が STUN と TURN の管理を調整して、接続が確立される可能性を最適化し、優先ネットワーク通信プロトコルが優先されるようにします。
各 RDP セッションは、RDP Shortpath トラフィックを受け入れるエフェメラル ポート範囲 (既定では 49152 から 65535) から動的に割り当てられた UDP ポートを使用します。 ポート 65330 は、Azure が内部的に使用するために予約されているため、この範囲からは無視されます。 さらに小さく予測可能なポート範囲を使用することもできます。 詳細については、「 パブリック ネットワークでクライアントが使用するポート範囲を制限する」を参照してください。
ヒント
パブリック ネットワークの RDP Shortpath は、ネットワークとファイアウォールがトラフィックの通過を許可し、セッション ホストとクライアントの Windows オペレーティング システムの RDP トランスポート設定が既定値を使用している場合に、追加の構成なしで自動的に機能します。
次の図は、セッション ホストが Microsoft Entra ID に参加したパブリック ネットワークで RDP Shortpath を使用する場合のネットワーク接続の概要を示しています。
TURN リレーの可用性
TURN リレーは、ACS TURN リレー (51.5.0.0/16) を使用する次の Azure リージョンで使用できます。
- オーストラリア中部
- オーストラリア東部
- オーストラリア南東部
- ブラジル南部
- カナダ中部
- カナダ東部
- インド中部
- 米国中部
- 米国東部
- 米国東部 2
- フランス中部
- ドイツ中西部
- イスラエル中部
- 東日本
- 西日本
- 韓国中部
- 韓国南部
- メキシコ中部
- 米国中央北部
- 北ヨーロッパ
- ノルウェー西部
- 南アフリカ北部
- 南アフリカ西部
- 米国中央南部
- 東南アジア
- インド南部
- スペイン中部
- スイス北部
- タウェイン北部
- タウェイン北東部
- アラブ首長国連邦中部
- アラブ首長国連邦北部
- 英国南部
- 英国西部
- 米国中央西部
- 西ヨーロッパ
- 米国西部
- 米国西部 2
- 米国西部 3
TURN リレーは、クライアント デバイスの物理的な場所に基づいて選択されます。 たとえば、クライアント デバイスが英国内にある場合、英国南部または英国西部地域の TURN リレーが選択されます。 クライアント デバイスが TURN リレーから遠く離れている場合、UDP 接続は TCP にフォール バックする可能性があります。
ネットワーク アドレス変換とファイアウォール
ほとんどの Azure Virtual Desktop クライアントは、プライベート ネットワーク上のコンピューターで実行されます。 インターネット アクセスは、ネットワーク アドレス変換 (NAT) ゲートウェイ デバイスを介して提供されます。 したがって、NAT ゲートウェイは、プライベート ネットワークからインターネット宛てのすべてのネットワーク要求を変更します。 このような変更は、プライベート ネットワーク上のすべてのコンピューターで単一のパブリック IP アドレスを共有することを目的としています。
IP パケットの変更により、トラフィックの受信者には、実際の送信者ではなく、NAT ゲートウェイのパブリック IP アドレスが表示されます。 トラフィックが NAT ゲートウェイに戻ってくると、送信者の知らないうちに目的の受信者に転送されます。 ほとんどのシナリオでは、このような NAT の背後に隠れているデバイスは変換が行われていることを認識せず、NAT ゲートウェイのネットワーク アドレスを認識しません。
NAT は、すべてのセッション ホストが存在する Azure 仮想ネットワークに適用されます。 セッション ホストがインターネット上のネットワーク アドレスに到達しようとすると、NAT ゲートウェイ (独自のゲートウェイまたは Azure によって提供される既定のゲートウェイ) または Azure Load Balancer によってアドレス変換が実行されます。 さまざまな種類のソース ネットワーク アドレス変換の詳細については、「 送信接続にソース ネットワーク アドレス変換 (SNAT) を使用する」を参照してください。
ほとんどのネットワークには通常、トラフィックを検査し、ルールに基づいてトラフィックをブロックするファイアウォールが含まれています。 ほとんどのお客様は、着信接続 (つまり、要求なしに送信されるインターネットからの未承諾のパケット) を防ぐためにファイアウォールを構成しています。 ファイアウォールは、要求されたトラフィックと未承諾のトラフィックを区別するために、データ フローを追跡するためにさまざまな手法を採用しています。 TCP のコンテキストでは、ファイアウォールは SYN パケットと ACK パケットを追跡しますが、プロセスは簡単です。 UDP ファイアウォールは通常、パケット アドレスに基づくヒューリスティックを使用して、トラフィックを UDP フローに関連付け、それを許可またはブロックします。 NAT 実装にはさまざまなものがあります。
接続シーケンス
すべての接続は、Azure Virtual Desktop Gateway 経由で TCP ベースの逆引き接続トランスポートを確立することから始まります。 次に、クライアントとセッション ホストは最初の RDP トランスポートを確立し、機能の交換を開始します。 セッション ホストでパブリック ネットワークの RDP Shortpath が有効になっている場合、セッション ホストは候補の収集と呼ばれるプロセスを開始します。
セッション ホストは、VPN や Teredo などの仮想インターフェイスを含め、セッション ホストに割り当てられているすべてのネットワーク インターフェイスを列挙します。
Windows サービス リモート デスクトップ サービス (TermService) は、各インターフェイスに UDP ソケットを割り当て、 IP:Port ペアを ローカル候補テーブルに格納します。
リモート デスクトップ サービス サービスは、前の手順で割り当てられた各 UDP ソケットを使用して、パブリック インターネット上の Azure 仮想デスクトップ STUN サーバーへの到達を試行します。 通信は、小さな UDP パケットをポート 3478 に送信することによって行われます。
パケットが STUN サーバーに到着すると、STUN サーバーはパブリック IP とポートを使用して応答します。 この情報は、 再帰候補として候補テーブルに格納されます。
セッション ホストがすべての候補を集めた後、セッション ホストは確立された逆引き接続トランスポートを使用して候補リストをクライアントに渡します。
クライアントは、セッション ホストから候補のリストを受け取ると、自身の側で候補の収集も実行します。 次に、クライアントはその候補リストをセッション ホストに送信します。
セッション ホストとクライアントが候補リストを交換した後、両者は収集されたすべての候補を使用して相互に接続を試みます。 この接続試行は両側で同時に行われます。 多くの NAT ゲートウェイは、送信データ転送が初期化されるとすぐにソケットへの着信トラフィックを許可するように構成されています。 NAT ゲートウェイのこの動作が、同時接続が不可欠な理由です。 ブロックされているために STUN が失敗した場合は、TURN を使用してリレー接続が試行されます。
最初のパケット交換の後、クライアントとセッション ホストは 1 つまたは複数のデータ フローを確立する場合があります。 これらのデータ フローから、RDP は最速のネットワーク パスを選択します。 その後、クライアントは、信頼できる UDP 経由の TLS を使用してセッション ホストとのセキュリティで保護された接続を確立し、RDP Shortpath トランスポートを開始します。
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 を使用して接続を成功させるための一般的な推奨事項がいくつかあります。 詳細については、「 一般的な推奨事項」を参照してください。
ユーザーがマネージド ネットワークとパブリック ネットワークの両方の RDP Shortpath を使用している場合は、最初に見つかったアルゴリズムが使用されます。 ユーザーは、そのセッションで最初に確立された接続を使用します。 詳細については、 サンプル シナリオを参照してください。
以下のセクションでは、RDP Shortpath が機能するために許可する必要があるセッション ホストとクライアント デバイスの送信元、宛先、プロトコルの要件を説明します。
注:
Microsoft は、以前に共有されていた 20.202.0.0/16 サブネットから、39 の Azure リージョンにわたる新しい 51.5.0.0/16 TURN リレー IP 範囲への移行を完了しました。 この新しい範囲は、Azure Virtual Desktop と Windows 365 専用であり、Azure Communication Services インフラストラクチャから分離されています。 このアップグレードは、公衆ネットワーク用の RDP Shortpath (TURN/リレー経由) を強化し、より高速で信頼性の高い接続と改善されたユーザー エクスペリエンスを提供するように設計されています。
注:
TURN ベースの接続は、 TURN リレーの更新中に接続が切断される可能性が高くなります。 これらの更新は通常、計画されたメンテナンス期間中に行われますが、緊急の Azure インフラストラクチャの修正のために、計画された期間外に発生することもあります。
上記のすべてのシナリオで、クライアントは数秒以内に自動的に再接続します。
セッション ホストの仮想ネットワーク
次の表は、セッション ホスト仮想ネットワークの RDP Shortpath の送信元、宛先、プロトコルの要件の詳細を示しています。
| 名前 |
ソース |
送信元ポート |
Destination (転送先) |
宛先ポート |
プロトコル |
アクション |
| STUN 直接接続 |
VM サブネット |
任意 |
任意 |
1024-65535 (デフォルト 49152-65535) |
UDP |
許可 |
| STUN/TURN リレー |
VM サブネット |
任意 |
51.5.0.0/16 |
3478 |
UDP |
許可 |
クライアント ネットワーク
次の表は、クライアント デバイスの送信元、宛先、プロトコルの要件の詳細を示しています。
| 名前 |
ソース |
送信元ポート |
Destination (転送先) |
宛先ポート |
プロトコル |
アクション |
| STUN 直接接続 |
クライアント ネットワーク |
任意 |
NAT ゲートウェイまたは Azure Firewall に割り当てられたパブリック IP アドレス (STUN エンドポイントによって提供) |
1024-65535 (デフォルト 49152-65535) |
UDP |
許可 |
| STUN/TURN リレー |
クライアント ネットワーク |
任意 |
51.5.0.0/16 |
3478 |
UDP |
許可 |
重要
Azure Government の専用 TURN リレー IP 範囲は 20.140.236.0/22 です。 TURN 経由の RDP Shortpath は現在、Azure Government でパブリック プレビュー段階にあります。 お客様は検証リングを使用してこの機能を試すことができます。
セッション ホストの仮想ネットワーク
次の表は、セッション ホスト仮想ネットワークの RDP Shortpath の送信元、宛先、プロトコルの要件の詳細を示しています。
| 名前 |
ソース |
送信元ポート |
Destination (転送先) |
宛先ポート |
プロトコル |
アクション |
| STUN 直接接続 |
VM サブネット |
任意 |
任意 |
1024-65535 (既定値: 49152-65535) |
UDP |
許可 |
| STUN/TURN リレー |
VM サブネット |
任意 |
20.140.236.0/22 |
3478 |
UDP |
許可 |
クライアント ネットワーク
次の表は、クライアント デバイスの送信元、宛先、プロトコルの要件の詳細を示しています。
| 名前 |
ソース |
送信元ポート |
Destination (転送先) |
宛先ポート |
プロトコル |
アクション |
| STUN 直接接続 |
クライアント ネットワーク |
任意 |
NAT ゲートウェイまたは Azure Firewall に割り当てられたパブリック IP アドレス (STUN エンドポイントによって提供) |
1024-65535 (既定値: 49152-65535) |
UDP |
許可 |
| STUN/TURN リレー |
クライアント ネットワーク |
任意 |
20.140.236.0/22 |
3478 |
UDP |
許可 |
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 を有効にします。
接続のセキュリティ
RDP Shortpath は、RDP のマルチトランスポート機能を拡張します。 これは、逆接続トランスポートに取って代わるものではなく、それを補完するものです。 初期セッション ブローカーは、Azure Virtual Desktop サービスとリバース接続トランスポートを通じて管理されます。 逆接続セッションと最初に一致しない限り、すべての接続試行は無視されます。 認証後に RDP Shortpath が確立され、正常に確立されると、逆に接続トランスポートが破棄され、すべてのトラフィックが RDP Shortpath 上を流れます。
RDP Shortpath は、クライアントとセッション ホストの証明書を使用するセッション ホスト間で、信頼性のある UDP 経由で TLS を使用するセキュリティで保護された接続を使用します。 既定では、RDP 暗号化に使用される証明書は、展開時にオペレーティング システムによって自動的に生成されます。 Azure Virtual Desktop では、現時点では証明機関から発行された証明書の使用はサポートされていません。
シナリオ例
ここでは、接続を評価して、異なるネットワーク トポロジ間で RDP Shortpath が使用されるかどうかを判断する方法を示すシナリオ例をいくつか紹介します。
シナリオ 1
UDP 接続は、パブリック ネットワーク (インターネット) 経由でのみクライアント デバイスとセッション ホストの間で確立できます。 VPN などの直接接続は利用できません。 UDP は、ファイアウォールまたは NAT デバイス経由で許可されます。
シナリオ 2
ファイアウォールまたは NAT デバイスがダイレクト UDP 接続をブロックしているが、パブリック ネットワーク (インターネット) 経由でクライアント デバイスとセッション ホストの間で TURN を使用してリレーされた UDP 接続を中継できる。 VPN などの別の直接接続は利用できません。
シナリオ 3
UDP 接続は、パブリック ネットワーク経由または直接 VPN 接続を介してクライアント デバイスとセッション ホストの間で確立できますが、マネージド ネットワークの RDP Shortpath は有効になっていません。 クライアントが接続を開始すると、ICE/STUN プロトコルは複数のルートを認識し、各ルートを評価して待機時間が最も短いルートを選択します。
この例では、直接 VPN 接続を介したパブリック ネットワークの RDP Shortpath を使用した UDP 接続は、緑色の線で示されているように待機時間が最も小さいため確立されます。
シナリオ 4
パブリック ネットワークとマネージド ネットワークの両方の RDP Shortpath が有効になっています。 UDP 接続は、パブリック ネットワーク経由または直接 VPN 接続を介して、クライアント デバイスとセッション ホストの間に確立できます。 クライアントが接続を開始すると、ポート 3390 (既定) を介したマネージド ネットワーク用の RDP Shortpath と、ICE/STUN プロトコルを介してパブリック ネットワーク用の RDP Shortpath を使用して接続する試行が同時に行われます。 最初に見つかったアルゴリズムが使用され、ユーザーはそのセッションで最初に確立された接続を使用します。
NAT デバイス、ロード バランサー、STUN サーバーなど、パブリック ネットワークを経由するにはより多くの手順が必要であるため、最初に検出されたアルゴリズムでは、管理対象ネットワークの RDP Shortpath を使用して接続が選択され、最初に確立される可能性があります。
シナリオ 5
UDP 接続は、パブリック ネットワーク経由または直接 VPN 接続を介してクライアント デバイスとセッション ホストの間で確立できますが、マネージド ネットワークの RDP Shortpath は有効になっていません。 ICE/STUN が特定のルートを使用できないようにするために、管理者は UDP トラフィックのルートの 1 つをブロックできます。 ルートをブロックすると、残りのパスが常に使用されます。
この例では、UDP は直接 VPN 接続でブロックされ、ICE/STUN プロトコルはパブリック ネットワーク経由で接続を確立します。
シナリオ 6
パブリック ネットワークとマネージド ネットワークの両方の RDP Shortpath が構成されていますが、直接 VPN 接続を使用して UDP 接続を確立できませんでした。 ファイアウォールまたは NAT デバイスもパブリック ネットワーク (インターネット) を使用した直接 UDP 接続をブロックしていますが、リレー UDP 接続は、パブリック ネットワーク (インターネット) 経由でクライアント デバイスとセッション ホストの間で TURN を使用して中継できます。
シナリオ 7
パブリック ネットワークとマネージド ネットワークの両方の RDP Shortpath が構成されていますが、UDP 接続を確立できませんでした。 この場合、RDP Shortpath は失敗し、接続は TCP ベースの逆引き接続トランスポートにフォール バックします。
次の手順