Назад | Перейти на главную страницу

AWS: Ошибка доступа в Интернет с помощью настраиваемого сетевого ACL

Я застрял, глядя на свой экран около 2 часов, пытаясь понять, почему это не работает. Я создаю типичный VPC с частной и общедоступной подсетями и пытаюсь максимально его заблокировать. У меня есть несколько групп безопасности, но я знаю, что проблема в NACL, как будто я ослаблю правила, все работает.

Мой входящий NACL

и исходящий

У меня проблема в том, что я не могу получить доступ к Интернету (порт 80 и 443) изнутри любого из экземпляров EC2 в общедоступных или частных подсетях. Я знаю, что "правило проблемы" - это входящий номер 1000, который разрешает все временные порты из 10.0.0.0/16. Если я изменю это правило, чтобы применить ко всем источникам (0.0.0.0/0) Я могу получить доступ к Интернету со всех экземпляров ec2 в обеих подсетях (я тестирую это, запуская разные приложения; в основном curl и yum.

Я просто изо всех сил пытаюсь понять это поведение, поскольку правило для входящего трафика должно разрешать любому экземпляру ec2 открывать эфемерный порт и разговаривать с маршрутизатором, а затем маршрутизатор может разговаривать с портами 80 и 443 любого хоста. Такое ощущение, что мне здесь не хватает простого, но важного момента :).

редактировать

В ascii art это мое понимание правил

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 в журнале).

Ответ

Спасибо Тиму и Майклу-sqlbot. Ответ немного похоронен в комментариях. Но проблема заключалась в неправильном понимании того, как работают правила для входящих подключений. В диапазон портов на входящие правила обратитесь к порт назначения, а не порт источника. Из документов AWS

Ниже перечислены части правила сетевого ACL:

  • Номер правила. Правила оцениваются, начиная с правила с наименьшим номером. Как только правило соответствует трафику, оно применяется независимо от правила с более высоким номером, которое может ему противоречить.
  • Протокол. Вы можете указать любой протокол, имеющий стандартный номер протокола. Для получения дополнительной информации см. Номера протоколов. Если вы укажете ICMP в качестве протокола, вы можете указать любой или все типы и коды ICMP.
  • [Только правила для входящих] источник трафика (Диапазон CIDR) и порт назначения (прослушивание) или диапазон портов.
  • [Только для исходящих правил] Пункт назначения для трафика (диапазон CIDR) и порт назначения или диапазон портов.
  • Выбор РАЗРЕШИТЬ или ЗАПРЕТИТЬ для указанного трафика.

Когда вы устанавливаете соединение через порт 80 (или к любому демону на любом порту), соединение передается на порт высокого диапазона, чтобы порт 80 оставался свободным для приема новых соединений. Они называются эфемерные порты.

Вам необходимо разрешить входящий трафик на эти порты высокого диапазона, которые, согласно Википедии, составляют от 32768 до 61000. Если вы предоставляете веб-сервер, вам, вероятно, также необходимо разрешить им исходящий - как правило, у вас есть 100.

Обновление / расширено NACL не имеют состояния, что означает, что вам нужно разрешить порты в каждом направлении, в котором должны передаваться данные. Когда вы подключаетесь к веб-серверу через порт 80, их веб-сервер сообщает: «Соединение принято, продолжить обмен через порт (скажем) 50000». Вот почему вам необходимо разрешить входящие порты с большим диапазоном, чтобы разрешить исходящий трафик.

Есть другое объяснение Вот.

Если я правильно прочитал вопрос, когда вы меняете Inbound Rule 1000 на 0.0.0.0/0 вместо 10.0.0.0/16, тогда соединения ваших экземпляров EC2 с Интернетом работают. Я думаю, что это имеет для меня немного смысла.

когда трафик поступает как входящий и передается через NACL (связанный с подсетью, в которой находятся ваши экземпляры), источником является не подсеть 10.0.0.0/16, а тот IP-адрес веб-службы, к которой вы подключились. вот почему 0.0.0.0/0 работает, а 10.0.0.0/16 нет