Я создал два экземпляра EC2 в одной зоне доступности и в одной учетной записи. Они используют разные группы безопасности. Я хочу, чтобы экземпляр A принимал соединения на определенном порту только от экземпляра B.
Я не верю, что это VPC, но не знаю, как это подтвердить. Мне не удалось изменить группу безопасности, поэтому я думаю, что это не VPC.
В группе безопасности, например, A, я добавил правило для порта и использовал публичный IP-адрес экземпляра B / 32 для источника. Затем я попытался подключиться из экземпляра B, используя общедоступный IP-адрес экземпляра A, но попытка подключения немедленно завершилась неудачей.
Я попробовал те же шаги с частным IP каждого экземпляра. Что мне не хватает?
Вот статья, которая отвечает на аналогичный вопрос, но с участием VPC: Не удается подключиться к инстансу EC2 в VPC (Amazon AWS).
Оба экземпляра имеют одинаковый идентификатор VPC и идентификатор подсети.
Я также попытался установить источник для группы безопасности экземпляра B, что тоже не сработало.
Я пробую это с помощью mysql. Клиент mysql, работающий на экземпляре B, немедленно отказал с этой ошибкой:
ОШИБКА 2003 (HY000): не удается подключиться к серверу MySQL на '54 .xx.xx.xx '(113)
Чтобы проверить, нет ли проблем с установкой mysqld, я попробовал то же самое с ICMP Echo Reply, который тоже не сработал.
редактировать Благодаря первоначальным ответам я смог подтвердить, что эти два экземпляра работают в VPC (перейдя в консоль VPC). Итак, мой вопрос очень похож на статью по ссылке. Но в этом случае проблема заключалась в том, что экземпляры не были экземплярами по умолчанию, поэтому не было создано правильного маршрута и подсети. Вот как настроен мой VPC: VPC используется по умолчанию и имеет связанную с ним таблицу маршрутизации. Таблица маршрутов неявно связана с подсетью, связанной с VPC. В таблице маршрутов указан единственный маршрут, а цель - «локальная».
Все они создаются по умолчанию, поскольку, как я понимаю, документы должны позволять двум экземплярам подключаться друг к другу. Что мне (все еще) не хватает?
Я решил это с помощью службы технической поддержки AWS. Вот информация для будущих новичков вроде меня:
Проблема заключалась в том, что iptables работал на экземпляре B и не допускал никакого трафика. Я узнал, что для экземпляров EC2 существует два уровня межсетевого экрана: группы безопасности (управляемые с консоли AWS) и iptables (управляемые на хосте). Есть причины использовать iptables, например https://wincent.com/wiki/Using_iptables_on_EC2_instances
В большинстве случаев вам не нужно беспокоиться об использовании брандмауэра на уровне хоста, такого как iptables, при запуске Amazon EC2, потому что Amazon позволяет запускать экземпляры внутри «группы безопасности», которая фактически является политикой брандмауэра, которую вы используете для укажите, каким соединениям из внешнего мира следует разрешить доступ к экземпляру. Однако это подход «белого списка», и его непросто использовать для целей «занесения в черный список» на работающем экземпляре.
В моем случае мне не нужен брандмауэр уровня хоста, поэтому отключил iptables:
sudo service chkconfig stop
sudo chkconfig iptables off
Вот некоторые результаты, которые я получил в связи с комментариями, опубликованными по этому вопросу:
Причина, по которой это сработало для меня в другом экземпляре, заключается в том, что изображение, которое я использовал в этом случае, не запускало iptables - все изображения разные. Образ, который я использовал в этом случае, использовал iptables, чтобы запретить все соединения, кроме SSH.
Немного не по теме, но это единственный результат поиска по данной проблеме.
У нас была аналогичная проблема, но наши существующие экземпляры были перезагружены и внезапно перестали общаться. Оказалось, что в группе безопасности было слишком много правил - просто удалили некоторые разрешенные связи для возобновления. Он все еще работал до перезагрузки, потому что правила добавлялись с течением времени автоматическими вызовами API.
Надеюсь, это поможет кому-то в будущем.
Если вы не можете изменить настройки безопасности запущенных экземпляров, они НЕ запускаются в VPC.
Даже если это не VPC, EC2 запускает их в частные сети, которые связаны между собой. Поэтому вам следует указать частный IP-адрес экземпляра B в группе безопасности экземпляра A.
(1) вы можете проверить, находится ли ваш экземпляр в VPC, через консоль AWS. На панели управления EC2 вы можете выбрать свой экземпляр, затем на вкладке «Описание» в левом столбце появится поле «Идентификатор VPC». Если это поле пусто, вы используете классическую версию EC2.
(2) Вы не можете получить доступ к общедоступному IP-адресу экземпляра из другого экземпляра в EC2, если этот порт не открыт для всего мира. Приведенная выше ошибка с использованием IP 54.X.X.X говорит мне, что вы используете общедоступный IP. Измените строку подключения, чтобы вместо этого использовать общедоступный DNS. Это будет имя хоста, которое начинается с ec2-. Когда вы выполняете поиск в DNS для этого общедоступного DNS-имени, оно будет преобразовано в ЧАСТНЫЙ IP-адрес вместо общедоступного IP-адреса, который должен быть доступен, если ваши группы безопасности настроены правильно.
Резюме: попробуйте подключиться к вашему экземпляру mysql, используя общедоступный DNS экземпляра.
Если вы по-прежнему не можете подключиться, убедитесь, что mysql прослушивает eth0, а не только интерфейс обратной связи.
AWS имеет отдельные группы безопасности для экземпляров VPC и не-VPC, поэтому вам нужно каким-то образом узнать, используете ли вы VPC или нет (просто перейдите в консоль VPC и проверьте, видите ли вы там свои экземпляры), а затем убедитесь, что группы безопасности у вас есть созданы в том же контексте. Затем вы можете просто добавить группу безопасности A в группу безопасности B как доверенную и сделать наоборот. Таким образом, вы просто разрешаете весь трафик между двумя хостами на отдельных портах (я предполагаю, что это было вашим намерением).