強制トンネリング環境に Azure Virtual Desktop を構築する！

強制トンネリングとは、Azure上のVMに対して、デフォルトルート(0.0.0.0/0)をオンプレミスに向ける事です。特に日本に多いらしいのですが、この強制トンネリングが Azure Virtual Desktop(AVD) の導入に大きく立ちはだかります。

なぜなら、AVDを快適に利用するためには、必要な通信を最短経路で届ける必要があるからです。この必要な通信が全てオンプレミス経由となると、それだけで大きな遅延が発生してしまいます。さらに厄介なのが、多くの環境で”Proxy”を導入している事です。。

オススメのNW構成はこちら「Azure Virtual Desktop ネットワークアーキテクチャ」

先ずは、AVDを快適に利用するために必要な通信を確認してみましょう！

これらの通信を”FW”や”Proxy”にて阻害してはいけません。
また、オンプレミスを経由せずに導入するのが快適なAVDの利用に繋がります！

・Blob＝”RDAgent” “RDAgentBootLoader”のダウンロード用通信
・AzureAD＝Managed環境接続用の認証通信(デプロイ時のみ) ※AVD Classicで利用
・RD Gateway＝SxS Stack(リバースコネクト用通信)
・Connection Broker＝ヘルスチェック(HeartBeat)用通信
・FSlogix＝ユーザープロファイル用通信
・Active Directory＝認証用通信

※これらの通信は、ブラウザから行うProxy設定、WinHTTP Proxy設定の対象となりません。

～注意～
“AVD Client” “SessionHost”共に東西(日本の場合)のGatewayに接続を試みている。
最初の接続は”AVD Client”が利用しているFrontDoorに近いリージョンが選択される。
※必ずしも”SessionHost”が存在するリージョンのGatewayが選択されるわけではない。

そこで、今回の構成です！

※AVDに必要な通信意外は、オンプレミス経由にしたい場合の構成

・Blob＝「UDR」を利用してデフォルトルートを回避します。
※「Service Endpoint」も利用できるのですが、通信先を特定できるため「UDR」で対応。

・AzureAD＝「Service Endpoint」を利用してデフォルトルートを回避します。
※宛先の特定ができない。AVD Classicで利用。

・RD Gateway＝「UDR」を利用してデフォルトルートを回避します。
※宛先が”Web App”なのですが「Service Endpoint」のIPレンジに含まれていない。

・Connection Broker＝「UDR」を利用してデフォルトルートを回避します。
※そもそも、宛先が”USWest2″なので「Service Endpoint」を利用できない。

全体の流れ

Step１：通信先の調査
Step２：UDR の作成
Step３：Service Endpoint の作成

Step１：通信先の調査

UDRに登録するための”IP Address”を調べるために、Session Host(VDI)からの発信している通信先を調べたいと思います。

調査には、Session Hostが必要なのですが、”強制トンネリング” “FW” “Proxy”の影響を受けない、仮想ネットワークにデプロイして下さい。

また、デプロイ先のリージョンは、AVDを利用する同じリージョンで行ってください。
調査結果の”IP Address”には、リージョン固有のものが含まれているためです。

Session Host(VDI)用VMー[分析情報]ー[マップ]を選択

以下のURLに該当する”IP Address”を調べます。
*.wvd.microsoft.com
*.blob.core.windows.net
*.core.windows.net
*.servicebus.windows.net
prod.warmpath.msftcloudes.com
catalogartifact.azureedge.net