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

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

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

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

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

・Blob=”RDAgent” “RDAgentBootLoader”のダウンロード用通信
・AzureAD=Managed環境への接続確認用の認証通信(デプロイ時のみ) ※WVD ARMは不要
・RD Gateway=SxS Stack(リバースプロキシ用通信)
・Connection Broker=ヘルスチェック(HeartBeat)用通信
・FSlogix=ユーザープロファイル用通信
・Active Directory=認証用通信

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

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

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

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

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

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

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

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


全体の流れ

Step1:通信先の調査
Step2:UDR の作成
Step3:Service Endpoint の作成





Step1:通信先の調査

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

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

また、デプロイ先のリージョンは、WVDを利用する同じリージョンで行ってください。
調査結果の”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


Step2:UDR の作成

調査した”IP Address”をUDRに登録します。 例:東日本
※Session Host(VDI)をデプロイするサブネットに対して適用


Step3:Service Endpoint の作成

[サービス エンドポイント]ー[Microsoft.AzureActiveDirectory]を選択
※Session Host(VDI)をデプロイするサブネットに対して適用


それでは、接続してみましょう!

強制トンネリング環境でも、無事に接続できました!