AWS EIPを使用したSSH踏み台サーバーの冗長構成について
最近「伝説対決」というスマホゲームにはまっている、プラットフォーム技術部の山崎です。
伝説対決というのはeスポーツとして世界的にも盛り上がっている5 vs 5の対戦ゲームで、自分のキャラクターをレベルアップさせながら相手のキャラクターや拠点を攻撃して、最終的に相手チームの本陣を破壊すれば勝ち、というゲームです。とにかくキャラクターがたくさんいるので、戦略によって幅広くキャラを使い分けたり、逆に特定のキャラを極めたりといった楽しみ方もできます。
例えば、あるキャラクターは敵を倒すと必殺技をもう一度打てるようになるという特徴があるのですが、慣れると集団戦で体力の低い相手を「踏み台」にして、必殺技を打ちまくって相手チームを一網打尽にできるようになったりします。ちなみに僕はよくその踏み台にされるのですが…
ということで伝説対決の話はこのくらいにして、今回はAWS環境における踏み台についてお伝えしたいと思います。
一般的に、外部公開しているサーバーが不特定多数のSSH接続を直接受け付けてしまう状態は、セキュリティ上望ましくありません。そこで保守作業用に踏み台サーバーを設けることが定石となっています。
踏み台サーバー自体も使いたいときにクラッシュしていたり、AWSのメンテナンスで停止されるといった事態を考慮し冗長化したいという要求も多くいただきます。
AWS環境におけるSSH踏み台サーバーの冗長化は、ELB（Elastic Load Balancing）を利用することで手軽に実現できます。しかしながら、ELBでは動的に外部アクセス用のIPアドレスが変更されることがあるため、社内ネットワークの管理ルールなどによりクライアント端末からの不特定IPアドレスへのアクセスが禁止されている場合など、ELBを用いて冗長化できないケースもあります。
今回はそのようなケースの対策として、ELBを利用せず、固定グローバルIPアドレスであるEIP（Elastic IPアドレス）を使用してSSH踏み台サーバーの冗長化を実現したいと思います。
SSH踏み台サーバーを使用するケース
AWS VPC（Virtual Private Cloud）にあるプライベート環境のEC2（Elastic Compute Cloud）/RDS（Relational Database Service）へアクセスするための方法の一つとして、SSH踏み台サーバーを使用するケースが考えられます。
他の方法としては、AWSが提供する「AWS Systems Manager セッションマネージャー」という機能があり、これを使えば踏み台を使わずともプライベート環境のサーバーへログインできます。ただし、セッションマネージャーだと、EC2にはアクセスできるがRDSにはアクセスできなかったり、CLIアクセス限定なのでWindowsサーバーのRDP接続やDBのODBC接続ができない、といった制約があります。
SSH踏み台サーバーであれば、SSHポート転送機能を使用することでクライアントPCから直接GUI操作したり、ADサーバーと連携して作成したアカウントでログインすることが可能です。
設定
設定手順は4つです。
社内ネットワークの管理ルールで不特定IPアドレスへの22番ポートアクセスが禁止（※）されていることを想定し、固定グローバルIPアドレスであるEIPをSSH踏み台サーバーに割り当てた上で冗長化します。
※社内ネットワーク管理者に、「外部接続許可申請」などで対象EIPの通信を許可してもらうことを前提とします。
SSH踏み台サーバー（EC2）の構築
冗長構成とするため、SSH踏み台サーバーを2台構築します。
別々のAZ(Avalavirity Zone)に分け、2台にそれぞれEIPを割り当てます。
OSはAmazon linux2やCentOSなど、要件に応じて選択します。
EIPを固定化するため、EIPに紐づけられているENI（Elastic Network Interface）も同じものを使い続けます。EC2削除に伴ってENIを自動削除しないように設定しましょう。
Amazon Route53の設定
Route53の「DNSフェイルオーバー」機能を使用して、SSH踏み台サーバーの自動切り替え/自動切り戻し設定をします。前提として、Route53のホストゾーンにパブリックドメインが登録されている必要があります（設定例では、example.co.jpを作成）。
まず、1号機（primary）/2号機（secondary）を自動で切り替えるため、1号機に対してのみ設定するRoute53ヘルスチェックを作成します。このヘルスチェックにより、1号機のEIPへの通信がNGとなった場合、2号機のEIPへ自動的に切り替わります。1号機のEIPへの通信がOKとなった場合は、自動的に切り戻しされます。ヘルスチェックのアラート設定として、SNS（Simple Notification Service）と連携することも可能です。
ヘルスチェック作成時、対象となるIPアドレスはSSH踏み台1号機に関連づけているEIPを指定し、監視ポートはsshの22を指定しています。
上記画面で「次へ」をクリックすると、ヘルスチェックのアラート設定画面に遷移します。必要に応じてアラート設定をして「ヘルスチェックの作成」をクリックします。
次に、1号機（primary）/2号機（secondary）のEIPを、それぞれ同一のSSH踏み台サーバー用DNS名に紐づけます。つまり、同じDNS名を異なるIPアドレスで2レコード分登録します。ルーティングポリシーはどちらも「フェイルオーバー」です。1号機のレコードに対してのみ、作成したRoute53ヘルスチェックを指定します。
画像では、「ssh.example.co.jp」に対して、2レコードを作成しています。
以上でRoute53の設定は完了です。
この時点で、SSH踏み台1号機の22ポートに異常が発生した場合、DNS名に紐付くIPアドレスが2号機へ自動的に切り替わります。切り替わりのイメージは以下のとおりです。
セキュリティグループの設定
Route53からのヘルスチェック通信をSSH踏み台サーバーが受け取れるようにするためには、SSH踏み台サーバーに対してセキュリティグループを設定し、明示的にヘルスチェック通信元IPアドレスからの通信を許可する必要があります。
ヘルスチェック送信元IPアドレスは以下のAWS CLIコマンドで求められますので、そのIPアドレスの範囲を設定すればOKです。IPアドレスの範囲は変わる可能性があるため、AWS CLIコマンドにて最新の情報を取得してください。
$ aws route53 get-checker-ip-ranges --query 'CheckerIpRanges[]'
[
"15.177.0.0/18",
"54.183.255.128/26",
"54.228.16.0/26",
"54.232.40.64/26",
"54.241.32.64/26",
"54.243.31.192/26",
"54.244.52.192/26",
"54.245.168.0/26",
"54.248.220.0/26",
"54.250.253.192/26",
"54.251.31.128/26",
"54.252.79.128/26",
"54.252.254.192/26",
"54.255.254.192/26",
"107.23.255.0/26",
"176.34.159.192/26",
"177.71.207.128/26"
]
実際にヘルスチェックで使用されるIPアドレスは、上記IPアドレスの中からランダムでいくつか選択されます。それらのIPアドレスはAWS側の都合で通知なしで変更されることがあるため、上記のコマンドで取得したIPアドレスの範囲をすべて設定する必要があります。
Amazon SNSの設定
上記一覧のヘルスチェック送信元IPアドレスは、AWS側の都合で変更されることがあります。
IPアドレスの範囲が変更された場合、セキュリティグループで許可した範囲外のIPアドレスからヘルスチェック通信が来る可能性があるので、場合によってはSSH踏み台には何も異常がないのにヘルスチェック上はエラーとなり、Route53の自動フェイルオーバーが発生してしまうこともあり得ます。
そうならないようにするためには、ヘルスチェック送信元IPアドレスの変更に合わせてセキュリティグループを修正する必要があります。そのために、Amazon SNS(Simple Notification Service)にてIPアドレスの範囲が変わった際のメール受信設定をします。
ただし、メールが来たからといって、必ずしもヘルスチェック送信元IPアドレスが変わっているわけではありません。なぜなら、設定できる通知条件はあくまで「AWSが保持するIPアドレスの範囲が変わった場合」であり、「ヘルスチェック送信元IPアドレスの範囲のみが変わった場合」に限定することが現状はできないためです。通知を受け取ったら、通信元IPアドレスが変わったかどうか都度AWS CLIコマンドにて確認する必要があります。
通知を受け取り、実際にIPアドレスの範囲が変わったことを確認できたら、SSH踏み台のセキュリティグループを修正します。
通知設定に関しては、下記URL内の項目「AWS の IP アドレス範囲の通知」をご参照ください。
https://docs.aws.amazon.com/ja_jp/general/latest/gr/aws-ip-r...まとめ
ELBのような動的IPアドレスを外部アクセス用IPアドレスとしてSSH踏み台サーバーにアタッチできない場合でも、EIPとRoute53により固定IPアドレスを自動で切り替えることで、SSH踏み台サーバーの冗長化を実現することが可能です。
SSH踏み台サーバーを冗長化したいが、社内ルールなどの制約により動的にIPアドレスが変わってしまうELBが使えない、とお困りの場合に今回の記事が参考になれば幸いです。
その他、AWSを使う上での構築/セキュリティ対策全般でお悩みがございましたら、ぜひ当社にお声掛けください。
