Windows Virtual Desktop #38 中国本土から WVD を利用する

この記事のWVDは”Windows Virtual Desktop Spring 2020 Release”が対象です。

今回の記事では中国本土からのWindows Virtual Desktop への接続を実際に試す内容になります。　Japan East リージョンに展開した仮想のWindows 10 に中国本土からアクセスした場合、そもそも接続できるのか？どこの管理プレーンに接続されるのか？、この2点を確認していきます。

1. テストする環境

Alibaba Cloud のBeijing (北京)とShanghai (上海) にWindows Server 2019 を立ち上げてそこからWindows Virtual Desktop に接続します。　仮想のWindows 10 はAzure のJapan East region に展開しています。

この時、中国本土のリモートデスクトップクライアントの接続先がどこになるのか？　が今回の一番の検証ポイントとなります。

Alibaba Cloud には2 vCPU、8 GiB メモリを搭載する Burst タイプのインスタンス (t6-c1m4.large)をBeijing と Shanghai のリージョンに今回のテスト用に展開します。従量課金で0.081 USD / 時間ですのでレート 107円 / USD 換算で1時間で約8.7円 / 時間です。　　

Azureの似たスペックだと B2MS (2 vCPU、8GiB メモリ）が12.208円 / 時間です（ディスク抜き）。　Alibaba Cloud はディスク込みで8.7円 / 時間なのでAlibaba Cloud は安いですね。

2. Shanghai （上海）からの接続

Alibaba Cloud のコンソールから Shanghai のWindows Server 2019 のパブリックIPアドレスを確認します。　（Alibaba Cloud へのECS インスタンスは事前に展開済です）

手元のPC（東京の自宅にある物理PC)からリモートデスクトップでShanghai のWindows Server 2019 に接続します。　

OSは Windows Server 2019 Datacenter (1809)、CPUは Xeon Platinum 8269CY なのでBurst タイプとは言え良いCPU を使えます。　なお Alibaba Cloud のインスタンスのTime Zone は既定でUTC +8:00 です。　これはAlibaba Cloud の東京リージョンにデプロイした場合もです。　気になる人は修正しましょう。

Windows Virtual Desktop の接続クライアントとなる msrdc をインストールします。　（手順は省略）

Remote Desktop Client を起動し、Windows Virtual Desktop に接続します。

Azure AD の認証を進め、Workspace に接続します。

何の問題もなく接続出来ました。　明るい青いデスクトップがWindows Virtual Desktop の仮想のWindows 10 です。

少しわかりづらいのでAlibaba Cloud のShanghai region にあるWindows Server 2019 の背景を Alibaba Cloud カラーのオレンジ色にします。

Windows Virtual Desktop の接続に利用しているリモートデスクトップクライアントの接続情報機能から通信品質を確認します。

Latency ( Round-trip time )は 100 ms です。　”Your connection’s network round-trip time is fair” とのことなんで Windows Virtual Desktop を利用する上では問題なしのようです。

接続先( Server details > Gateway name ) は afd-rdgateway-r0.wvd.microsoft.com です。　この接続先自体は全世界共通なはずで地理的負荷分散により最適な接続先に自動的に振り分けられます。　

Shangahi の Windows Server 2019 （オレンジのデスクトップ）から nslookup により”afd-rdgateway-r0.wvd.microsoft.com” を名前解決します。　Aliases が色々返ってきているので本当はパケットキャプチャして一つ一つ名前解決を紐解くのが一番ですが今回は省略します。　

C:\Users\Administrator>nslookup afd-rdgateway-r0.wvd.microsoft.com
Server: UnKnown
Address: 100.100.2.136
Non-authoritative answer:
Name: standard.t-0001.t-msedge.net
Addresses: 2620:1ec:bdf::10
13.107.246.10
Aliases: afd-rdgateway-r0.wvd.microsoft.com
mrs-rdgateway-r0-prod.azurefd.net
t-0001.t-msedge.net
Edge-Prod-HK2r3.ctrl.t-0001.t-msedge.net

実際の接続は OS 標準のResource Monitor で確認するのが最も簡単です。 Network Activity から “msrdc.exe” のAddress を確認します。

拡大すると以下の通り。 “13.88.221.28”と通信していることがわかります。

あとは Task Manager から msrdc.exe のPIDを確認し（以下の画面だと4184)

他の方法として、コマンドプロンプトから”netstat -aon” を実行し、msrdc.exe のPIDのエントリを探して、接続際のIPアドレスを確認してもよいです。　と思ったらこっちでは”13.88.221.28″とは別に”13.75.34.66″とも443 / tcp で接続していますね。どうして Resource Monitor ではこの”13.75.34.66″との通信が確認出来なかったは不明。　netstat で見た方が確実かもしれません。

とりあえず Shanghai の Windows Server 2019 上のリモートデスクトップクライアント(msrdc.exe)は2つのグローバルアドレス”13.88.221.28″と”13.75.34.66″に接続していることがわかりました。　あとはこのアドレスの所在を確認します。

まずは whois で確認します。Microsoft のIPアドレスです。 whois は適当なホストからでも今回はAsia だったのでAPNIC のサイトからでも確認可能です。

NetRange: 13.64.0.0 – 13.107.255.255
CIDR: 13.64.0.0/11, 13.104.0.0/14, 13.96.0.0/13
NetName: MSFT
NetHandle: NET-13-64-0-0-1
Parent: NET13 (NET-13-0-0-0-0)
NetType: Direct Assignment
OriginAS:
Organization: Microsoft Corporation (MSFT)
RegDate: 2015-03-26
Updated: 2015-03-26
Ref: https://rdap.arin.net/registry/ip/13.64.0.0

あとは場所になります。今回は手抜きして https://db-ip.com/ のサイトで調べました。”13.88.221.28″と”13.75.34.66″ もHong Kong (香港) でした。

絵にしてみると以下の通信経路になっていると考えます。　Shanghai のWindows Server 2019はリモートデスクトップクライアント(msrdc.exe)からHong Kong のAzure のパブリックIPアドレスに接続し、あとはAzure のBackbone を通って日本のJapan East region にある仮想のWindows 10 と画面転送の通信を行うと。

3. Beijing （北京）からの接続

Beijing の Alibaba Cloud のWindows Server 2019 （オレンジ背景）にリモートデスクトップで接続します（接続先は 39.106.144.15 )。　

そして Windows Virtual Desktop の仮想のWindows 10 (青色背景）に接続します。

リモートデスクトップクライアント (msrdc.exe) の接続情報を確認します。

Round-trip time は 150 ms です。　上海からの 100 ms よりも＋50 ms ですね。　それでも “Your connection’s network round-trip time is fair.”なので許容範囲のようです。

msrdc.exe からの接続先は “13.88.221.28”であることが確認できます。　Shanghai のWindows Server 2019 からの接続先と同じMicrosoft が管理する Hong Kong のパブリックIPアドレスです。

結果として、Beijing （北京）からのWindows Virtual Desktop の接続もShanghai からと同様にHong Kong に接続していることがわかりました。

ただ、この時点でも不明なのは Windows Virtual Desktop のControl Plane（Gateway) の所在です。　日本にあるのか Hong Kong なのか判別できません。　

仮想のWindows 10 (青色背景）でResource Monitor から Network Activity を確認します。　そうするとsvchost.exe (NetworkService) が”13.88.221.28″と通信していることがわかります。　試しに画面転送の通信を意図的に増やしてみたところこのsvchost.exe (NetworkService) の”13.88.221.28″への通信量が増えることが確認できました。

参考として、Windows Virtual Desktop ではなく通常のリモートデスクトップの場合はsvchost.exe (termsvcs) が画面転送の通信を行います。Windows Virtual Desktop ではsvchost.exe (NetworkService)になるのかもしれません。　

4. まとめ

今回の検証により中国本土、とはいっても北京と上海の2か所のみですが、からWindows Virtual Desktop に接続するとその接続先はMicrosoft が管理する香港のパブリックIPアドレスになることがわかりました。

1つ前の記事で書いたのですが、中国本土でのWindows Virtual Desktop は2021年のリリース予定です。　それまではControl Plane もVirtual Machine も中国外に接続する必要があり、その際の接続先が香港となるということです。

また、接続しているGateway の所在も香港である可能性が高いこともわかりました。

”可能性が高い”と表現したのは、今回の検証では本当にGateway が Hong Kong にあるとまで断言出来ないということがあります。　利用者側から見えているIPアドレスの実体がどこにあるかは確認しようがないためです。全世界にBackbone Network を持っているような場合、そのパブリックIPアドレスの所在は単純なものではないということもあります。　

加えてGateway 以外のBroker などもどこにあるかは今回の検証では確認できていません。　