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

Как настроить статический IP-адрес для исходящего трафика в AWS?

У меня есть несколько инстансов EC2 в 3-х зонах доступности. Приложение, которое я запускаю на этих экземплярах, обменивается данными с несколькими сторонними приложениями, имеющими механизм белого списка. Я знаю, что могу общаться с этими сторонними приложениями, используя статические IP-адреса (эластичный IP) с помощью шлюза NAT. Если я это сделаю, мне нужно будет указать конкретный маршрут для каждого стороннего приложения, чтобы оно работало. Я хотел бы получить статический исходящий IP-адрес без определения всех этих маршрутов. Так что в основном по умолчанию весь трафик маршрутизируется через шлюз NAT. Я пробовал следующее, но больше не могу получить доступ к своему приложению. (Кстати, все эти экземпляры EC2 находятся за приложением LoadBalancer)

таблица маршрутизации подсети:

10.0.0.0/16     ->  local
0.0.0.0/0       ->  NAT Gateway

Таблица маршрутизации подсети шлюза NAT

10.0.0.0/16     ->  local
0.0.0.0/0       ->  Internet Gateway

Это будет работать, если я настрою следующие таблицы маршрутизации, но тогда мне придется настроить определенные маршруты для каждого стороннего приложения, с которым мое приложение взаимодействует.

таблица маршрутизации подсети:

10.0.0.0/16                 ->  local
0.0.0.0/0                   ->  Internet Gateway
ThirdPartyApplicationIp/32  ->  NAT Gateway

Таблица маршрутизации подсети шлюза NAT

10.0.0.0/16     ->  local
0.0.0.0/0       ->  Internet Gateway

Определив этот маршрут специально, у нас могут возникнуть проблемы, когда, например, обновляются записи DNS и меняются IP-адреса. Я знаю, что это произойдет, потому что я знаю, что некоторые сторонние приложения также используют AWS с ELB, а IP-адреса ELB со временем будут меняться. К тому же это просто не очень удобно, когда нам приходится так управлять всеми этими сторонними приложениями.

Есть ли способ решить эту проблему, чтобы мне не нужно было определять конкретные маршруты для каждого стороннего приложения, и я по-прежнему мог получить доступ к моему приложению через Application LoadBalancer и уважал изменения DNS?

Дополнительная проблема:
Решение этого может также решить следующую проблему, которой у меня еще нет, но которая возникнет в ближайшем будущем: в будущем, когда наше приложение взаимодействует со сторонним приложением, и это приложение также подключает наше приложение, тогда трафик маршрутизируется через шлюз NAT. Потому что это маршрутизация, которую я настроил, но тогда она не будет работать, как только сторонние приложения попытаются подключиться через приложение LoadBalancer к нашим приложениям, потому что тогда трафик должен маршрутизироваться через Интернет-шлюз напрямую, а не через шлюз NAT. . Но если я это сделаю, то потеряю свой статический IP. Есть ли способ решить эту проблему?

Результаты предложения Мэтта: Предложение Мэтта работает, но я действительно не понимаю, почему. Поэтому я начал экспериментировать с этой установкой, чтобы попытаться выяснить, в чем разница. Потому что таблицы маршрутизации такие же, как и раньше, и мне это показалось странным. Оказывается, если я добавлю один экземпляр EC2 в частную подсеть с назначенным общедоступным IP-адресом (снова сделав его общедоступной подсетью), вся маршрутизация завершится неудачно, и мой ELB больше не будет отвечать на запросы. После удаления этого нового экземпляра EC2 (с назначенным общедоступным IP-адресом) он все еще не удался. Только после удаления зон доступности в моем ELB и повторного добавления моих частных подсетей он работает. Я не понимаю, почему простое добавление нового экземпляра EC2 с общедоступным IP-адресом нарушает всю маршрутизацию? (Этот новый экземпляр EC2 не входит в целевую группу ELB, просто бездействует в подсети)

Чтобы эффективно использовать шлюз / экземпляр NAT, ваши экземпляры EC2 должны находиться в частных подсетях. Таким образом, у вас просто есть маршрут по умолчанию для всего исходящего трафика, проходящего через NAT.

Переместите экземпляры EC2 из общедоступных подсетей в частные. Ваш балансировщик нагрузки по-прежнему сможет получить к ним доступ, поскольку ELB находится внутри вашего VPC.

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

  • Туннелируйте через SSH для доступа к вашим внутренним инстансам EC2, или
  • Дважды SSH для доступа к вашим внутренним экземплярам EC2.

Я не всезнайка Ansible, но уверен, что есть способ использовать Ansible и сохранить конфиденциальность ваших экземпляров EC2.