なぜこれが機能しないのかを理解しようとして、約2時間画面を見続けています。私はプライベートサブネットとパブリックサブネットを使用して一般的なVPCを構築し、可能な限りロックダウンしようとしています。私にはいくつかのセキュリティグループがありますが、ルールを緩和するかのように、問題がNACLにあることはわかっています。すべてが機能します。
私が抱えている問題は、パブリックサブネットまたはプライベートサブネットのいずれかのEC2インスタンスの内部からインターネット(ポート80および443)にアクセスできないことです。 「問題ルール」はインバウンド1000番であり、10.0.0.0/16
からのすべてのエフェメラルポートを許可します。このルールをすべてのソースに適用するように変更すると(0.0.0.0/0
)、両方のサブネットのすべてのec2インスタンスからインターネットにアクセスできます(ほとんどの場合、curlとyumという異なるアプリを実行してこれをテストしています。
インバウンドルールでは、すべてのec2インスタンスがエフェメラルポートを開いてルーターと通信できるようにする必要があるため、この動作を理解するのに苦労しています。その後、ルーターは任意のホストのポート80と443と通信できます。シンプルではないが、ここで重要なポイントが欠けているような気がします:)。
アスキーアートでは、これが私のルールの理解です
EC2 instance does a curl on www.google.com (port 80)
SYN Packet out to stablish the connection (ephemeral port on VM to port 80)
EC2 vm (somewhere in 10.0.0.0/16:ephemeral)
-> SG
-> NACL in (in rule 1000 - ALLOW source 10.0.0.0/16 on ports 1024-65535)
-> NACL out (out rule 200 - ALLOW destination 0.0.0.0/0 on port 80)
-> IGW
-> Google (172.217.23.14:80)
SYN + ACK Packet in to continue the connection handshake
Google (172.217.23.14:80)
-> IGW
-> NACL in (in rule 100 - ALLOW source 0.0.0.0/0 on port 80)
-> NACL out (out rule 100 - ALLOW destination 0.0.0.0/0 on port 1024-65535)
-> SG
-> EC2 vm (somewhere in 10.0.0.0/16:ephemeral)
Tcpdump(Sudo tcpdump -i eth0 -s 1500 port not 22
)を実行して、Googleがエフェメラルポートからデータを返さないようにします。パケットフラグを使用して余分なデータを削除しました。フラグに-X
を追加して、各パケットの実際のデータを確認できます。
18:28:56.919335 IP ip-10-112-7-114.eu-west-1.compute.internal.40174 > prg03s06-in-f4.1e100.net.http:
18:28:56.949105 IP prg03s06-in-f4.1e100.net.http > ip-10-112-7-114.eu-west-1.compute.internal.40174:
18:28:56.949119 IP ip-10-112-7-114.eu-west-1.compute.internal.40174 > prg03s06-in-f4.1e100.net.http:
18:28:56.949219 IP ip-10-112-7-114.eu-west-1.compute.internal.40174 > prg03s06-in-f4.1e100.net.http:
18:28:56.979089 IP prg03s06-in-f4.1e100.net.http > ip-10-112-7-114.eu-west-1.compute.internal.40174:
18:28:57.010155 IP prg03s06-in-f4.1e100.net.http > ip-10-112-7-114.eu-west-1.compute.internal.40174:
18:28:57.010178 IP ip-10-112-7-114.eu-west-1.compute.internal.40174 > prg03s06-in-f4.1e100.net.http:
18:28:57.010308 IP ip-10-112-7-114.eu-west-1.compute.internal.40174 > prg03s06-in-f4.1e100.net.http:
18:28:57.041100 IP prg03s06-in-f4.1e100.net.http > ip-10-112-7-114.eu-west-1.compute.internal.40174:
18:28:57.041110 IP ip-10-112-7-114.eu-west-1.compute.internal.40174 > prg03s06-in-f4.1e100.net.http:
そこから、curlがポート40174を開き、google(prg03s06-in-f4.1e100.net)がポート80(ログのhttp)から応答したことがわかります。
TimとMichael-sqlbotに感謝します。答えはコメントに少し埋もれています。しかし、問題は、インバウンドルールがどのように機能するかについての誤解でした。 インバウンドルールのポート範囲は送信元ポートではなく、宛先ポート。 AWSドキュメントから
以下は、ネットワークACLルールの一部です。
- ルール番号。ルールは、番号が最も小さいルールから評価されます。ルールがトラフィックと一致するとすぐに、それと矛盾する可能性のある大きな番号のルールに関係なく適用されます。
- プロトコル。標準のプロトコル番号を持つ任意のプロトコルを指定できます。詳細については、プロトコル番号を参照してください。プロトコルとしてICMPを指定する場合は、ICMPのタイプとコードのいずれかまたはすべてを指定できます。
- [インバウンドルールのみ]トラフィックの送信元(CIDR範囲)および宛先(リスニング)ポートまたはポートrange。
- [アウトバウンドルールのみ]トラフィックの宛先(CIDR範囲)および宛先ポートまたはポート範囲。
- 指定されたトラフィックに対してALLOWまたはDENYを選択します。
ポート80(または任意のポートの任意のデーモン)で接続を確立すると、接続は高範囲ポートに渡され、ポート80が新しい接続を受け入れるために自由に保たれます。これらは エフェメラルポート と呼ばれます。
ウィキペディアによると32768から61000であるこれらの高範囲ポートへの着信トラフィックを許可する必要があります。Webサーバーを提供している場合は、おそらくそれらも発信を許可する必要があります。
更新/拡張NACLはステートレスです。つまり、データが流れる必要がある各方向のポートを許可する必要があります。ポート80でWebサーバーに接続すると、Webサーバーに「接続が受け入れられました。ポート(たとえば)50000でこの交換を続行してください」と表示されます。これが、発信トラフィックを許可するために、高範囲のポートの着信を許可する必要がある理由です。
別の説明があります ここ 。
質問を正しく読んだ場合、インバウンドルール1000を10.0.0.0/16ではなく0.0.0.0/0に変更すると、EC2インスタンスからインターネットへの接続が機能します。これは私には少し理にかなっていると思います。
トラフィックがインバウンドになり、NACL(インスタンスが存在するサブネットに関連付けられている)を通過する場合、ソースは10.0.0.0/16サブネットではなく、接続しているWebサービス上のIPアドレスです。これが0.0.0.0/0が機能し、10.0.0.0/16が機能しない理由です。