セカンダリ IP アドレスを使用して EC2 インスタンスに接続する際の問題のトラブルシューティング方法を教えてください。
最終更新日: 2020 年 11 月 24 日
セカンダリ IP アドレスを使って Amazon Elastic Compute Cloud (Amazon EC2) インスタンスに接続できません。これを解決するにはどうすればよいですか?
簡単な説明
セカンダリ IP アドレスを使用して SSH 経由でインスタンスに接続するには、インスタンスが次の前提条件を満たすようにしてください。
- プライベートサブネットでインスタンスを起動した場合は、セカンダリプライベート IP アドレスを使用して SSH 経由で接続します。ネットワークインターフェイス用のサブネットの IPv4 CIDR ブロック範囲から、セカンダリ IPv4 アドレスを必ず選択してください。
- パブリックサブネットでインスタンスを起動した場合は、インスタンスにアタッチされたセカンダリプライベート IP アドレスに Elastic IP アドレスを割り当てます。
- EC2 インスタンスのオペレーティングシステムがセカンダリプライベート IP アドレスを認識していることを確認します。
Amazon Linux の場合は、「セカンダリプライベート IPv4 アドレスを認識するようにインスタンスのオペレーティングシステムを設定する」を参照してください。
Ubunto の場合は、「Ubuntu EC2 インスタンスでセカンダリネットワークインターフェイスを動作させるにはどうすればよいですか?」を参照してください。
他の Linux ディストリビューションについては、ご利用のディストリビューションのネットワーク設定ドキュメントを参照してください。
インスタンスがこれらの前提条件を満たしている場合は、次の手順を実行して SSH 経由の接続のトラブルシューティングを行います。
- 詳細メッセージをオンにして SSH 経由で接続し、エラーを特定します。
- システムログを確認して、エラーを探します。
解決方法
注: 開始する前に、一般的な接続の前提条件を確認してください。
詳細メッセージをオンにして SSH 経由で接続し、エラーを特定する
手順の詳細については、「SSH を使用した Amazon EC2 Linux インスタンスへの接続問題に関するトラブルシューティングはどのように行えばいいですか?」を参照してください。
システムログを確認してエラーを探す
警告: この手順を開始する前に、次に注意してください。
- インスタンスを停止すると、インスタンスストアボリュームのデータがすべて消去されます。インスタンスストアボリューム上の保持したいデータを必ずバックアップしてください。詳細については、「インスタンスのルートデバイスタイプの判別」を参照してください。
- インスタンスを停止して開始すると、インスタンスのパブリック IP アドレスが変更されます。インスタンスに外部トラフィックをルーティングするときは、パブリック IP アドレスではなく、Elastic IP アドレスを使用することをお勧めします。
上記の手順で問題が解決しない場合は、インスタンスのシステムログを確認します。
1. Amazon EC2 コンソールを開きます。
2. ナビゲーションペインで [インスタンス] を選択し、接続しようとしているインスタンスをクリックします。
3. [インスタンスの状態 ]、[インスタンスを停止] の順に選択してから、[停止] をクリックします。インスタンス ID をメモします。
注: 新しい EC2 エクスペリエンスを使用していない場合は、接続先のインスタンスを選択し、[アクション]、[インスタンスの状態]、[停止]、[停止] の順にクリックします。
4. 停止したインスタンスからルート Amazon Elastic Block Store (Amazon EBS) ボリュームをデタッチします。停止したインスタンスからデタッチする前に、ルート EBS ボリュームのデバイス名を書き留めます。デバイス名は、トラブルシューティング後にボリュームを再アタッチするときに必要です。
6. 元のインスタンスと同じアベイラビリティーゾーンで、新しい EC2 インスタンスを起動します。新しいインスタンスは「レスキュー」インスタンスになります。
注: Amazon Linux 2 インスタンスをレスキューインスタンスとして使用するのがベストプラクティスです。EBS ボリュームの UUID または名前が同じであるため、Amazon Linux 2 インスタンスを使用すると、アタッチされた EBS ボリュームからレスキューインスタンスが起動できなくなります。
7. レスキューインスタンスが起動したら、ナビゲーションペインで [ボリューム] をクリックし、障害が発生したインスタンスの接続解除したルートボリュームを選択します。
注: 障害のあるインスタンスのルートボリュームに Marketplace コードがあり、レスキューインスタンスが Amazon Linux でない場合は、ルート EBS ボリュームをアタッチする前にレスキューインスタンスを停止してください。例えば、公式の RHEL または CentOS AMI からインスタンスを起動した場合は、インスタンスに Marketplace コードがある場合があります。
8. [アクション]、[ボリュームのアタッチ] の順に選択します。
9. ナビゲーションペインで [インスタンス] を選択してから、レスキューインスタンスをクリックします。
10. [インスタンスの状態]、[ インスタンスを開始] の順に選択します。
注: 新しい EC2 エクスペリエンスコンソールを使用していない場合は、接続先のインスタンスを選択してから、[アクション]、[インスタンスの状態]、[開始] の順にクリックします。
11. SSH を使用してレスキューインスタンスに接続します。
12. 次のコマンドを実行して、EBS ボリュームがレスキューインスタンスに正常にアタッチされたことを確認します。次のコマンドでは、ボリュームは /dev/sdf としてアタッチされます。
$ lsblk
以下にコマンドの出力の例を示します。
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvda 202:0 0 20G 0 disk
└─xvda1 202:1 0 20G 0 part /
xvdf 202:80 0 100G 0 disk
13. 次のコマンドを使用してマウントポイントディレクトリを作成してから、アタッチされたボリュームをレスキューインスタンスにマウントします。以下の例のマウントポイントディレクトリは /test です。
$ sudo su
$ mkdir /test
$ mount /dev/xvdf1 /test
$ df -h
$ cd /test
14. システムログおよび認証関連ログで、アクセスを試行した時刻のタイムスタンプが付いたエラーを特定します。
Amazon Linux、RHEL、CentOS
$ sudo cat /test/var/log/messages
Amazon Linux、RHEL、CentOS (認証関連の問題)
$ sudo cat /test/var/log/secure
Ubuntu、Debian (システムログ)
$ sudo cat /test/var/log/syslog
Ubuntu、Debian (認証関連の問題)
$ sudo cat /test/var/log/auth.log
15. 設定を確認し、エラーに対処したら、レスキューインスタンスから EBS ルートボリュームをマウント解除してデタッチします。
$ umount /test
16. ボリュームを元のインスタンスにアタッチします。デバイス名は /dev/xvda です。