AWS VPC: порты ответа и порядок правил сетевой ACL

Введение

Публичное приложение доставки имеет интернет-маршрут, публичный адрес и разрешение HTTP в группе безопасности, но клиент A не может его прочитать. ACL подсети разрешает порт назначения запроса и блокирует обратный порт клиента. Вы диагностируете и исправите этот путь, проверите приоритет правил и восстановите предоставленную начальную конфигурацию.

Сначала завершите Connect Privately to S3 with a VPC Endpoint. Новая среда предоставляет собственное приложение, публичную и частную подсети, публичный маршрут, адрес, группу и пользовательскую ACL. CLI настроен. Сохраните эти ресурсы и эталонную сеть. Меняйте только рассматриваемое правило ACL; при очистке удалите временный запрет. Итоговое базовое состояние намеренно воспроизводит исходную неисправность, не удаляя приложение.

Связь с сертификацией

Это базовая практика по следующим экзаменационным темам.

Cloud Practitioner (CLF-C02) · Задача 3.5: Основные роли групп безопасности и ACL в VPC.
Solutions Architect – Associate (SAA-C03) · Задача 1.2: Защита подсети и условия доступа к приложению.
CloudOps Engineer – Associate (SOA-C03) · Задача 5.3: Диагностика соединений по правилам ACL и портам ответа.
Advanced Networking – Specialty (ANS-C01) · Задача 3.1: Базовая практика упорядоченных правил подсети и реального обратного пути.

Исследуйте границу подсети приложения

Найдите приложение и сравните маршрут, группу и ACL до изменений.

Используйте Terminal, рядом откройте AWS View. Частный адрес публичного приложения — 10.20.1.10. Клиент A — 198.51.100.10, B — 198.51.100.20. Предоставленная группа разрешает только A TCP 80. Для 8081 разрешения нет.

cd /home/labex/project

Выберите VPC по тегу Name. Фильтры выбирают ресурсы, запрос извлекает ID, а $(...) сохраняет его:

VPC_ID=$(aws ec2 describe-vpcs \
  --filters Name=tag:Name,Values=application-network \
  --query 'Vpcs[0].VpcId' \
  --output text)

Сохраните публичную подсеть и предоставленный интерфейс:

SUBNET_ID=$(aws ec2 describe-subnets \
  --filters "Name=vpc-id,Values=$VPC_ID" Name=tag:Name,Values=public-subnet \
  --query 'Subnets[0].SubnetId' \
  --output text)

ENI_ID=$(aws ec2 describe-network-interfaces \
  --filters "Name=subnet-id,Values=$SUBNET_ID" \
  --query 'NetworkInterfaces[0].NetworkInterfaceId' \
  --output text)

Прочитайте частный адрес, публичную ассоциацию и прикреплённую группу:

aws ec2 describe-network-interfaces \
  --network-interface-ids "$ENI_ID" \
  --query 'NetworkInterfaces[].{Private:PrivateIpAddress,Public:Association.PublicIp,Groups:Groups}' \
  --output json

Прочитайте таблицу, связанную с подсетью:

aws ec2 describe-route-tables \
  --filters "Name=association.subnet-id,Values=$SUBNET_ID" \
  --query 'RouteTables[].{Routes:Routes,Associations:Associations}' \
  --output json

Публичный адрес связан, активный маршрут 0.0.0.0/0 ведёт к интернет-шлюзу. Сохраните и прочитайте группу:

GROUP_ID=$(aws ec2 describe-security-groups \
  --filters "Name=vpc-id,Values=$VPC_ID" Name=group-name,Values=supplied-application \
  --query 'SecurityGroups[0].GroupId' \
  --output text)

aws ec2 describe-security-groups \
  --group-ids "$GROUP_ID" \
  --query 'SecurityGroups[].{Inbound:IpPermissions,Outbound:IpPermissionsEgress}' \
  --output json

Вход разрешает TCP 80 от 198.51.100.10/32, выход имеет предоставленное стандартное разрешение. Сохраните правила.

Сетевая ACL управляет трафиком через границу подсети. У каждой подсети одна ACL; одна ACL может обслуживать несколько подсетей. В отличие от группы с состоянием, ACL не хранит состояние: разрешение запроса автоматически не разрешает ответ. Выберите связанную ACL:

ACL_ID=$(aws ec2 describe-network-acls \
  --filters "Name=association.subnet-id,Values=$SUBNET_ID" \
  --query 'NetworkAcls[0].NetworkAclId' \
  --output text)

Прочитайте идентификатор, ассоциации и отдельные входящие/исходящие записи:

aws ec2 describe-network-acls \
  --network-acl-ids "$ACL_ID" \
  --query 'NetworkAcls[].{ID:NetworkAclId,Default:IsDefault,Associations:Associations,Entries:Entries}' \
  --output json

Это пользовательская application-acl, не стандартная ACL. Правило 100 в обоих направлениях разрешает A TCP порт назначения 80. Egress: false — вход, true — выход. Протокол 6 — TCP. Несовпавший трафик достигает конечного запрета: * в AWS View, 32767 в CLI.

В AWS View нажмите Request application · client A: результат Connection failed, несмотря на маршрут и разрешение группы. Request application · client B и Request port 8081 тоже не работают. Сохраните открытый Terminal, чтобы не потерять ID.

Исправьте правило обратного порта клиента

Замените ошибочный исходящий порт, сохранив узкий адрес клиента.

HTTP-запрос идёт с выбранного клиентом эфемерного порта на серверный 80. Ответ идёт с 80 на этот клиентский порт. ACL сравнивает порт назначения пакета в каждом направлении. Исходящий порт назначения 80 не пропускает этот ответ.

Эфемерный диапазон зависит от инициатора. В упражнении разрешите распространённый диапазон 1024–65535 только к A 198.51.100.10/32. Это не универсальное значение всех ОС. Замените исходящее 100; --egress выбирает выход, --port-range — диапазон назначения:

aws ec2 replace-network-acl-entry \
  --network-acl-id "$ACL_ID" \
  --rule-number 100 \
  --protocol 6 \
  --rule-action allow \
  --egress \
  --cidr-block 198.51.100.10/32 \
  --port-range From=1024,To=65535

Успешная замена не выводит результат. Прочитайте записи:

aws ec2 describe-network-acls \
  --network-acl-ids "$ACL_ID" \
  --query 'NetworkAcls[].Entries' \
  --output json

Входящее 100 по-прежнему разрешает A TCP 80. Исходящее 100 теперь разрешает назначения 1024–65535 к тому же клиенту. Стандартные запреты и ассоциация подсети не меняются.

В AWS View снова нажмите Request application · client A. Новый запрос возвращает Application online, источник 198.51.100.10, назначение 80. Request application · client B и Request port 8081 по-прежнему не работают. Запрос и ответ проходят ACL без расширения входных разрешений группы или ACL на других клиентов.

Исправленная ACL пропускает A и сохраняет конечные запреты

Пример: входящее 100 разрешает A TCP 80; исходящее 100 — ответные назначения 1024–65535 к A. Конечные запреты показаны в обоих направлениях, реальный запрос возвращает Application online. ID ресурсов могут отличаться.

Наблюдайте запрет с меньшим номером

Намеренно вставьте совпадающий запрет перед входящим разрешением, чтобы проверить порядок.

ACL проверяет правила по возрастанию в каждом направлении. Первое совпадение решает результат; последующие не учитываются. Создайте временное входящее 90, запрещающее A TCP 80. --ingress явно выбирает вход; создание 90 не заменяет 100:

aws ec2 create-network-acl-entry \
  --network-acl-id "$ACL_ID" \
  --rule-number 90 \
  --protocol 6 \
  --rule-action deny \
  --ingress \
  --cidr-block 198.51.100.10/32 \
  --port-range From=80,To=80

Прочитайте записи:

aws ec2 describe-network-acls \
  --network-acl-ids "$ACL_ID" \
  --query 'NetworkAcls[].Entries' \
  --output json

Входящий запрет 90 совпадает раньше разрешения 100. Исходящее 100 всё ещё разрешает обратные порты, группа — HTTP от A. Ни одно не отменяет более ранний запрет ACL.

Когда AWS View покажет входящее 90, нажмите Request application · client A. Новый запрос не работает; B и 8081 тоже заблокированы. Старый успех — история: повторяйте запрос после изменения правил. Оставьте 90 для проверки шага, удалите в следующем.

Удалите временный запрет и повторите проверку доступа

Удалите только ранний запрет и проверьте исправленный обратный путь.

Удалите входящее 90. Направление важно: входящие и исходящие номера независимы:

aws ec2 delete-network-acl-entry --network-acl-id "$ACL_ID" --rule-number 90 --ingress

Повторно прочитайте записи:

aws ec2 describe-network-acls \
  --network-acl-ids "$ACL_ID" \
  --query 'NetworkAcls[].Entries' \
  --output json

90 отсутствует. Входящее 100 разрешает A TCP 80, исходящее — обратные порты, остальной трафик запрещён. Сохраните исходную ассоциацию, группу, публичный маршрут и адрес.

В AWS View новый Request application · client A возвращает Application online. Request application · client B и Request port 8081 не работают. Группа с состоянием разрешает ответы на допущенные запросы, но ACL без состояния требует обоих направлений. Удаление раннего запрета восстанавливает эту независимую границу.

Восстановите предоставленную начальную конфигурацию ACL

Отмените изменение обратных портов, убедитесь в отсутствии временного запрета и сохраните ресурсы.

Верните исходящее 100 к предоставленному порту назначения 80. Очистка намеренно воспроизводит исходный сбой; это не рекомендуемое правило для работающего HTTP-ответа:

aws ec2 replace-network-acl-entry \
  --network-acl-id "$ACL_ID" \
  --rule-number 100 \
  --protocol 6 \
  --rule-action allow \
  --egress \
  --cidr-block 198.51.100.10/32 \
  --port-range From=80,To=80

Прочитайте полный инвентарь ACL VPC с ассоциациями. Удаляемые теги сами по себе не доказывают очистку:

aws ec2 describe-network-acls \
  --filters "Name=vpc-id,Values=$VPC_ID" \
  --query 'NetworkAcls[].{ID:NetworkAclId,Default:IsDefault,Associations:Associations,Entries:Entries}' \
  --output json

Временное 90 должно отсутствовать. Пользовательская ACL остаётся у публичной подсети приложения. Оба правила 100 соответствуют A TCP назначению 80; конечные запреты целы. Частная подсеть сохраняет стандартную ACL. Не удаляйте и не заменяйте предоставленные ACL, подсети, приложение, группу, шлюз или публичный адрес.

Прочитайте исходную группу и подтвердите сохранность правил:

aws ec2 describe-security-groups \
  --group-ids "$GROUP_ID" \
  --query 'SecurityGroups[].{Inbound:IpPermissions,Outbound:IpPermissionsEgress}' \
  --output json

В AWS View новый Request application · client A снова не работает: обратный порт больше не разрешён. B и 8081 заблокированы. Ошибка API или недоступная сеть приложения не доказывает очистку: аутентифицированный инвентарь должен успешно читаться, а реальный настроенный путь — давать эти результаты.

Выполните проверку завершения этого шага.

Итоги

Вы нашли ACL приложения и диагностировали отсутствующий диапазон ответных портов. Замена исходящего правила восстановила реальный HTTP для A, сохранив блокировку остальных источников и портов. Запрет с меньшим номером показал первое совпадение; его удаление восстановило доступ.

Вы сохранили группу, маршруты, адреса и ассоциации, удалили временный запрет и вернули исходную ACL.

Диагностика обратного пути сетевой ACL