Azure Virtual Desktop の構築 (2) ネットワーク構成

Azure
この記事は約11分で読めます。

前回の記事で Azure Virtual Desktop（AVD）の構築に必要となる AVD の仮想マシンと利用するユーザーの ID について解説しましたが、今回は AVD を構築する際のネットワーク構成について解説します。

基本のネットワーク構成

前回の記事で解説した ID の構成で一番接続が複雑になるのは「①」の

  • オンプレミスのActive Directory と Entra ID を同期させる
  • 仮想マシンはオンプレミスのActive Directory に参加する
  • ユーザーはオンプレミスのActive Directory アカウントで仮想マシンにサインインする

というパターンです。

このパターンの場合、クライアントが AVD 仮想マシンを利用する際のネットワークの構成は以下のようになります。

表内の用語については以下をご覧ください。

  • AVD フィード サブスクリプション：クライアントが接続して利用可能なリモートデスクトップ ホストや RemoteApp の情報（フィード）を取得するための通信
  • リバース接続トランスポート：RDP トラフィックを伝送するための HTTPS 接続
  • RDP データ：RDP トラフィックのデータ

クライアントが利用する ID が機能するための通信は以下のようになります。

  1. オンプレミスの Active Directory は Entra ID Connect を利用して TCP 443 を通じて Entra ID と同期する
  2. AVD のセッション ホストは オンプレミスの Active Directory のドメイン コントローラーと通信してドメインに参加する
  3. クライアントは Entra ID と TCP 443 で認証を行うための通信を行う

クライアントが AVD のセッション ホストにリモートデスクトップ接続するための通信の流れは以下のようになります。

  1. クライアントは AVD のワークスペース（AVDに接続するための RD Web の URL）に TCP 443 でアクセスする
  2. AVD は Entra ID でユーザーを認証し、AVD フィードをクライアントに返す
  3. クライアントは受け取ったフィードの情報を元に RD ゲートウェイに TCP 443 でアクセスする
  4. クライアントからのアクセスは Azure Front Door で最適な RD ゲートウェイに振り分けられる
  5. RD ゲートウェイはクライアントからの接続要求を検証し、RD ブローカーに接続を調整するよう依頼する
  6. RD ブローカーは接続先のセッション ホストを識別して、セッション ホストと RD ゲートウェイを接続する
  7. クライアントとセッション ホストの両方が接続され、リバース接続トランスポート確立すると、RD ゲートウェイはデータのリレーを開始する
  8. クライアントからセッション ホストへの RDP 接続が確立する

この一連の通信にはすべて TLS 1.2 が使用されます。通常 RDP 接続はホストの証明書を使った暗号化が行われますが、TLS 1.2 で暗号化されたリバース接続トランスポートを利用した場合も、そのトランスポート内部で入れ子になった TLS 接続が行われます。

このように AVD へのアクセスはすべて TCP 443 番ポート上の TLS 1.2 で行われるため、ファイアウォールでインターネットへのトラフィックを制限しているようなネットワーク環境の場合、AVD に必要な URL への接続を許可すればセッション ホストへの接続が可能です。
※許可する URL については本記事の「ファイアウォール/プロキシ」の節を参照してください。

RDP Shortpath

上記の基本の構成の場合、RDP トラフィックはリバース接続トランスポート内で二重に暗号化された状態となり、またトラフィックが RD ゲートウェイで中継されるため、単純な RDP 接続に比べてレイテンシが高くなる場合があります。またトラフィックがパブリック インターネットを経由するため、QoS などのトラフィック制御を行うことができません。

こうした問題に対応するため、RDP Shortpath を利用することができます。

RDP Shortpath はクライアントとセッション ホストを（通常の RDP 接続と同様に）UDP で直接通信させる機能です。また UDP での接続はオンプレミス ネットワークと仮想ネットワーク間の閉域網接続を経由することも、パブリック インターネットを経由させることも可能です。

RDP Shortpath を利用すると以下のようなメリットがあります。

さらに閉域網接続で RDP Shortpath を利用すると、以下のメリットもあります。

  • DSCP を利用した QoS が利用できる
  • AVD へのネットワーク トラフィックに対するスロットリングが行える

RDP Shortpath を閉域網接続で利用した場合のネットワーク構成は以下のようになります。

閉域網接続の RDP Shortpath でクライアントが AVD のセッション ホストにリモートデスクトップ接続するための通信の流れは、途中のリバース接続トランスポートの確立までは基本の場合と同じです。その後、以下のように進行します。

  1. セッション ホストが自分の Pv4 と IPv6 のアドレスの一覧をクライアントに送信する
  2. クライアントは受け取った IP アドレスに対して UDP 3390 番ポートでのリモートデスクトップ接続を行う
  3. UDP での接続が成功したら、そのままリモートデスクトップ接続を行う
  4. UDP での接続ができない場合は、リバース接続トランスポートを経由したリモートデスクトップ接続を行う

パブリック インターネットを経由した RDP Shortpath のネットワーク構成は以下のようになります。

パブリック インターネット経由の RDP Shortpath でクライアントが AVD のセッション ホストにリモートデスクトップ接続するための通信の流れも、途中のリバース接続トランスポートの確立までは基本の場合と同じです。その後、以下のように進行します。

  1. クライアントとセッション ホストは Azure Virtual Desktop STUN サーバーを利用して相互接続を試みる。まず STUN での直接接続を試みて、接続できなければ TURN での間接接続を試みる
  2. UDP 接続が行えたら、TLS 1.2 で保護されたリモートデスクトップ接続を開始する
  3. 接続ができない場合は、リバース接続トランスポートを経由したリモートデスクトップ接続を行う

STUN/TURN はいずれも NAT やファイアウォール配下のクライアントがインターネット上のサーバーと直接通信するためのプロトコルです、詳しくは以下のページを参照してください。

パブリック インターネット経由の RDP Shortpath でのクライアントからセッション ホストへの UDP 接続は、エフェメラル ポート（49512～65535）が利用されます。何番のポート番号を使用するかは STUN/TURN でのホストとクライアントのネゴシエーションで決まるので、あらかじめ指定することはできません。

RDP ショートパスを有効にするには、セッション ホストの Windows でグループポリシーを構成します。構成方法については以下を参照してください。

Private Link

RDP Shortpath を構成することで AVD のセッション ホストへのリモートデスクトップ接続を VPN や Express Route などの閉域網接続経由にすることは可能ですが、AVD のインフラストラクチャー（RD ゲートウェイ・RD ブローカー・RD Web）は仮想ネットワーク内にデプロイすることができない PaaS のサービスであるため、閉域網接続から直接アクセスすることができません。

このような AVD インフラストラクチャーに閉域網接続からアクセスするには、Private Link を利用します。

Private Link は 仮想ネットワーク内のプライベート エンドポイント（IP アドレスが割り振られた特殊な仮想ネットワーク インターフェース）を通じて、Azure のバックボーン ネットワーク経由で（つまりパブリック インターネットを経由せず）PaaS のサービスに接続できる仕組みです。

Private Link を使用した AVD は、RD ゲートウェイ・RD ブローカー・RD Web などのインフラストラクチャーをインターネットに公開する必要がなくなるので、セキュリティを向上させることができます。

ただし現時点では Private Link と RDP Shortpath の併用はサポートされていません。

※閉域網接続を利用した RDP Shortpath と Private Link の併用はサポートされていませんが、動作自体は行えるため「ユーザーの自己責任で利用できる」と示されています。パブリック インターネット経由の RDP Shortpath は Private Link と併用できません（機能しない）。

詳細は以下を参照してください。

インフラストラクチャーとセッション ホストの両方に閉域網接続を行う必要がある場合は、Citrix Cloud with Azure Virtual Desktop の利用をご検討ください。

ファイアウォール/プロキシ

AVD のセッションホスト、AVD にアクセスするクライアント共に、ファイアウォールやプロキシでパブリック インターネットとの接続を制御したい場合があります。

この場合、AVD の利用に必要な接続先へのアウトバウンド接続は必ず許可してください。

  • セッション ホストの仮想マシンで AVD の動作に必要な接続先は「セッション ホスト仮想マシン」に記載されています。
    仮想マシンの接続先の制御にネットワーク セキュリティ グループ（NSG）または Azure Firewall を利用する場合は、サービス タグを利用することができます。
  • クライアント デバイスから AVD に接続してセッション ホストにアクセスするために必要な接続先は「エンド ユーザーのデバイス」に記載されています。
    特に既存のオンプレミス ネットワーク内にクライアントがある場合、オンプレミス ネットワークのファイアウォールで必要な接続先が許可されていることを確認してください。

詳しくは以下を参照してください。

また AVD へのトラフィックはプロキシ サーバーをバイパスすることが推奨されています。これは以下の理由によります。

  • AVD のトラフィックは常に暗号化されているため、プロキシによってセキュリティが強化されることはない
  • 多くのプロキシ サーバーは、AVD で利用されている長時間持続する複数の WebSocket がサポートされていない、またはスケーラビリティに問題が生じる場合がある

十分なスケールと機能を持つプロキシサーバーを経由する場合でも、以下の機能はサポートされません。

  • プロキシサーバーによる SSL ターミネーション（SSL インターセプト）
  • 認証を必要とするプロキシ

プロキシの利用について詳しくは、以下を参照してください。

オンプレミスへのアクセス

ネットワーク構成を検討する上でさらに必要なことは、セッション ホストの仮想マシンからオンプレミスのネットワーク内のリソース（ファイル共有、共有プリンター、データベース、アプリケーション）にアクセスする必要があるかどうかです。

アクセスが必要なオンプレミスのリソースが Web アプリケーションである場合は、Microsoft Entra アプリケーション プロキシを利用することができます。Microsoft Entra アプリケーション プロキシは Entra ID 認証を利用して、オンプレミスのアプリケーションへのリモート アクセスを提供するリバース プロキシとして機能します。

ファイル共有などのリソースへのアクセスが必要な場合は、Azure 仮想ネットワークとオンプレミスのネットワークを閉域網接続で接続する必要があります。またオンプレミスのリソースは通常 Active Directory ドメインでアクセス制御されていますので、セッション ホストも同じ Active Directory ドメインに参加させることをお勧めします（前回記事の「① のシナリオ」または「①´のシナリオ」）。

まとめ

前回の記事で AVD を利用するために必要となる ID のインフラストラクチャーで利用されるネットワーク構成を解説しました。今回は AVD 自体（AVD インフラストラクチャーとセッション ホスト）への接続に必要なネットワーク構成を解説しています。

これらの構成を検討し、実際に構築・利用するネットワーク構成を決定していきます。

この記事を書いた人

MurachiAkira
タイトルとURLをコピーしました