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

Развертывание эластичного beanstalk в частной подсети VPC завершается ошибкой со следующей ошибкой, когда входящий ACL общедоступной подсети запрещает все

TLD: ошибка, когда общедоступная подсеть является входящей, запретить все.

The EC2 instances failed to communicate with AWS Elastic Beanstalk,  
either because of configuration problems with the VPC or a failed EC2 instance.  
Check your VPC configuration and try launching the environment again.

моя конфигурация

У меня есть три подсети внутри VPC, также общедоступные назначаются с возрастом Интернета, а обе частные подсети назначаются с помощью шлюза nat Услуги конечных точек VPC добавлены с SG, разрешающим весь трафик с уровня VPC, и добавлены как частные-1, так и частные-2 подсети.

входящий ACL общедоступной подсети

исходящий ACL общедоступной подсети

входящий ACL подсети private-1 и private-2

исходящий ACL подсети private-1 и private-2

Используя шаблон формирования облака, развернутое приложение beanstalk узла как ec2, так и ELB в подсети private-1, где ELB находится с группой безопасности внутренней схемы, разрешает порт 80 на экземпляре из ELB SG.

И после долгого ожидания приложение beanstalk вышло из строя с ошибкой 

The EC2 instances failed to communicate with AWS Elastic Beanstalk,  
either because of configuration problems with the VPC or a failed EC2 instance.  
Check your VPC configuration and try launching the environment again.

Я разрешил порты из общедоступной подсети в частную-1 и подключился через туннель ssh из общедоступной подсети экземпляра в экземпляр ec2, созданный beanstalk. На экземпляре нет настроек

  1. Приложение узла не работает на порту 8081
  2. Nginx не работает на порту 8080
  3. Нет правила пересылки IP-таблиц для портов с 80 по 8080

Когда я разрешаю входящий трафик в общедоступной подсети, приложение эластичного бобового стебля настроено, а среда зеленого цвета

Я не понимаю, почему мне нужно разрешать входящий ACL общедоступной подсети, если я вообще не использую в нем какой-либо ресурс, и почему beanstalk не настраивает экземпляр в этом случае?

Я все еще сталкиваюсь с проблемой после разрешения 1024-65535 эфемерных портов в общедоступном входящем ACL подсети для обратного трафика из Интернета.

Beanstalk может успешно запуститься после добавления порта 443 во входящий ACL общедоступной подсети новый ACL для публичной подсети

Поскольку в сети не разрешено переходить из общедоступной подсети в частную и вся установка находится в частной подсети, почему порт 443 нарушает среду beanstalk?

Я действительно не понимаю, почему мне нужно разрешать входящий ACL общедоступной подсети, если я вообще не использую какой-либо ресурс в этом

Но ты. У вас есть шлюз NAT. Шлюзы NAT предоставляют услуги для ресурсов в частных подсетях, но на самом деле они расположены в общедоступных подсетях и используют общедоступную подсеть на своей стороне, обращенной к Интернету.

Вы блокируете обратный трафик из Интернета от возврата на шлюз NAT.

и почему beanstalk в этом случае не настраивает экземпляр?

Причина этого должна быть очевидна из вышеизложенного. Как указано в сообщении об ошибке, экземпляр не связался со службой EB, потому что не может - вы заблокировали его - поэтому инициализация не может произойти.

Вы можете использовать любую конфигурацию VPC, которая вам нравится, если она отвечает следующим требованиям.

Требования VPC

Доступ в Интернет - экземпляры должны иметь доступ к Интернету одним из следующих способов.

  • Публичная подсеть - экземпляры имеют общедоступный IP-адрес и используют интернет-шлюз для доступа в Интернет.

  • Частная подсеть - экземпляры используют устройство NAT для доступа в Интернет.

https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/vpc.html

Сетевые ACL лучше не трогать, если у вас нет особых причин для их настройки. Группы безопасности достаточны для большинства целей.