AWS: Errore di accesso a Internet con un ACL di networking personalizzato

Sono stato bloccato a guardare il mio schermo per circa 2 ore cercando di capire perché questo non funziona. Sto costruendo il tipico VPC con una substring privata e pubblica e cercato di bloccarlo il più ansible. Ho alcuni gruppi di sicurezza, ma so che la questione è nel NACL, come se mi distenda le regole, tutto funziona.

Il mio ingresso NACL è ACL in ingresso

e l'output è immettere qui la descrizione dell'immagine

Il problema che ho è che non posso accedere a Internet (port 80 e 443) da qualsiasi delle istanze EC2 nelle sottoreti pubbliche o private. So che la "regola del problema" è in ingresso no 1000, che consente a tutte le porte effimere da 10.0.0.0/16 . Se cambio questa regola per applicare a tutte le fonti ( 0.0.0.0/0 ) posso accedere a Internet da tutte le istanze ec2 in entrambe le sottoreti (sto provando a eseguire applicazioni diverse, curl e yum per lo più.

Sto solo lottando per capire questo comportmento, poiché la regola in entrata dovrebbe consentire a qualsiasi istanza ec2 di aprire una port effimera e di parlare con il router e quindi il router può parlare con la port 80 e 443 di qualsiasi host. Ho la sensazione che mi manca semplicemente, ma qui cruciale qui :).

modifica

Nell'arte ascii, questa è la mia comprensione delle regole

 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) 

Modifica 2

L'esecuzione di tcpdump ( sudo tcpdump -i eth0 -s 1500 port not 22 ) per garantire che Google non restituisca i dati da una port effimera. Ho rimosso i dati aggiuntivi con i flag di pacchetto e puoi aggiungere -X alle flag per vedere i dati reali in each pacchetto.

 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: 

Da lì si può vedere che la curl ha aperto la port 40174 e google (prg03s06-in-f4.1e100.net) ha risposto dalla port 80 (http nel log).

Risposta

Grazie a Tim e Michael-sqlbot. La risposta è un po 'sepolta nei commenti. Ma il problema era una mancanza di comprensione di come funzionano le regole in entrata. L' intervallo di port sulle regole in entrata si riferisce alla port di destinazione , non alla port di origine. Dai documenti AWS

Di seguito sono riportte le parti di una regola ACL di networking:

  • Numero di regola. Le regole vengono valutate a partire dalla regola più numerata. Appena una regola corrisponde al traffico, viene applicata indipendentemente da qualsiasi regola di maggiore numero che possa contraddirla.
  • Protocollo. È ansible specificare qualsiasi protocollo che abbia un numero di protocollo standard. Per ulteriori informazioni, vedere Numeri di protocollo. Se si specifica ICMP come protocollo, è ansible specificare uno o tutti i tipi e i codici ICMP.
  • [Solo regole in entrata] La fonte del traffico (intervallo CIDR) e la port o la port di destinazione (ascolto) .
  • [Solo regole in output] La destinazione del traffico (intervallo CIDR) e la port di destinazione o la port.
  • Scelta di ALLOW o DENY per il traffico specificato.

2 Solutions collect form web for “AWS: Errore di accesso a Internet con un ACL di networking personalizzato”

Quando si effettua una connessione sulla port 80 (o su un qualsiasi demone su qualsiasi port), la connessione viene trasferita alla port ad alta gamma per mantenere la port 80 libera di accettare nuove connessioni. Queste sono chiamate porte effimere .

Devi consentire il traffico in arrivo a queste porte ad alta gamma, che secondo Wikipedia sono 32768 a 61000. Se stai fornendo un server web, probabilmente hai bisogno di consentirli anche in output – che hai come regola 100.

I NACL aggiornati / ampliati sono apolidi, il che significa che è necessario consentire alle porte in each direzione che i dati devono fluire. Quando si connette a un server web sulla port 80 il loro server web dice "la connessione accettata, continua questo scambio sulla port (ad esempio) 50000". È per questo che è necessario consentire porte ad alta gamma in arrivo per consentire il traffico in output.

C'è un'altra spiegazione qui .

se ho letto la domanda correttamente, quando si modifica la regola di entrata 1000 a 0.0.0.0/0 invece di 10.0.0.0/16, allora le connessioni dalle istanze EC2 al lavoro di Internet. Penso che questo mi fa un po 'di senso.

quando il traffico è in entrata e viene passato dal NACL (associato alla substring che le istanze sono attive), la sorgente non è la substring 10.0.0.0/16 ma è qualsiasi indirizzo IP nel servizio web a cui è connesso. è per questo che 0.0.0.0/0 funziona e 10.0.0.0/16 non lo fa

Suggerimenti per Linux e Windows Server, quali Ubuntu, Centos, Apache, Nginx, Debian e argomenti di rete.