この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので十分ご注意ください。
社内研修のハンズオン実施中に思わぬところで躓いてしまったので、
本記事として共有します。
※今回はトラブルシューティングの紹介のため、ハンズオン形式ではありませんが
初学者の方はご自身の端末でも試せる範囲で一度試してみると良いかと思います。
まずは現状の確認から入りたいと思います。
【事象】
・作成済みのEC2にSSH接続できない(ステータスは「起動中」)
⇒厳密には、EC2インスタンスの詳細に表示されるパブリックIPアドレスを
Tera Termのホストに打ち込んでも画面遷移が行われず、
「ホストに接続できません」と表示され、Tera Termが終了する。
【インスタンスの状態について】
・前日作成したインスタンス。
・検証で使用していたため、一度は接続実績あり。
・検証に時間がかかりそうだったので、その日は該当のインスタンスを停止し、
翌日インスタンス起動時に事象発生。
【一般的な原因と思われる箇所】
1.パブリックIPが振られていない
2.誤ったセキュリティグループが割り当てられている
3.セキュリティグループの設定に誤りがある。
【実際の原因/対処】
・セキュリティグループにマイIPを設定していたが、接続環境が前日と異なる環境から
接続を行おうとしたため、接続元IPが相違していた。
マイIPの更新を行うことで事象解消を確認した。
当たり前の部分もありますが、
今後同じミスをしないよう一つずつ確認していきたいとおもいます。
1.パブリックIPが振られていない
当然ですが、IPアドレスがなければTera Termからの接続自体できません。
(本事象も発生していません)
インスタンスのパブリックIPアドレスの確認方法は以下となります。
[AWSコンソール] > [EC2] > [インスタンス] > 表示されたインスタンスから対象のインスタンスを選択 > [詳細]タブ > [パブリックIPv4アドレス]
2.誤ったセキュリティグループが割り当てられている
次に正しいセキュリティグループかどうかを確認します。
同じくインスタンスを選択して、セキュリティタブから確認できます。
[AWSコンソール] > [EC2] > [インスタンス] > 表示されたインスタンスから対象のインスタンスを選択 > [セキュリティ]タブ > [セキュリティグループ]
EC2用に作成したセキュリティグループは「SG-EC2-」として
作成したので、想定したセキュリティグループが割り当てられています。
3.セキュリティグループの設定に誤りがある。
先ほどのセキュリティグループを選択すると対象の詳細画面に遷移します。
割り当てられたセキュリティグループの設定内容を確認します。
今回確認したいのはインバウンドルールの設定内容なので、
画面右側にある「インバウンドルールの編集」を選択します。
上記の「SSH」のIPアドレスが原因でした。
古いIPを削除して、再度「マイIP」選択し、ルールを保存して事象解消しました。
(IPが変更されていない場合は、保存ボタン押下時に「変更していません」と
表示されるので、別の箇所が原因の可能性があります。)
【事象解消後の再現検証/マイIPの確認】
せっかくなので、再現確認とマイIPについてもう少し見ていきます。
実際にインスタンスに振られているIPは以下から確認できます。
※自分のローカル端末から「IPCONFIG」で確認できるIPと「マイIP」として
設定されているIPは異なります。「tracert」コマンドでも同様でした。
機会があればもう少しこのあたりも調べてみようと思います。
・EC2にログイン後、「w -i」を実行
ちなみにコマンドの意味は以下となります。
「w」コマンド ： 現在Linuxにログインしているユーザー情報を表示する。
「-i」オプション ：ログイン元をホスト名の代わりにipアドレスで表示する。
設定したマイIPと該当のEC2にログインしているIPが同一であることを確認できました。
・ローカルで使用しているIPを変更する。
今回は現在利用中のWifiを切り替えました。
Wifi切り替え後、対象のEC2インスタンスへの接続を行ったところ、
当初の事象の再発を確認しました。(Tera Term接続不可)
その後、マイIPを更新して、接続可能な状態となりました。
【まとめ】
今まで、作成したインスタンスの日跨ぎでの使用をしていなかったので、
原因特定までに時間がかかってしまいました。
AWS内の機能だけでなく、構築環境全般にも気を付けながら学習を進めたいと思います。