AWS Security Group не разрешает доступ с частного IP-адреса для инстансов EC2
У меня есть экземпляры EC2. Они оба находятся в одном VPC, и им обоим назначены общедоступные IP-адреса.
Моя проблема в том, что я должен использовать общедоступные IP-адреса в моих группах безопасности, чтобы позволить им общаться. Если я попытаюсь использовать частные IP-адреса, их соединения будут запрещены.
В конечном итоге я удалю их общедоступные IP-адреса и не хочу впоследствии менять настройки моей группы безопасности.
Почему бы мне не использовать частные IP-адреса в качестве источника для двух машин, находящихся в одном VPC?
1 ответ
Tl ;dr: когда вы подключаетесь к экземпляру, используя его общедоступный IP-адрес, вы обязательно используете общедоступный адрес исходного компьютера в качестве исходного адреса (или адреса его шлюза NAT, если исходный экземпляр не имеет IP-адреса publig), и ваш трафик уходит в Интернет и возвращается обратно, когда вы это делаете (хотя, по общему признанию, вы не уходите далеко в сторону Интернета).
Возьмем два примера:
#1 public 203.0.113.1 private 172.31.3.1
#2 public 203.0.113.2 private 172.31.3.2
Если экземпляр №1 подключается к №2, используя общедоступный IP-адрес экземпляра №2 203.0.113.2:
- IP-пакеты покидают экземпляр №1 с исходным IP-адресом 172.31.3.1 и адресом назначения 203.0.113.2.
- пакеты поступают в таблицу маршрутизации VPC, которая видит, что 203.0.113.2 это не IP-адрес внутри VPC, поэтому таблица маршрутизации отправляет его на интернет-шлюз
- Интернет-шлюз видит трафик с адресом источника 172.31.3.1, который, как ему известно, на самом деле является экземпляром EC2 с общедоступным IP-адресом 203.0.113.1, поэтому он перезаписывает исходный IP-адрес с 172.31.3.1 на 203.0.113.1 и отправляет его в Интернет.
- IP-адрес источника теперь 203.0.113.1, а IP-адрес назначения - 203.0.113.2.
- безымянный компонент (возможно, он находится внутри самого Интернет-шлюза, но может находиться между Интернет-шлюзом и редко обсуждаемой частью региональной инфраструктуры AWS, называемой транзитным центром, которых в каждом регионе есть по крайней мере два), видит, что 203.0.113.2 принадлежит вашему Интернет-шлюзу, трафик возвращается на ваш Интернет-шлюз для обработки.
- Интернет-шлюз знает, что 203.0.113.2 принадлежит вашему экземпляру №2, поэтому он переводит адрес назначения в 172.31.3.2; на этом этапе адрес источника по-прежнему остается 203.0.113.1.
- Экземпляр № 2 и его группа безопасности рассматривают этот трафик как поступающий из Интернета с исходным IP-адресом 203.0.113.1, поэтому это адрес, который должен быть разрешен группой безопасности.
Если экземпляр № 1 использует 172.31.3.2 для подключения к экземпляру № 2, то по существу ничего из этого не происходит, поэтому группа безопасности для № 2 будет видеть 172.31.3.1 в качестве адреса источника.
Лучше всего использовать частный IP-адрес целевого экземпляра.
Обратите внимание, что при использовании частных IP-адресов вы также можете указать идентификатор группы безопасности экземпляра №1 в правилах группы безопасности экземпляра №2 вместо того, чтобы указывать частный IP-адрес экземпляра №1. Идет там же, где и IP в консоли - введите
sg
в этом поле, и вы сможете выбрать один. Это, вероятно, легче поддерживать, и это хорошо работает, если вы поместите экземпляр № 1 в "группу из единиц" с автоматическим масштабированием, чтобы автоматическое масштабирование заменило машину в случае сбоя.
Также обратите внимание, что когда два экземпляра обмениваются данными, используя свои общедоступные IP-адреса, вам выставляется счет за выход и возвращение. Это не столько, сколько стоит интернет-трафик, но ставка аналогична ставкам для внутрирегиональных и внутрирегиональный пиринговый трафик VPC.