RD Gatewayを使ってかっこよくクラウド上のWindowsVMに接続する

 

こんにちは。
TAFS Adventカレンダー2023 にチャレンジしますMPPAです。


表題に掲げた「かっこよく」いかにも胡散臭いタイトルですが、
周りにヒアリングしたところ、この方法が「まだ当たり前のように使われているわけではない」と独自調査(これも胡散臭い)で判断したので記事にしようと思います。


👹お品書き👺
1. 本日のゴール
2. RD Gatewayを利用するメリット
3. 準備
4. かっこよく接続する環境を作る
5. 最後に


1.本日のゴール

今回はAWSを利用してWindowsVMを起動し、RD Gatewayを利用してRDP接続します。

2.RD Gatewayを利用するメリット

ゲートウェイにも認証があるため、ユーザー認証や証明書認証適用できるため、このゲートウェイを通過したもののみが内部へアクセスできるようになります。
ゲートウェイ認証での制御でアクセスすれば、無造作に作成されたAdministrator/P@ssw0rdみたいな真っ裸なサーバーへのアクセスもいったんは安心です。

また、リモートデスクトップ標準ポート3389をセキュリティグループにて許可する必要がなくなります。攻撃対象になりやすい3389ポートなので閉めておけばちょっとは安心です。

もう一つ大きなメリットとして、例えば443ポートでゲートウェイが通信していれば、
443ポートでゲートウェイを通過してSSLトンネルを利用してリモートデスクトップに接続可能です。(私はこの接続あまり好きじゃないですけどまあセキュアですよ)

と言うわけでこれと言ったメリットが説明できなくてごめんなさい🙏

3.準備

ざっくりですが以下のように環境を作りました。
名前備考
リージョンap-southeast-1シンガポールリージョン
VPCmppadev-vpc1
SUBNETmppadev-public-subnet110.1.129.0/24
ルートテーブルmppadev-public-route1
インターネットGWmppadev-inet1
セキュリティグループmppadev-sec-group1 
Elastic IPmppadev-elaip1証明書を使うので利用

4.かっこよく接続する環境を作る

4.1 VMの作成

まずはWindowsVMを作成します。

今回は起動して接続できればいいのでt2.microで実施します。
準備したサブネットや、セキュリティグループを割り当てて起動しましょう。

情報隠したら見事に黒塗り状態!(意味ない黒塗りもあるが)


4.2 RDGatewayのインストール

インストールするためにRDPしなくてはいけないのでいろいろ考えた結果一時的に、
RDPポートを開けることにしました。
Administratorのパスワードを取得して、さっそく接続します!

↑全部英語だったので日本語化します↓


サーバーマネージャを起動して[管理]-[役割と機能の追加]でウィザードを起動します。

「役割ベースまたは機能ベースのインストール」を選択してリモートデスクトップゲートウェイを追加します。
サーバーの役割で「リモートデスクトップサービス」を選択すると当該ゲートウェイを追加することが可能です。



ちなみにこのゲートウェイはIISを利用するので下記の画面がでても臆せず全部インストールしてしまいましょう!

サーバーが貧弱なせいか偉いインストールに時間がかかります。
(と思いました)

ようやく終わりました!

4.3 RD Gatewayの設定

さあ、インストールも終わったので設定しますよ!
またサーバーマネージャのお世話になります。

[ツール]-[Remote Desktop Services]-[リモートデスクトップゲートウェイマネージャ]を開きます。

ゲートウェイマネージャで新しい認証ポリシーを作成します。

ここからはいろいろ設定があるので掻い摘んで説明していきます。

下記パラメータシートに記載のない項目は今回デフォルトのままです。
また、設定についてはケースバイケースで設定することになるかと思いますが
今回はとりあえず接続することを目的とします。

作成する承認ポリシーの種類RD CAPとRD RAPを作成する
接続承認ポリシー
 RD CAPの名前(任意)
 ユーザーグループメンバシップAdministrators
リソース認証ポリシー
 RD RAPの名前(任意)
 ユーザーグループメンバシップAdministrators
 ネットワークリソースユーザーによる任意の~接続を許可する
 許可されたポートポート3389への接続のみ許可



上記画面で完了ボタンを押せばポリシーの作成完了です!


4.4 オレオレ証明書の作成

IIS経由でhttpsを利用してゲートウェイに接続をするので証明書が必要です。
いつも通り検証なのでオレオレ証明書(自己署名)を作成します。


RD Gatewayで簡単に作成できます!
またサーバーマネージャにお世話になりましょう。
先ほどのゲートウェイマネージャ自分のサーバーのステータスをみると、
下図のような状態に「×」がついた項目があるので構成タスク部分をクリックします。


証明書の作成とインポートを選択して自己署名証明書を作成しましょう。


名前を入力して、ルート証明書の格納場所(今回は使いません)を設定したら
OKを押下して作成します。
 ※ポイント!
  オレオレ証明書の名前は適当じゃだめだそうです。
  画面にある通り「FQDNに一致する」名前じゃないとだめです。
  IPアドレスやドメイン名がそれにあたると思います。
  今回はIPアドレスを名前にしてあります。

できました!(エラーがなくなっていればOK)

作成したオレオレ証明書はエクスポートしておきます。
certlm.mscで確認すると個人の証明書に先ほど作成した証明書が格納されていました。

これをエクスポートします。


4.5 RDゲートウェイの起動

サーバーマネージャからRDゲートウェイを起動しましょう!
(サービスなんでどっから起動してもいいんですけどね)


長かった道のりもあとはクライアントの設定のみです!!

4.6 RDゲートウェイ接続

と、思ったのですが、セキュリティグループでまだ通信を許可するのを忘れていました。
EC2のあるセキュリティグループに443ポートの許可を追加しましょう。
ついでにセットアップで追加した3389ポートの許可を削除しましょう。

セキュリティグループのインバウンドに443を追加しました。
とりあえずソースは自分のIPだけにしておきます。
(必要に応じて許可して下さい)


今度こそクライアント設定です。
先ほどエクスポートした証明書を手元に持ってきてインポートします。

インポート場所は[信頼されたルート証明機関]です。

誰が信頼してるかって?
信頼しているのはあなたです(笑)

・・・・・・・
・・・・・
・・・笑ってるのは私だけですね。。

こちらで完了です。。


リモートデスクトップの画面を開きます。
詳細設定を開き[任意の場所から接続する]の設定を選択します。

RDゲートウェイの設定を行い、OKでいったん画面を閉じます。
サーバー名にはEC2のパブリックIPかDNS名を入力します。(証明書の名前に合わせます)

リモートデスクトップには接続したいサーバーのローカルIPアドレスを入力します。
RDゲートウェイを利用することで、ローカル接続が実現します!



今回はゲートウェイとリモート接続先が同じですが、ゲートウェイからアクセス可能なローカルサーバーにもこうして接続することができるわけです。
(今回は尺の関係で省略させていただきます)

まずゲートウェイの認証をします。
ここでのポイントですがドメインを指定しないと認証できません。
今回はローカル認証(RDゲートウェイサーバー上のユーザー)ですので
「.\」を先頭につけて(localhost\でも同様です)ログインしました。


続けてリモートデスクトップの認証を行います。


無事にローカルIP指定で繋がりました!
これで完了です!

5.最後に

正直この接続方法に出会ったとき衝撃的でした。
自分は開発側の人間のため、インフラ設定については与えられたもの正として、
それをどのように利用するかをいつも考えています。
今回はこのような環境下でプロジェクトを実施したのですが、衝撃で、
初めて「このような環境を自力で再現したい!」と思い作成したので執筆いたしました。

これにてMPPAのTAFS Advent カレンダーの記事を終了いたします。
またどこかでお会いしましょう。




コメント

このブログの人気の投稿

ProxmoxでLet's Encryptを使用した証明書セットアップをやってみた

AIと共に「考える」エンジニアに!

ルーティングって何で必要で、何してるの?を React Routerで理解する