web-dev-qa-db-ja.com

AWS:カスタムネットワークACLを使用したインターネットへのアクセスエラー

なぜこれが機能しないのかを理解しようとして、約2時間画面を見続けています。私はプライベートサブネットとパブリックサブネットを使用して一般的なVPCを構築し、可能な限りロックダウンしようとしています。私にはいくつかのセキュリティグループがありますが、ルールを緩和するかのように、問題がNACLにあることはわかっています。すべてが機能します。

私のインバウンドNACLは Inbound ACL

アウトバウンドは enter image description here

私が抱えている問題は、パブリックサブネットまたはプライベートサブネットのいずれかの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)

編集2

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を選択します。
4
Augusto

ポート80(または任意のポートの任意のデーモン)で接続を確立すると、接続は高範囲ポートに渡され、ポート80が新しい接続を受け入れるために自由に保たれます。これらは エフェメラルポート と呼ばれます。

ウィキペディアによると32768から61000であるこれらの高範囲ポートへの着信トラフィックを許可する必要があります。Webサーバーを提供している場合は、おそらくそれらも発信を許可する必要があります。

更新/拡張NACLはステートレスです。つまり、データが流れる必要がある各方向のポートを許可する必要があります。ポート80でWebサーバーに接続すると、Webサーバーに「接続が受け入れられました。ポート(たとえば)50000でこの交換を続行してください」と表示されます。これが、発信トラフィックを許可するために、高範囲のポートの着信を許可する必要がある理由です。

別の説明があります ここ

4
Tim

質問を正しく読んだ場合、インバウンドルール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が機能しない理由です。

0
Michael Brown