セカンダリ IP アドレスを使用して EC2 Linux インスタンスへの接続問題をトラブルシューティングする方法を教えてください。

最終更新日: 2021 年 4 月 28 日

セカンダリ IP アドレスを使って Amazon Elastic Compute Cloud (Amazon EC2) Linux インスタンスに接続できません。これを解決するにはどうすればよいですか?

簡単な説明

セカンダリ IP アドレスを使用して SSH 経由でインスタンスに接続するには、インスタンスが次の前提条件を満たすようにしてください。

インスタンスがこれらの前提条件を満たしている場合は、次の手順を実行して SSH 経由の接続のトラブルシューティングを行います。

  1. 詳細メッセージをオンにして SSH 経由で接続し、エラーを特定します。
  2. システムログを確認して、エラーを探します。

解決方法

注: 開始する前に、一般的な接続の前提条件を確認してください。

詳細メッセージをオンにして SSH 経由で接続し、エラーを特定する

手順の詳細については、「SSH を使用した Amazon EC2 Linux インスタンスへの接続問題に関するトラブルシューティングはどのように行えばいいですか?」を参照してください。

システムログを確認してエラーを探す

上記の手順で問題が解決しない場合は、インスタンスのシステムログを確認します。次の 2 つの方法のいずれかを用いて、インスタンス上のログにアクセスできます。

方法 1: EC2 シリアルコンソールを使用する

Linux 用 EC2 シリアルコンソールを有効にした場合は、それを使用して、サポートされている Nitro ベースのインスタンスタイプのトラブルシューティングを行うことができます。シリアルコンソールは、起動の問題、ネットワーク設定、および SSH 設定の問題のトラブルシューティングに役立ちます。シリアルコンソールは、正常に動作するネットワーク接続を必要とすることなく、インスタンスに接続します。Amazon EC2 コンソールまたは AWS コマンドラインインターフェイス (AWS CLI) を使用して、シリアルコンソールにアクセスできます。

シリアルコンソールを使用する前に、アカウントレベルでコンソールへのアクセスを許可し、IAM ユーザーにアクセス権を付与する AWS Identity and Access Management (IAM) ポリシーを作成する必要があります。また、シリアルコンソールを使用するすべてのインスタンスには、パスワードベースのユーザーを 1 つ以上含める必要があります。インスタンスが到達不能で、シリアルコンソールへのアクセスを設定していない場合は、方法 2 の手順に従います。Linux 用 EC2 シリアルコンソールの設定の詳細については、EC2 シリアルコンソールへのアクセスを設定するをご参照ください。

注: AWS CLI コマンドの実行時にエラーが発生した場合は、AWS CLI の最新バージョンを使用していることを確認してください。

方法 2: レスキューインスタンスを使用してログにアクセスする

警告: この手順を開始する前に、次に注意してください。

1.    Amazon EC2 コンソールを開きます。

2.    ナビゲーションペインで [Instances] (インスタンス) を選択し、接続しようとしているインスタンスをクリックします。

3.    [Instance State] (インスタンスの状態)、[Stop Instance] (インスタンスを停止) の順に選択してから、[Stop] (停止) を選択します。[Instance ID] (インスタンス ID) を書き留めます。

注: 新しい EC2 エクスペリエンスを使用していない場合は、接続先のインスタンスを選択します。その後、[Actions] (アクション)、[Instance State] (インスタンス状態)、[Stop] (停止)、[Stop] (停止) の順に選択します。

4.    停止したインスタンスからルート Amazon Elastic Block Store (Amazon EBS) ボリュームをデタッチします。ルート EBS ボリュームのデバイス名を書き留めます。デバイス名は、トラブルシューティング後にボリュームを再アタッチするときに必要です。

5.    元のインスタンスと同じアベイラビリティーゾーンで、新しい EC2 インスタンスを起動します。新しいインスタンスは「レスキュー」インスタンスになります。

注: Amazon Linux 2 インスタンスをレスキューインスタンスとして使用するのがベストプラクティスです。EBS ボリュームの UUID または名前が同じであるため、Amazon Linux 2 インスタンスを使用すると、アタッチされた EBS ボリュームからレスキューインスタンスが起動できなくなります。

6.    レスキューインスタンスが起動したら、ナビゲーションペインで [Volumes] (ボリューム) をクリックし、障害が発生したインスタンスの接続解除したルートボリュームを選択します。

注: 障害のあるインスタンスのルートボリュームに Marketplace コードがあり、レスキューインスタンスが Amazon Linux でない場合は、ルート EBS ボリュームをアタッチする前にレスキューインスタンスを停止してください。例えば、公式の RHEL または CentOS AMI からインスタンスを起動した場合は、インスタンスに Marketplace コードがある場合があります。

7.    [Actions] (アクション)、[Attach Volume] (ボリュームのアタッチ) の順に選択します。

8.    ナビゲーションペインで [Instances] (インスタンス) を選択してから、レスキューインスタンスをクリックします。

9.    [Instance state] (インスタンスの状態)、[Start instance] (インスタンスを開始) の順に選択します。

注: 新しい 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 です。

SSH クライアントを使用して Linux インスタンスに接続する

この記事はお役に立ちましたか?

フィードバックを送信

請求に関するサポートまたは技術サポートが必要ですか?

AWS サポートにお問い合わせください