DirectAccess 経由で VDI の仮想デスクトップに接続できない !? (原因と回避策)

Windows Server 2012 の DirectAccess、そしてリモート デスクトップ サービス (RDS) に統合された　VDI (Microsoft VDI)、どちらもリモート ワークを可能にするテクノロジですが、両者を組み合わせた場合に発生するかもしれないトラブルとその回避策です。

DirectAccess 接続でインターネット側から社内 LAN に接続すれば、社内の VDI も利用できるはずと、誰もが思うはず。でも Windows Server 2012 の DirectAccess と Microsoft VDI を組み合わせた場合、不可解な現象に遭遇します。RD Web アクセスから仮想デスクトップに接続できないんです。


こんなリモート アクセス環境を想像してください。問題なさそうですよね。

※ DA (DirectAccess)、ADDS (Active Directory Domain Service)、RD Web (RD Web アクセス)、RDCB (RD 接続ブローカー)、RDVH (RD 仮想化ホスト)、VD Collection (仮想デスクトップ コレクション、プールまたは個人)

DirectAccess クライアントを社内 LAN に直結して、RD Web アクセス経由で仮想デスクトップ プールに接続すると、このとおり (↓) 接続は成功します。

この DirectAccess クライアントを社外に持ち出して、インターネットに接続すると、DirectAccess 接続 (職場への接続) が自動的に確立します。当然ながら、社内の RD Web アクセスのサイトにもアクセスできます。しかし、仮想デスクトップ コレクションへの接続を開始すると...

仮想デスクトップの割り当てや仮想マシンの開始とかまでは正常に動いているように見えるのですが、"仮想マシンからネットワーク情報を取得しています..." のあと、接続に失敗します。

ちなみに、仮想デスクトップの FQDN を直接指定して接続すると、問題なく接続できます。

どういうことでしょうか？

ポイントは、"DirectAccess 接続は IPv4 アドレス直接指定によるアクセスをサポートしていない" ことにあります。Windows Server 2012 の DirectAccess は、NAT64/DNS64 の実装により、IPv4 オンリー ホストへの接続がサポートされましたが、DirectAccess クライアントと DirectAccess サーバーの間は IPv6 なので、IPv4 アドレスの直接指定はできません。まず、このことを覚えておいてください。

DirectAccess 接続時に仮想デスクトップの FQDN を直接していして接続した場合 (RD 接続ブローカーを経由しない場合)、IPv6 アドレスの RDP (ms-wbt-server、3389/TCP) に接続しています。

では、仮想デスクトップ コレクションへの接続に失敗したときはどうなっているのかというと...

仮想デスクトップの IPv4 アドレスに直接接続しようとした痕跡が残っています (SYN_SENT)。


以前、Windows　Server 2012 Community Day というイベントで Windows Server 2012 の VDI で Windows XP がサポートされない理由として、仮想デスクトップへのリダイレクトの仕様変更と、Windows XP がエンド ポイントの IP アドレス情報を返さないことについて紹介しました。DirectAccess 接続経由で失敗する理由は、これに関連しています (と思います)。

→ Windows Server 2012 VDI Deep Drive! with App-V 5.0

Windows Server 2008 R2 までの Microsoft VDI では、FQDN を使用して最終的な仮想デスクトップに要求がリダイレクトされていました。そのため、仮想マシン名を FQDN と一致させておく必要があるという制約がありました。Windows Server 2012 の Microsoft VDI では、RD 接続ブローカーがユーザーに割り当てた仮想マシンから、エンド ポイントのアドレス情報を直接聞き出して、それをリダイレクト先の接続情報としてクライアントに返す動作に変更されています。

社内 LAN 上で仮想デスクトップ コレクションに接続 (成功) した際の、RD 接続ブローカーとクライアントの両方のイベント ログを見てみましょう。まずは、RD 接続ブローカー側です。TerminalServices-SessionBroker-Client ログに、エンドポイントから取得した IPv4 アドレスが記録されています。仮想デスクトップ コレクションへの接続時の "仮想マシンからネットワーク情報を取得しています..."は、このエンドポイントの IP アドレスを取得しようとしているところみたいです。

こちらはクライアント側のログです。Microsoft-Windows-TerminalServices-RDPClient/Operational ログに、IPv4 アドレス指定の接続が開始されていることが記録されています。

RD Web アクセスからの仮想デスクトップ コレクションへの接続は、最終的に RD 接続ブローカーが提供するエンドポイントの IP アドレスに対して行われます。通常、IPv4 アドレスが返され、そのアドレスに対して接続が試行されるため、DirectAccess 接続では失敗する (IPv4 アドレス直接指定は不可なので) というわけです。

IPv6 ネイティブな環境が手元にないので、Microsoft VDI を IPv6 環境に展開した場合、IPv6 アドレスを返してくれるかどうかは未確認です。もし、IPv4 アドレスではなく、IPv6 アドレスを返してくれるのであれば、 DirectAccess 接続でも接続に失敗することはないと思います。どなたか、IPv6 ネイティブ環境に Microsoft VDI を導入している方おりませんかぁー！

では、IPv4 アドレスが返される環境ではどうすればよいのでしょうか。思いつく回避策は、RD ゲートウェイの導入です。境界に設置する必要はありません。RD Web アクセスからの接続を RD ゲートウェイを経由させることで、エンドポイントとのやり取りは RD ゲートウェイが行うことになるので、この問題を回避できるはずです。

 社内 LAN 上に RD ゲートウェイを設置します。RD Web アクセスと同じサーバーでも OK です。追加した設定は、こんな感じ。

ばっちり問題解決。上のように構成すれば、DirectAccess 接続時は RD ゲートウェイ経由、LAN 接続時は直接に RDP 接続されました。

お絵描きするとこんな感じかな？

しかし、DirectAccess 環境で RD ゲートウェイを設置するのは、美しくないですよね。DirectAccess の IPSec 暗号化、RDP のプロトコル自身が持つ暗号化、RDP over HTTPS の暗号化と、何度も暗号化されるとプロセッサ リソースをそれだけ余計に消費します。RD　ゲートウェイを導入するなら、DirectAccess の環境を構築するまでもなく、RD ゲートウェイをインターネットに公開したほうが早いような気もします。