AVD for Azure Stack HCI の AVD に関する Azure リソース は 通常の AVD と同様のリソース構成 (ホス トプール / アプリケーション グループ / ワークスペース) となっており、使用するセッションホストが Azure VM ではなく、Arc VM 管理で展開された仮想マシンとなっています。
AVD for Azure Stack HCI は、現時点では AVD のすべての機能は提供されておらず 制限事項 に記載されている機能制限があるのですが、この記載にはプライベートエンドポイントについての記載はなかったため、使用することができるかを検証してみました。
AVD のクライアントとして使用している環境は、次の内容となっています。
- Azure Stack HCI と同一のドメインに参加しており、DNS は AD の DNS を参照
- クライアントから Azure でプライベートエンドポイントを作成した VNET には VPN 経由でアクセスが可能
本検証で使用した、AVD のパブリックアクセスの設定は次のようになっており、プライベートエンドポイント接続を作成した環境となっています。(ホストプールについては「パブリックアクセスを無効にし、プライベートアクセスを使用する」の設定でも動作しました) 
Contents
参考情報の整理
プライべードエンドポイントを使用するに際して、AVD のプライベートエンドポイントの機能が把握できていなかったため、最初に AVD の Private Endpoint の情報を確認してみました。
AVD の Private Link の設定について
AVD の Private Link の設定と基本的な動作については、次のドキュメントが参考となりました。
DNS の設定について
プライベートエンドポイントを使用する場合、DNS による名前解決の設定が重要となります。DNS の設定については次のドキュメントが参考になりました。
- Azure プライベート エンドポイントの DNS 統合
- Azure portal を使用してプライベート エンドポイントの DNS レコードをエクスポートする
- Azure Private Endpoint のための DNS 構成パターン
基本となる情報は Azure VM として構築したセッションホストのものとなりますので、Azure VM でどのようにして名前解決が行われるかについても、以下の情報から改めて確認をしました。
オンプレミスの DNS の設定
AVD for Azure Stack HCI はセッションホストがオンプレミスの HCI 上に作成されるため、プライべードエンドポイント向けの DNS 設定は Azure 上ではなく、AD 上で実施するケースもあるのではないかと考えています。
AD の DNS に AVD の Private Endpoint 向けの設定を行う際には次の記事が参考となりました。
- Configuring Private links for Azure Virtual Desktop ? Part 1 Private Endpoint for Host Pools
- Configuring Private links for Azure Virtual Desktop ? Part 2 Private Endpoint for Feed discovery and Feed Download
「privatelink.wvd.microsoft.com」を解決できるゾーンを AD の DNS に作成し、その中に必要となる DNS レコードを作成するという内容となっています。
オンプレミス DNS フォワーダーを使用した Azure プライベート リゾルバー には次の記載があります。
条件付き転送は、推奨されるパブリック DNS ゾーン フォワーダーに対して行われる必要があります。 たとえば、 privatelink.database.windows.net ではなく、
database.windows.netです。
オンプレミスの DNS でプライベートエンドポイントの名前解決をする場合、「wvd.microsoft.com」の名前解決を Azure 内の DNS で解決できるようにするのが推奨される設定となっていますが、今回はオンプレミスの環境で完結させたいため「privatelink.wvd.microsoft.com」を AD の DNS 内で解決しています。
パブリック DNS ゾーンの転送が推奨される理由 でプライベートエンドポイントを検証した結果が公開されていますが、名前解決の挙動が安定しない場合は Azure 側の DNS に転送することも考慮したほうが良いかもしれませんね。
また、現在のオンプレミスの DNS と Azure の統合については、 Azure プライベート エンドポイントの DNS 統合 で記載されていますが、Azure プライベートリゾルバーを使用した構成となっています。
Azure 内の DNS フォワーダー用の VM を使用した構成については Github 上の 過去のドキュメント から確認する必要があります。
AVD for Azure Stack HCI 向けのプライベートエンドポイントの設定
本題の AVD for Azure Stack HCI 向けのプライべードエンドポイントの設定についてまとめておきます。
AVD for Azure Stack HCI のプライベートエンドポイントについては、通常の AVD の設定と同様に「ホストプール」「ワークスペース」の「ネットワーク」から、
- パブリックアクセスの設定の公衆ネットワークアクセスを設定
- プライベートエンドポイント接続の設定
を該当のリソースに対してのエンドポイントを、指定した VNET のサブネットに作成を行います。
プライベートエンドポイントの設定
プライべードエンドポイントの設定については通常の AVD と同様でした。
- 「ホストプール」の「ネットワーク」のパブリックアクセス / プライベートエンドポイント接続を設定
(最初の検証としては、下の画像の設定で実施しましたが、正しく設定ができていれば「パブリックアクセスを無効にし、プライベートアクセスを使用する」の設定でも接続することが可能でした)
- 「ワークスペース」の「ネットワーク」のパブリックアクセス / プライベートエンドポイント接続を設定
「ホストプール」の公衆ネットワークアクセスの設定としては以下の二種類があり、設定の違いについては ホスト プール に記載されています。
- エンド ユーザーのパブリック アクセスを有効にし、セッション ホストにプライベート アクセスを使用する
- パブリック アクセスを無効にし、プライベート アクセスを使用する
エンドユーザーからのアクセスについてはパブリックアクセスを使用し、AVD の内部的な通信についてはプライベートエンドポイントを使用する場合は「1.」を使用し、エンドユーザーからのアクセスについてもプライべードエンドポイントを使用する場合は「2.」を使用することになるのではないでしょうか。
オンプレミスとプライベートエンドポイントを展開した VNET との接続
プライベートエンドポイントを作成したエンドポイントの VNET に対して、HCI 上のセッションホストと AVD に接続をするクライアントからのネットワーク接続を確保した状態にしておきます。
今回はオンプレミスのネットワークと Azure の VNET が VPN で接続された状態としています。
接続の簡略化のためハブスポーク構成にはしておらず、オンプレミスとプライベートエンドポイントを展開した VNET ハブサイトを介さずに直接接続された状態としています。
DNS の設定
AVD を使用する場合、Azure VM をセッションホストとして使用し、その環境にオンプレミスから接続することが多いかと。
この場合、DNS としては オンプレミス DNS フォワーダーを使用した Azure プライベート リゾルバー の構成を使用した、次のような設定となるのではないでしょうか。
- VNET に統合された DNS を使用し、プライベートエンドポイントのプライベート DNS ゾーンを該当の VNET に仮想ネットワークリンクでリンクさせる
- Azure プライベートリゾルバーを使用して AD の DNS の条件付きフォワーダーで、Azure 側の DNS で 「wvd.microsoft.com」を解決するようにする (「privatelink.wvd.microsoft.com」の条件付きフォワーダーでも対応できるかもしれませんが)
Azure で AVD を構築した場合は、セッションホストがプライベートエンドポイント向けの DNS レコードを解決する必要があるため、Azure 内で DNS を構成することになるのではないでしょうか。
しかし、AVD for Azure Stack HCI については Azure にリソースは作成されますが、Azure の VNET にセッションホストを参加させて構築をしているわけではないため、オンプレミスの AD の DNS を使用して構成できるかを検討することになるのではないでしょうか。
今回の検証ではオンプレミスの AD の DNS を使用して構成を行っています。
AD の DNS には「privatelink.wvd.microsoft.com」「privatelink-global.wvd.microsoft.com」の 2 種類のゾーンを追加しています。
このゾーンに対してプライベートエンドポイントの A レコードの追加を行います。
追加するレコードについては、プライベートエンドポイントの「DNS の構成」で確認をすることができますので、作成したエンドポイント (Compute に記載されている conection/ feed / global のエンドポイント) で必要となるカスタム DNS レコードを追加しています。
このような設定を行い、セッションホストを再起動したところ、プライベートエンドポイントを使用した接続となっていました。
ホストプールの「ネットワーク」で「パブリックアクセス」をプライベートエンドポイント向けの設定に変更し、セッションホストを再起動した際に、「接続できません」となっている場合、セッションホストでプライベートエンドポイント向けの DNSレコードが正しく設定されているかを見直したほうがよさそうでした。(この辺は Azure で構築した場合は VNET に統合された DNS により透過的に設定ができているケースがあるのかもしれないと思いました)
正常に構成できていればプライベートエンドポイントの設定を行っても次の画像のように接続可能なセッションホストとして認識されます。(私が検証した際には、接続できませんにカウントアップされている場合は DNS の設定の見直しが必要でした)
公衆ネットワークアクセスの設定を変更後に「接続できません」になった場合のログ確認
プライベートエンドポイントの検証をする際に、「公衆ネットワークアクセス」の設定を変更し、セッションホストの再起動またはRemote Desktop Agent Loader (RDAgentBootLoader) サービス を再起動した後に、「接続できません」の状態から「接続可能」に変わらない場合、私が検証していた範囲では、DNS による想定された名前解決ができていないことが主な要因となっていました。
必要となるエンドポイントにアクセスができていない場合、イベントビューアーの「RemoteDesktopServices」にログが出力されていました。
パブリックアクセスの設定変更後に「接続できません」の状態が継続する場合には、イベントログからアクセスができていないエンドポイントを確認するとよいのではないでしょうか。
NSG を使用したアクセス制御
厳密な確認はしていないのですが、プライベートエンドポイントを展開したサブネットに対して NSG を設定する必要がある場合は、次の設定を活用できるのではないでしょうか。
- ネットワーク セキュリティ グループまたは Azure Firewall を使用してパブリック ルートをブロックする
- プライベート エンドポイントのネットワーク ポリシーを管理する
- Azure Virtual Desktop に必要な FQDN とエンドポイント
ネットワーク セキュリティ グループまたは Azure Firewall を使用してパブリック ルートをブロックする には次の記載があります。
ネットワーク セキュリティ グループまたは Azure Firewall を使用して、ユーザー クライアント デバイスまたはセッション ホストからプライベート エンドポイントへの接続を制御している場合は、WindowsVirtualDesktop サービス タグを使用して、パブリック インターネットからのトラフィックをブロックできます。 このサービス タグを使用してパブリック インターネット トラフィックをブロックすると、すべてのサービス トラフィックでプライベート ルートのみが使用されます。
セッション ホスト仮想マシン から必要となる通信 としては、サービスタグを使用した次の通信があります。
通常の AVD では、プライベートエンドポイントで通信を実施させる場合、セッションホストが配置されているサブネットの送信セキュリティ規則として、次のような規則を作成してセッションホストからのパブリックアクセスの経路を閉じることがありますので、HCI 出の子規則が必要となるか (動作するか) を確認する必要はあるのではと思います。
NSG のフローログの取得について
プライベートエンドポイントの NSG のフローログについては プライベート エンドポイントへのトラフィック に記載されていますが、プライベートエンドポイントへのトラフィックについてはソース VM 側でのキャプチャとなるということで、ソース VM を HCI 上に展開している AVD for Azure Stack HCI については、NSG フローログを取得するのは難しそうでした。
まとめ
軽く検証した範囲では AVD for Azure Stack HCI でもプライベートエンドポイント経由でのアクセスの利用は可能なようでした。