Network Load Balancerを経由してRDP接続してみる
いわさです。
ちょっと事情があって、Auto Scalingグループ（ASG）配下のEC2インスタンスに「いつでも」RDP接続出来るようにしておきたいなというシーンがありました。
そしてRDP接続するユーザーにはAWSの認証情報ではなくリモートデスクトップ接続に必要な情報のみを共有する必要がありました。
また、踏み台やポートフォワードやRDゲートウェイなどは使わずに、通常のリモートデスクトップ接続の操作手順に近い必要もあります。
外部から直接RDP接続することの是非は本記事では触れません。
パブリックなサブネットに配置されている場合はパブリックIPを共有して接続してもらうだけで済みますね。
ただし今回はASG配下ということで、AZ障害などでインスタンスが置き換わる可能性があります。
そうすると都度現在のIPアドレスを共有し直す必要があります。
できればインスタンスが置き換わっていても、同じパブリックIPアドレスでアクセスしたい。固定化をしたいところだと思いますが、以下のような方法を取ると固定化出来そうです。
予め確保しておいたElastic IPをEC2インスタンスが起動されるときにスクリプトで割当する方法です。
上記で実現は出来そうなのですが、別の方法としてNetwork Load Balancer(NLB)も使えるかなーと思いました。
うまくいきそうな気はするのですが本当にRDP接続出来るのか、接続にあたってAZ分散されたIPアドレスはどうなるのか、など動かして確認したかったので試してみました。
やってみた
NLBとターゲットグループにASGを紐付けます。
注意点としては、NLBはセキュリティグループがないのでヘルスチェック時の送信元を考慮する必要がありました。
今回は、ヘルスチェックポートはトラフィックポートを使い、ドキュメントに記載があったので送信元にVPC CIDRを指定しました。
接続出来ました。
NLBを構成する際にAZを指定しますが、AZ1とAZ2にNLBを配置したとした場合パブリックIPアドレスは2つ存在します。
AZ1にインスタンスが存在している時はAZ1に割り当てられているパブリックIPアドレスから通信が出来て、AZ2に割り当てられているパブリックIPアドレスからは通信出来ません。
切り替わった時は別のAZのNLBのパブリックIPアドレスへアクセスする必要があります。
このようにIPアドレス直接だとAZ毎のIPアドレスを利用者が使い分ける必要があるのでDNS名を使います。
iwasa.takahito@hoge hoge % nslookup hoge-nlb-ce08d302304b7ca5.elb.ap-northeast-1.amazonaws.com Server: 192.168.111.1 Address: 192.168.111.1#53 Non-authoritative answer: Name: hoge-nlb-ce08d302304b7ca5.elb.ap-northeast-1.amazonaws.com Address: 35.74.192.163
ヘルスチェックで有効になっているAZのパブリックIPアドレスのみ取得されました。
DNSで名前解決
今後NLBを作り直す可能性があるとか、NLBのデフォルトDNS名をそのまま共有するのがいまいちであれば、Route53にNLBのエイリアスレコードを登録する感じになるかなと思います。
エイリアスレコードを追加しました。
iwasa.takahito@hoge hoge % nslookup rdp.tak1wa.com Server: 192.168.111.1 Address: 192.168.111.1#53 Non-authoritative answer: Name: rdp.tak1wa.com Address: 18.176.166.166
接続出来ますね。
ASGのインスタンスを停止させて、自動復旧してもう一度接続してみましょう。
自動起動した直後は接続出来ませんでした。
切り替え直後に名前解決で取得されるIPアドレスが切り替わるまでタイムラグがあります。
iwasa.takahito@hoge hoge % nslookup rdp.tak1wa.com Server: 192.168.111.1 Address: 192.168.111.1#53 Non-authoritative answer: Name: rdp.tak1wa.com Address: 35.74.2.68 Name: rdp.tak1wa.com Address: 18.176.166.166
少し待つと以下のようにEC2が生きているほうのAZのパブリックIPアドレスが帰ってきます。
iwasa.takahito@hoge hoge % nslookup rdp.tak1wa.com Server: 192.168.111.1 Address: 192.168.111.1#53 Non-authoritative answer: Name: rdp.tak1wa.com Address: 35.74.2.68
接続出来ました。
この用途でNLBは必要なのか？
個人的には、接続先がインターネットからアクセス出来る環境であれば、冒頭で述べたElastic IPをスクリプトで割り当てるほうが良いかなと思いました。
NLBの料金が発生しますし、管理対象リソースが増えるのがちょっと嫌な感じです。
逆にNLBを活用出来るシーンあるか考えたのですが、接続先のASGがプライベートサブネットにあってパブリックIPアドレスを割り当て出来ない場合に使えるかなと思いました。
せっかくなのでNLBを経由したプライベートサブネット（NATゲートウェイへのルート有り・無し）へのRDP接続も試してみました。
以下のような構成です。
CloudFormationテンプレートを一応残しておきます。
接続出来ました。
まとめ
パブリックサブネットであればElastic IPアドレスを初期化処理で割り当てる、プライベートサブネットであればNLBを使う。という使い分けをするのが良さそうかなと思いました。
