Экземпляр в частной подсети AWS со шлюзом NAT не может получить доступ к сервисам AWS

У нас есть экземпляр в частной подсети, который имеет управляемый шлюз NAT. В этом случае мы можем получить доступ к Интернету:

$ curl https://www.google.com/
<!doctype html><html itemscope="" itemtype="http://schema.org/WebPage" lang="en"><head>...

Тем не менее, мы не можем получить доступ к конечной точке cloudwatch, например, в следующем тайм-ауте: (РЕДАКТИРОВАТЬ: Моя ошибка, не конечная точка cloudwatch, а сайт, на котором хранятся сценарии мониторинга cloudwatch.)

$ curl https://cloudwatch.s3.amazonaws.com

DNS не проблема:

$ dig cloudwatch.s3.amazonaws.com
cloudwatch.s3.amazonaws.com. 2303 IN    CNAME   s3-1-w.amazonaws.com.
s3-1-w.amazonaws.com.   1   IN  A   54.231.72.59

Есть идеи о том, что может происходить?

Источник

3 ответа

Решение

Добавление конечной точки S3 в частную подсеть решило проблему.

Оказывается, наша проблема была связана с доступом к S3. Наша установка в то время была:

  • NAT-шлюз работает в публичной подсети
  • Конечная точка S3 в публичной подсети (с более высоким приоритетом маршрутизации, чем интернет-шлюз)
  • Правило по умолчанию для трафика в частных подсетях, проходящего через NAT.

Похоже, что трафик не проходил через NAT к S3 ни через общедоступный Интернет, ни через конечную точку S3. Я до сих пор не знаю, почему.

Источник

У меня фактически была та же проблема, и мне удалось решить ее так же, как это делал Джастин ХК ниже. Я связался с AWS, чтобы понять, почему это произошло, потому что я не мог его отпустить, поэтому это должно помочь объяснить поведение. Вот разбивка:

  • Проблема не в том, что трафик не может добраться до места назначения, а в том, что трафик не может правильно вернуться к источнику.
  • Поскольку общедоступная подсеть (где находится шлюз NAT) имеет 2 варианта для достижения пункта назначения - либо через VPCE (конечная точка VPC), либо через IGW (интернет-шлюз), она не знает, какую из них выбрать при запросе. возвращаюсь обратно Так как он не знает, какой из них выбрать - это просто время ожидания.
  • Маршрутизация выбирает путь наименьшего сопротивления, поэтому добавление VPCE в частную подсеть сделало маршрут VPCE идеальным маршрутом. Хотя здесь стоит упомянуть, что запрос вообще не проходит через общедоступную подсеть, поскольку теперь он имеет VPCE в частной подсети.

В зависимости от настройки, которую вы используете, и от того, нужен ли вам IGW для чего-то еще, кроме обращения к S3, можно либо удалить IGW из общедоступной подсети, либо сбросить связь шлюза NAT между частной и общедоступной подсетями. Обе эти опции должны немного очистить таблицы маршрутизации, не нарушая решения.

Источник

Во-первых, очевидное: cloudwatch.s3.amazonaws.com не является одной из конечных точек Cloudwatch.

Конечные точки Cloudwatch находятся в форме monitoring.[aws-region].amazonaws.com,

Например, в us-west-2 регион, конечная точка https://monitoring.us-west-2.amazonaws.com,

http://docs.aws.amazon.com/general/latest/gr/rande.html

Кроме того, даже если ваша маршрутизация, NAT или сеть настроены неправильно, DNS-разрешение защищено от многих неправильных настроек из-за того, как оно реализовано в VPC... поэтому тот факт, что он работает, не говорит о наличии подключения к Интернету., в общем.

Источник
Другие вопросы по тегам