AWS 環境に Windows Server をたてて RemoteApp を構成している環境で、クライアントからのリモート接続時に数回に１回の割合で RDP 接続が失敗する事象に遭遇しました。
セッションホスト直接接続利用でのセッションホストを束ねたIPに対する接続時に証明書のエラーが発生
今回の構成を説明しておくと、リモートデスクトップサービス（RDS）を使った以下の構成です。
- RD 接続ブローカー(兼 Web アクセス) × 2 ※高可用性モード
- RD セッションホスト × ２（同一コレクション）
- SQL Server × １（高可用性構成のデータベース用）
- AWS ロードバランサ（セッションホストを束ねる用途）
一般的には、クライアントから Web アクセスに接続し、DNS ラウンドロビン(もしくは NLB)で登録されたブローカークラスタ名へ接続する構成が多いと思います。
今回は、クライアントから Web アクセスを経由せずに直接セッションホストサーバーへ RDP 接続を行う用途であったため、セッションホストを束ねるために基板側の AWS ロードバランサーを使う構成となっていました。
クライアントはロードバランサの IP に対して RDP 接続をすることで、セッションホストに接続され、ブローカーへの問い合わせ（負荷分散）後にセッションホストに接続されると言った動作になります。
RDP 接続時のエラー “リモート コンピューターから予期しないサーバー認証証明書を受け取ったため、接続は終了しました。”
RDP 接続時のエラー内容は「リモート コンピューターから予期しないサーバー認証証明書を受け取ったため、接続は終了しました。接続し直してください。問題が続く場合は、リモート コンピューターの所有者かネットワーク管理者に問い合わせてください。」というものです。
切り分けのために AWS ロードバランサの IP ではなく、どちらかのセッションホストの IP に接続を試みたところ、このようなエラーは発生せず、問題なくセッションを確立できます。これにより、間に噛ましてるロードバランサーが原因と推察。
AWS ロードバランサーのスティッキーセッションが原因
試しに Windows のネットワークロードバランサにて構成した環境で確認したところ、このようなエラーは発生しなかったため、原因は AWS のロードバランサーのようです。
海外のフォーラムで以下のコメントを見つけました。
What type of load balancer and what RDS configuration e.g. do you use TLS?
If it’s not an RDP-aware setup and is just something load balancing ports 3389/443 round-robin, make sure you have sticky sessions (or in F5 speak that’s “source IP persistence”)
If it’s RDP aware like a Netscaler MPX or RD Connection Broker/NLB look at the CRL issue mentioned already by others
このコメントによると、RDP 対応のセットアップではなく、ポート 3389/443 のラウンドロビンの負荷分散に過ぎない場合は、スティッキーセッションがあること、とあります。
スティッキーセッションを維持する設定を追加
スティッキーセッションとは、ELB がサーバーへのリクエストを振り分ける際にセッションを維持するかどうかの設定で、維持を有効にすることで特定のクライアントからのリクエストを特定のサーバーに紐付けを行う設定との事です。
そのため、スティッキーセッション無しの場合、クライアントからのリクエストは LB の負荷分散機能によってセッションホストへ振り分けられますが、リクエストの要求がある度に異なるサーバーへ振り分けられるということになります。
今回、スティッキーセッションの設定的にセッションを維持しないとなっていたため、クライアントからの接続が LB によって行われた際に RD 接続ブローカーからの負荷分散が行われ、最初に LB によって振り分けられたセッションホストとは別のセッションホストへ接続となった際に証明書エラーが発生していたものと推察します。
今回のような構成で LB 側ではなく、サーバー側の負荷分散機能（今回の場合の RD 接続ブローカーのセッション管理機能）を利用する場合は、LB のセッション維持を有効にしておくことが必要です。
