Azure Virtual Desktop のプロキシ サーバーのガイドライン

この記事では、Azure Virtual Desktop でプロキシ サーバーを使用する方法について説明します。 この記事の推奨事項は、Azure Virtual Desktop インフラストラクチャ、クライアント、セッション ホスト エージェント間の接続にのみ適用されます。 この記事では、Office、Windows 10、FSLogix、またはその他の Microsoft アプリケーションのネットワーク接続については説明しません。

プロキシ サーバーとは

Azure Virtual Desktop トラフィックのプロキシをバイパスすることをお勧めします。 トラフィックは既に暗号化されているため、プロキシでは Azure Virtual Desktop のセキュリティが強化されません。 接続セキュリティの詳細については、「 接続セキュリティ」を参照してください。

ほとんどのプロキシ サーバーは、実行時間の長い WebSocket 接続をサポートするように設計されていないため、接続の安定性に影響する可能性があります。 Azure Virtual Desktop では複数の長期的な接続が使用されるため、プロキシ サーバーのスケーラビリティも問題を引き起こします。 プロキシ サーバーを使用する場合は、これらの接続を実行するために適切なサイズである必要があります。

プロキシ サーバーの地域がホストから遠い場合、この距離により、ユーザー接続の待機時間が長くなります。 待機時間が長いほど、特にグラフィックス、オーディオ、または入力デバイスとの待機時間の短い対話が必要なシナリオでは、接続時間が遅くなり、ユーザー エクスペリエンスが低下します。 プロキシ サーバーを使用する必要がある場合は、Azure Virtual Desktop エージェントとクライアントと同じ地域にサーバーを配置する必要があることに注意してください。

Azure Virtual Desktop トラフィックの唯一のパスとしてプロキシ サーバーを構成した場合、リモート デスクトップ プロトコル (RDP) データは、ユーザー データグラム プロトコル (UDP) ではなく伝送制御プロトコル (TCP) 経由で強制されます。 この移動により、リモート接続の視覚的品質と応答性が低下します。

要約すると、待機時間の低下やパケット損失によってパフォーマンス関連の問題が発生するため、Azure Virtual Desktop でプロキシ サーバーを使用することはお勧めしません。

プロキシ サーバーのバイパス

organizationのネットワークおよびセキュリティ ポリシーで Web トラフィックにプロキシ サーバーが必要な場合は、プロキシ サーバー経由でトラフィックをルーティングしながら、Azure Virtual Desktop 接続をバイパスするように環境を構成できます。 ただし、各organizationのポリシーは一意であるため、一部の方法は、他の方法よりもデプロイに適している場合があります。 環境内のパフォーマンスと信頼性の損失を防ぐために試みることができるいくつかの構成方法を次に示します。

• Azure Firewallを含む Azure サービス タグ
• プロキシ自動構成 (.PAC) ファイルを使用してプロキシ サーバーをバイパスする
• ローカル プロキシ構成のバイパス リスト
• ユーザーごとの構成にプロキシ サーバーを使用する
• プロキシ経由でサービス トラフィックを維持しながら RDP 接続に RDP Shortpath を使用する

プロキシ サーバーを使用するための推奨事項

一部の組織では、追跡またはパケット検査のために、すべてのユーザー トラフィックがプロキシ サーバーを経由する必要があります。 このセクションでは、このような場合に環境を構成する方法について説明します。

同じ Azure 地域でプロキシ サーバーを使用する

プロキシ サーバーを使用すると、Azure Virtual Desktop インフラストラクチャとの通信がすべて処理され、最も近い Azure Front Door への DNS 解決と Anycast ルーティングが実行されます。 プロキシ サーバーが離れているか、Azure 地域全体に分散されている場合、地理的な解決の精度は低下します。 地理的解決の精度が低いということは、接続がより遠い Azure Virtual Desktop クラスターにルーティングされることを意味します。 この問題を回避するには、Azure Virtual Desktop クラスターに地理的に近いプロキシ サーバーのみを使用します。

デスクトップ接続にマネージド ネットワークに RDP Shortpath を使用する

マネージド ネットワークに対して RDP Shortpath を有効にすると、可能であれば RDP データによってプロキシ サーバーがバイパスされます。 プロキシ サーバーをバイパスすると、UDP トランスポートの使用中に最適なルーティングが保証されます。 ブローカー、オーケストレーション、診断など、他の Azure Virtual Desktop トラフィックは引き続きプロキシ サーバーを経由します。

プロキシ サーバーで SSL 終了を使用しない

Secure Sockets Layer (SSL) の終了は、Azure Virtual Desktop コンポーネントのセキュリティ証明書をプロキシ サーバーによって生成された証明書に置き換えます。 このプロキシ サーバー機能により、プロキシ サーバー上の HTTPS トラフィックのパケット検査が可能になります。 ただし、パケット検査によってサービスの応答時間も長くなり、ユーザーのサインインに時間がかかります。 逆接続のシナリオでは、RDP トラフィックのパケット検査は必要ありません。逆接続 RDP トラフィックはバイナリであり、追加のレベルの暗号化が使用されるためです。

SSL 検査を使用するようにプロキシ サーバーを構成する場合は、SSL 検査が変更された後にサーバーを元の状態に戻すことはできません。 SSL 検査を有効にしている間に Azure Virtual Desktop 環境の何かが機能しなくなった場合は、サポート ケースを開く前に SSL 検査を無効にしてから、もう一度やり直す必要があります。 SSL 検査により、Azure Virtual Desktop エージェントは、エージェントとサービス間の信頼された接続に干渉するため、動作を停止する可能性もあります。

認証が必要なプロキシ サーバーを使用しない

セッション ホスト上の Azure Virtual Desktop コンポーネントはオペレーティング システムのコンテキストで実行されるため、認証を必要とするプロキシ サーバーはサポートされません。 プロキシ サーバーで認証が必要な場合、接続は失敗します。

プロキシ サーバーのネットワーク容量を計画する

プロキシ サーバーには容量制限があります。 通常の HTTP トラフィックとは異なり、RDP トラフィックの実行時間が長く、双方向で多くの帯域幅を消費するおしゃべりな接続があります。 プロキシ サーバーを設定する前に、サーバーのスループットについてプロキシ サーバー ベンダーに問い合わせてください。 また、一度に実行できるプロキシ セッションの数を確認してください。 プロキシ サーバーをデプロイした後、Azure Virtual Desktop トラフィックのボトルネックに対するリソースの使用を注意深く監視します。

プロキシ サーバーとMicrosoft Teamsメディアの最適化

Azure Virtual Desktop では、 Microsoft Teamsのメディア最適化を使用したプロキシ サーバーはサポートされていません。

セッション ホストの構成に関する推奨事項

セッション ホスト レベルのプロキシ サーバーを構成するには、システム全体のプロキシを有効にする必要があります。 システム全体の構成は、セッション ホストで実行されているすべての OS コンポーネントとアプリケーションに影響を与える点に注意してください。 次のセクションでは、システム全体のプロキシを構成するための推奨事項を示します。

Web プロキシ自動検出 (WPAD) プロトコルを使用する

Azure Virtual Desktop エージェントは、Web プロキシ自動検出 (WPAD) プロトコルを使用して、ネットワーク上のプロキシ サーバーの検索を自動的に試行します。 場所の試行中に、エージェントはドメイン ネーム サーバー (DNS) で wpad.domainsuffix という名前のファイルを検索します。 エージェントが DNS でファイルを検出すると、 wpad.dat という名前のファイルに対して HTTP 要求が行われます。 応答は、送信プロキシ サーバーを選択するプロキシ構成スクリプトになります。

WPAD の DNS 解決を使用するようにネットワークを構成するには、「自動検出設定インターネット エクスプローラー 11」の手順に従います。 Set-DnsServerGlobalQueryBlockList の指示に従って、DNS サーバーのグローバル クエリ ブロックリストで WPAD 解決が許可されていることを確認します。

Windows サービスのデバイス全体のプロキシを手動で設定する

プロキシ サーバーを手動で指定する場合は、少なくともセッション ホスト上の Windows サービス RDAgent と リモート デスクトップ サービス のプロキシを設定する必要があります。 RDAgent はアカウントの ローカル システム で実行され、リモート デスクトップ サービスはアカウント ネットワーク サービスで実行されます。 これらのアカウントのプロキシは、 bitsadmin コマンド ライン ツールを使用して設定できます。

次の例では、プロキシ .pac ファイルを使用するようにローカル システム アカウントとネットワーク サービス アカウントを構成します。 管理者特権のコマンド プロンプトからこれらのコマンドを実行し、独自のアドレスで <server> のプレースホルダー値を変更する必要があります。

bitsadmin /util /setieproxy LOCALSYSTEM AUTOSCRIPT http://<server>/proxy.pac
bitsadmin /util /setieproxy NETWORKSERVICE AUTOSCRIPT http://<server>/proxy.pac

完全なリファレンスとその他の例については、 bitsadmin util と setieproxy に関するページを参照してください。

デバイス全体のプロキシまたはプロキシの自動構成 (を設定することもできます。PAC) ファイル。対話型、ローカル システム、ネットワーク サービスのすべてのユーザーに適用されます。 セッション ホストが Intune に登録されている場合は、 ネットワーク プロキシ CSP でプロキシを設定できますが、Windows マルチセッション クライアント オペレーティング システムでは 、設定カタログのみがサポートされるため、ポリシー CSP はサポートされません。 または、 netsh winhttp コマンドを使用してデバイス全体のプロキシを構成することもできます。 完全なリファレンスと例については、「Windows Hypertext Transfer Protocol (WINHTTP) の Netsh コマンド」を参照してください。

クライアント側プロキシのサポート

Azure Virtual Desktop クライアントは、システム設定または ネットワーク プロキシ CSP で構成されたプロキシ サーバーをサポートします。

Azure Virtual Desktop クライアントのサポート

次の表は、プロキシ サーバーをサポートする Azure Virtual Desktop クライアントを示しています。

Linux ベースのシン クライアントでのプロキシサポートの詳細については、「 シン クライアントのサポート」を参照してください。

サポートの制限事項

プロキシ サーバーとして機能するサード パーティのサービスとアプリケーションは多数あります。 これらのサード パーティのサービスには、分散型次世代ファイアウォール、Web セキュリティ システム、および基本的なプロキシ サーバーが含まれます。 すべての構成が Azure Virtual Desktop と互換性があることを保証することはできません。 Microsoft では、プロキシ サーバー経由で確立された接続のサポートが制限されています。 プロキシ サーバーの使用中に接続の問題が発生している場合は、プロキシ バイパスを構成してから問題を再現することをお勧めします。

次の手順

Azure Virtual Desktop のデプロイをセキュリティで保護する方法の詳細については、セキュリティ ガイドをチェックしてください。