一般的なEC2インスタンスの接続問題の診断と解決方法

EC2の接続問題は、通常、インスタンス、セキュリティグループ、サブネットルール、ルートテーブル、ゲートウェイパスのいずれかのブロックされたホップに起因します。EC2インスタンスにSSH接続できない、アプリケーションポートに到達できない、またはインスタンス間で接続できない場合は、ランダムにルールを変更するのではなく、ネットワークパスを順に確認してください。

以下のチェック項目は、トラフィックがどこで停止しているかを特定し、アクセスを復元するための最小限の修正を適用するのに役立ちます。

EC2接続問題の一般的な原因

接続問題は、AWSネットワーキングスタックのさまざまなレイヤーから発生する可能性があります。根本原因を特定するには、以下の要素を組み合わせて確認する必要があります。

セキュリティグループ: これらは、Elastic Network Interfaceにアタッチされるステートフルな仮想ファイアウォールです。インスタンスレベルでのインバウンドおよびアウトバウンドトラフィックを制御します。
ネットワークアクセスコントロールリスト（NACL）: NACLはサブネットレベルで動作し、サブネットに出入りするトラフィックに対して追加のステートレスフィルタリングを提供します。
ルートテーブル: これらは、サブネットトラフィックの行き先（VPC内のローカル、インターネットゲートウェイ、NATゲートウェイ、トランジットゲートウェイなど）を決定します。
インスタンスの状態とネットワーク設定: EC2インスタンス自体の問題（停止している、ネットワークインターフェース設定が正しくないなど）。
インターネットゲートウェイ（IGW）/ NATゲートウェイ: インスタンスがインターネットにアクセスする必要がある場合、IGW（パブリックサブネット用）またはNATゲートウェイ（プライベートサブネット用）の設定が重要です。
VPCピアリング / トランジットゲートウェイ: VPC間で接続する場合、これらのVPC間接続サービスが正しく設定されている必要があります。

段階的な診断と解決

症状から始めて、パケットパスを追跡します。

1. インスタンスの状態と基本的なネットワーク到達可能性を確認する

複雑なネットワーク設定に入る前に、インスタンス自体が正常な状態であり、基本的なネットワーク設定が行われていることを確認します。

インスタンスのステータスチェック: EC2コンソールでインスタンスを選択し、「ステータスチェック」タブを確認します。システムチェックとインスタンスチェックの両方が合格している必要があります。
パブリックIPとプライベートIP: インスタンスに期待するアドレスがあることを確認します。パブリックサブネット内のインスタンスでも、IPv4経由で直接インターネットにアクセスするには、パブリックIPv4アドレスまたはElastic IPが必要です。
オペレーティングシステムのリスナー: ネットワークパスが開いているがポートがまだ失敗する場合は、インスタンス上でサービスがリッスンしていることを確認します。たとえば、SSHデーモン設定を変更していない限り、SSHはTCP 22でリッスンする必要があります。
DNS解決: IPで接続できるがホスト名のルックアップが失敗する場合は、VPC DNS設定、カスタムリゾルバー、およびLinuxの/etc/resolv.confを確認します。

2. セキュリティグループを調査する

セキュリティグループは、EC2インスタンスとの間のトラフィックを制御するステートフルファイアウォールです。これらは接続問題の非常に一般的な原因です。

2.1. インバウンドルール

インスタンスに接続できない場合（LinuxのSSHやWindowsのRDPなど）:

EC2インスタンスにアタッチされているセキュリティグループを確認します。
インバウンドルールを確認します: 必要なTCPポートをソースIPまたは信頼できるCIDRから許可します。管理アクセスには、0.0.0.0/0ではなく、現在のパブリックIPを<your_ip>/32として使用することをお勧めします。

例: 自分のIPアドレスからのSSHアクセスを許可するには:

タイプ: SSH
プロトコル: TCP
ポート範囲: 22
ソース: <your_ip>/32

2.2. アウトバウンドルール

インスタンスが外部リソースに到達できない場合（パッケージのダウンロード、他のAWSサービスへの接続など）:

EC2インスタンスにアタッチされているセキュリティグループを確認します。
アウトバウンドルールを確認します: デフォルトでは、セキュリティグループはすべてのアウトバウンドトラフィックを許可します。カスタムアウトバウンドルールが作成されている場合は、宛先ポートとIPへの必要なトラフィックが許可されていることを確認します。

例: すべてのアウトバウンドトラフィックを許可するには:

タイプ: すべてのトラフィック
プロトコル: すべて
ポート範囲: すべて
宛先: 0.0.0.0/0

3. ネットワークアクセスコントロールリスト（NACL）を調査する

NACLは、サブネットレベルで動作するステートレスファイアウォールです。セキュリティグループやインスタンスに到達する前にトラフィックをフィルタリングします。

インスタンスのサブネットに関連付けられているNACLを特定します。
インバウンドルールを確認します: NACLはルール番号順に評価されます。ソースIPから必要なポートでのトラフィックを許可するインバウンドルールがあることを確認します。
アウトバウンドルールを確認します: 同様に、アウトバウンドルールが宛先へのトラフィックを許可していることを確認します。
ステートレスの性質: NACLは確立された接続を記憶しません。フローの両側にインバウンドルールとアウトバウンドルールが必要です。ラップトップからのSSHの場合、サブネットNACLには通常、自分のIPからのインバウンドTCP 22と、戻りトラフィックのための自分のIPへのアウトバウンドエフェメラルポートが必要です。エフェメラルポートの範囲はオペレーティングシステムとクライアントによって異なるため、環境に適した範囲を使用します。
ルール番号: ルール番号が小さいほど先に評価されます。明示的な拒否ルール（例：特定のトラフィックを拒否するルール100）と許可ルール（例：より広いトラフィックを許可するルール200）を慎重に使用します。

4. ルートテーブルを確認する

ルートテーブルは、サブネットからのネットワークトラフィックの送信先を決定します。ルーティングが正しくないと、トラフィックが宛先に到達できなくなる可能性があります。

インスタンスのサブネットに関連付けられているルートテーブルを見つけます。
デフォルトルートを確認します: パブリックサブネット内のインスタンスがインターネットにアクセスするには、インターネットゲートウェイ（IGW）を指すルート0.0.0.0/0が必要です。
```
宛先 | ターゲット
----------------|--------
10.0.0.0/16     | local
0.0.0.0/0       | igw-xxxxxxxxxxxxxxxxx
```
プライベートサブネットとNATゲートウェイ: プライベートサブネット内のインスタンスがアウトバウンドのインターネット接続を開始するには、そのサブネットのルートテーブルにNATゲートウェイまたはNATインスタンスを指す0.0.0.0/0ルートが必要です。
```
宛先 | ターゲット
----------------|--------
10.0.0.0/16     | local
0.0.0.0/0       | nat-xxxxxxxxxxxxxxxxx
```
VPCピアリング、トランジットゲートウェイ、またはVPN: インスタンスが別のVPCまたはオンプレミスネットワークと通信する必要がある場合は、ルーティングが必要な両側でリモートCIDRブロックのルートを正しいターゲットに追加します。

5. インターネットゲートウェイ（IGW）とNATゲートウェイの接続をトラブルシューティングする

インターネットゲートウェイ

*   IGWが作成され、VPCにアタッチされていることを確認します。
*   パブリックサブネットのルートテーブルにIGWを指す`0.0.0.0/0`ルートがあることを確認します。
*   インスタンスにパブリックIPアドレスまたはElastic IPアドレスが割り当てられていることを確認します。
*   セキュリティグループとNACLのルールで、必要なインバウンドおよびアウトバウンドトラフィックが許可されている必要があります。明確な理由と補完的な制御がない限り、機密性の高いポートをインターネット全体に開放しないでください。

NATゲートウェイ

*   NATゲートウェイが作成され、パブリックサブネットにあることを確認します。
*   NATゲートウェイにElastic IPアドレスが関連付けられていることを確認します。
*   プライベートサブネットのルートテーブルにNATゲートウェイを指す`0.0.0.0/0`ルートがあることを確認します。
*   プライベートおよびパブリックサブネットのNACLルールで、アウトバウンド接続と戻りトラフィックが許可されている必要があります。NATゲートウェイはセキュリティグループを使用しません。

6. VPCピアリングとトランジットゲートウェイ

VPC間で接続の問題が発生している場合:

VPCピアリング:
- ピアリング接続がアクティブであり、両方のVPCで受け入れられていることを確認します。
- 両方の VPCのルートテーブルに、ピアリングされたVPCのCIDRブロックへのトラフィックを許可するルートが追加されていることを確認します。
- 両方の VPCのセキュリティグループとNACLで、必要なIP範囲間のトラフィックが許可されていることを確認します。
トランジットゲートウェイ:
- トランジットゲートウェイが作成され、関連するVPCがアタッチされていることを確認します。
- トランジットゲートウェイのルートテーブルを確認して、VPCアタッチメント間でトラフィックが正しくルーティングされていることを確認します。
- 各VPC内のルートテーブルにも、他のVPC宛てのトラフィックに対してトランジットゲートウェイを指すルートがあることを確認します。
- 各VPC内のセキュリティグループとNACLで、VPC間トラフィックが許可されている必要があります。

7. AWSネットワーク到達可能性ツールの使用

AWSはネットワーク問題の診断に役立つツールを提供しています。

VPC Reachability Analyzer: このツールは、サポートされているソースと宛先リソース間の到達可能性を分析します。セキュリティグループ、NACL、ルートテーブル、ゲートウェイ、および関連するネットワーク設定によって引き起こされるパスの失敗を特定できます。
VPCフローログ: 接続障害を直接診断するわけではありませんが、VPCフローログはVPC内のネットワークインターフェースとの間のIPトラフィックに関する情報をキャプチャします。これらのログを分析すると、ブロックされたトラフィックや予期しないトラフィックのパターンが明らかになり、セキュリティグループやNACLの設定ミスの特定に役立ちます。

8. その他の潜在的な問題

Elastic Network Interface（ENI）: ENIがインスタンスにアタッチされ、正しく設定されていることを確認します。
サブネットのルートテーブル関連付け: サブネットが目的のルートテーブルに正しく関連付けられていることを確認します。
DNS設定: カスタムDNSを使用している場合は、正しく解決されていることを確認します。デフォルトのVPC DNSの場合は、VPCでDNS解決が有効になっていることを確認します。
プロキシサーバー: インスタンスがプロキシを使用するように設定されている場合は、プロキシ自体がアクセス可能で正しく設定されていることを確認します。

接続問題を防ぐためのベストプラクティス

最小権限: セキュリティグループとNACLを最小限の必要な権限で設定します。絶対に必要な場合を除き、機密性の高いポートに0.0.0.0/0を使用しないでください。また、他の手段で保護されていることを確認します。
タグ付け: ネットワークリソース（VPC、サブネット、セキュリティグループ、ルートテーブル）に一貫してタグを付け、その目的と関連するインスタンスを簡単に識別できるようにします。
ドキュメント化: ネットワークトポロジ、IPアドレス指定スキーム、セキュリティルールの明確なドキュメントを維持します。
定期的な監査: セキュリティグループとNACLのルールを定期的に確認し、それらが依然として関連性があり安全であることを確認します。
AWSツールの活用: VPC Reachability AnalyzerとVPCフローログを積極的な監視とトラブルシューティングに活用します。

まとめ

EC2の接続が切れた場合は、インスタンスの状態、リスナー、セキュリティグループ、NACL、ルートテーブル、ゲートウェイ、リモート側のルールの順にパスを追跡します。一度に1つのレイヤーを変更し、再度テストします。これにより、修正範囲が狭くなり、次の障害の診断がはるかに容易になります。