EC2インスタンスの接続問題の診断：セキュリティグループとネットワークACL

EC2インスタンスが実行中にもかかわらず、SSH、RDP、またはアプリのトラフィックがタイムアウトする場合、問題は通常、インスタンス周辺のネットワークパスにあります。EC2接続を診断するには、最初にルートテーブル、次にサブネットネットワークACL、最後にインスタンスセキュリティグループを確認します。

これらの制御の階層と機能を理解することが重要です。セキュリティグループはインスタンスレベルのステートフルファイアウォールとして機能し、NACLはサブネットレベルのステートレスファイアウォールとして機能します。これらのコンポーネントのいずれかで設定ミスがあったり、ルーティングパスが正しくないと、予期されるトラフィックが即座にブロックされ、イライラする接続タイムアウトが発生します。

EC2接続制御の三本柱

具体的な設定に入る前に、各コンポーネントがEC2インスタンスへのトラフィックパスで果たす役割を理解することが重要です。

ルートテーブル: 宛先IPアドレスに基づいてネットワークトラフィックの転送先を決定します。インターネットまたはクライアントIP宛てのトラフィックが正しいサブネットゲートウェイに到達できない場合、接続は失敗します。
ネットワークACL（NACL）: サブネット全体にルールを適用します。これらはステートレスであり、インバウンドとアウトバウンドの両方のトラフィックを明示的に許可する必要があります。ルールは番号の小さいものから順に処理され、最初に一致したルールで停止します。
セキュリティグループ（SG）: EC2インスタンスのElastic Network Interface（ENI）に直接ルールを適用します。これらはステートフルであり、インバウンドトラフィックを許可すると、戻りのアウトバウンドトラフィックは自動的に許可されます。

ステップ1: VPCルートテーブルの確認

最初の診断チェックは、トラフィックがEC2インスタンスが存在するサブネットに到達するためのパスが存在することを常に確認することです。

インバウンドルーティングの確認

パブリックインターネットから到達可能なインスタンス（例：SSH/RDP経由）の場合：

目標: パブリックインスタンスを含むサブネットに**インターネットゲートウェイ（IGW）**へのデフォルトルートがあることを確認します。
アクション: VPCコンソールに移動し、ルートテーブルを選択し、インスタンスのサブネットに関連付けられたルートテーブルを確認します。次のようなエントリを探します：
```
宛先: 0.0.0.0/0 | ターゲット: igw-xxxxxxxx
```

アウトバウンドルーティングの確認（ステートフルな問題の場合）

SGはステートフルですが、特に戻りトラフィックや外部サービスへの接続を開始するインスタンスの場合、アウトバウンドパスを確認することが重要です。

アクション: インスタンスがプライベートサブネットにある場合、インターネットに到達するためにNATゲートウェイまたはNATインスタンスへのルートがあることを確認します。パブリックサブネットにある場合は、0.0.0.0/0をIGWにルーティングする必要があります。

ヒント: 同じVPC内のサブネット間のトラフィックは、通常、暗黙のlocalルートを使用します。そのトラフィックが失敗した場合は、ルートテーブルを非難する前に、セキュリティグループ、NACL、ホストファイアウォール、および宛先がICMPを許可しているかどうかを確認します。

ステップ2: ネットワークACLの検査（サブネットレベル）

NACLはサブネットレベルで動作し、ステートレスであるため、しばしば見落とされます。よくあるエラーは、インバウンドトラフィックを許可するが、戻りのアウトバウンドトラフィックを明示的に許可するのを忘れることです。

インバウンドルールの確認

インバウンド接続試行（例：ポート22のSSH）の場合：

インスタンスのサブネットに関連付けられたNACLを特定します。
インバウンドルールを確認します。
使用している特定のポートとプロトコルを許可するルールが存在することを確認します（例：ルール100: タイプ: SSH (22)、プロトコル: TCP、送信元: 0.0.0.0/0）。

アウトバウンドルールの確認（ステートレスの落とし穴）

ここでほとんどのNACL接続の問題が発生します。

アウトバウンドルールを確認します。
インバウンドSSH（ポート22）を許可した場合、インスタンスは高ポート（エフェメラルポート）範囲、通常1024-65535でクライアントにトラフィックを送り返す必要があります。
アクション: アウトバウンドルールが、関連する宛先ポート範囲（クライアントが接続を開始する場合は多くの場合1024-65535）へのトラフィックを明示的に許可していることを確認します。

インバウンドSSHアクセスのNACLルール例:

インバウンドルール:

ルール番号	タイプ	プロトコル	ポート範囲	送信元	許可/拒否
100	SSH	TCP	22	クライアントIP/CIDR	ALLOW
*	*	*	*	*	DENY (デフォルト)

アウトバウンドルール:

ルール番号	タイプ	プロトコル	ポート範囲	宛先	許可/拒否
100	カスタムTCP	TCP	1024-65535	クライアントIP/CIDR	ALLOW
*	*	*	*	*	DENY (デフォルト)

警告: NACLはルールを数値順に評価します。ルール90がすべて拒否の場合、その後のルール100のSSHを許可は決してヒットしません。明示的なALLOWルールが、広範なDENYルールよりも小さい番号を持つようにするか、最後の暗黙のすべて拒否ルールに依存します。

ステップ3: セキュリティグループの監査（インスタンスレベル）

セキュリティグループは最終防衛線であり、インスタンスに直接適用されます。これらはステートフルであるため、管理が容易です。

インバウンドルールの確認

EC2インスタンスにアタッチされたSGが、必要なポートでのトラフィックを予期される送信元から許可していることを確認します：

SSH（Linux）の場合: パブリックIPまたは0.0.0.0/0（必要な場合）からのTCPポート22を許可するインバウンドルール。
RDP（Windows）の場合: パブリックIPまたは0.0.0.0/0からのTCPポート3389を許可するインバウンドルール。
Webトラフィックの場合: 0.0.0.0/0からのTCPポート80および/または443を許可するインバウンドルール。

アウトバウンドルールの確認（通常はデフォルト）

SGはステートフルであるため、アウトバウンドルールは通常、すべてのトラフィックを許可（すべてのポートで0.0.0.0/0）に設定されています。アウトバウンドルールをカスタマイズした場合は、クライアントのエフェメラルポート範囲への応答を許可していることを確認します。

ベストプラクティス: 厳格なセキュリティ要件がない限り、セキュリティグループのアウトバウンドルールはデフォルトの「すべての宛先へのすべてのトラフィックを許可」のままにしておきます。これにより、トラブルシューティングが大幅に簡素化され、NACLまたはルートテーブルの問題を切り分けることができます。

接続チェックリスト

EC2接続が失敗した場合は、次の診断シーケンスに従います：

ルートテーブルの確認: トラフィックパス（インバウンドおよびアウトバウンド）が正しいサブネットゲートウェイ（IGW/VPCピアリング/NAT）に到達できますか？
NACLの確認（ステートレス）: トラフィックが特定のインバウンドポートで明示的に許可されており、かつ戻りトラフィック（多くの場合、高エフェメラルポート）がアウトバウンドで明示的に許可されていますか？
セキュリティグループの確認（ステートフル）: トラフィックが特定のインバウンドポートで明示的に許可されていますか？（アウトバウンドは通常開いている必要があります）。

広範なネットワーク層（ルーティング）からサブネットレベル（NACL）、そして最後にインスタンスレベル（SG）へと体系的に進むことで、ブロックメカニズムがステートレスフィルタリング、ステートフルフィルタリング、またはルーティング障害のいずれであるかを迅速に切り分けることができます。