AWS: Erro ao acessar a Internet com uma ACL de rede personalizada

Question

Eu tenho ficado preso na minha tela por cerca de duas horas tentando descobrir por que isso não está funcionando. Estou construindo o típico VPC com uma sub-rede pública e privada e tentando bloqueá-lo o máximo possível. Eu tenho alguns grupos de segurança, mas sei que o problema está no NACL, como se eu relaxasse as regras, tudo funcionasse.

Meu NACL de entrada é

easaídaé

OproblemaquetenhoéquenãoconsigoacessaraInternet(porta80e443)dedentrodenenhumadasinstânciasdoEC2nassub-redespúblicasouprivadas.Euseiquea"regra do problema" é a entrada no 1000, que permite todas as portas efêmeras de 10.0.0.0/16 . Se eu alterar essa regra para aplicar a todas as fontes ( 0.0.0.0/0 ), posso acessar a Internet de todas as instâncias ec2 em ambas as sub-redes (estou testando isso executando aplicativos diferentes; curl e yum principalmente.

Estou apenas lutando para entender esse comportamento, pois a regra de entrada deve permitir que qualquer instância do ec2 abra uma porta efêmera e fale com o roteador, e então o roteador pode conversar com as portas 80 e 443 de qualquer host. Eu tenho a sensação de que estou perdendo um ponto simples, mas crucial aqui:).

editar

Na arte ascii, este é o meu entendimento das regras

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)

Editar 2

Executando o tcpdump ( sudo tcpdump -i eth0 -s 1500 port not 22 ) para garantir que o google não esteja retornando dados de uma porta efêmera. Eu removi os dados extras com os sinalizadores de pacotes e você pode adicionar -X aos sinalizadores para ver os dados reais em cada pacote.

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:

De lá você pode ver que o curl abriu a porta 40174 e o google (prg03s06-in-f4.1e100.net) respondeu da porta 80 (http no log).

Resposta

Obrigado a Tim e Michael-sqlbot. A resposta está um pouco enterrada nos comentários. Mas o problema foi um mal-entendido de como funcionam as regras de entrada. O intervalo de portas nas regras de entrada refere-se à porta de destino , não à porta de origem. Dos documentos da AWS

The following are the parts of a network ACL rule:

• Rule number. Rules are evaluated starting with the lowest numbered rule. As soon as a rule matches traffic, it's applied regardless of any higher-numbered rule that may contradict it.
• Protocol. You can specify any protocol that has a standard protocol number. For more information, see Protocol Numbers. If you specify ICMP as the protocol, you can specify any or all of the ICMP types and codes.
• [Inbound rules only] The source of the traffic (CIDR range) and the destination (listening) port or port range.
• [Outbound rules only] The destination for the traffic (CIDR range) and the destination port or port range.
• Choice of ALLOW or DENY for the specified traffic.

    

Answer 1

Quando você faz uma conexão na porta 80 (ou para qualquer daemon em qualquer porta), a conexão é transferida para a porta de alto alcance para manter a porta 80 livre para aceitar novas conexões. Estes são chamados de portas efêmeras .

Você precisa permitir o tráfego de entrada para essas portas de alto alcance, que, de acordo com a Wikipedia, são de 32768 a 61000. Se você estiver fornecendo um servidor da Web, provavelmente precisará permitir também a saída - que você tem como regra 100.

Atualizar / expandido Os NACLs são sem estado, o que significa que você precisa permitir que os fluxos em cada direção de dados precisem fluir. Quando você se conecta a um servidor da Web na porta 80, seu servidor da Web diz "conexão aceita, continue esta troca na porta (digamos) 50000". É por isso que você precisa permitir que as portas de alcance alto entrem para permitir o tráfego de saída.

Existe outra explicação aqui .

    

Answer 2

Se eu tiver lido a pergunta corretamente, quando você alterar a regra de entrada 1000 para 0.0.0.0/0 em vez de 10.0.0.0/16, as conexões de suas instâncias do EC2 para a Internet funcionarão. Eu acho que isso faz um pouco de sentido para mim.

quando o tráfego chega de entrada e é passado pelo NACL (associado à sub-rede em que suas instâncias estão), a origem não é a sub-rede 10.0.0.0/16, mas é o endereço IP que estiver no serviço da Web ao qual você está conectado. é por isso que 0.0.0.0/0 funciona e 10.0.0.0/16 não funciona