Зачем нужна частная подсеть в VPC?

Ответ 1

Обновление: в конце декабря 2015 года AWS анонсировала новую функцию Управляемый NAT Gateway для VPC. Эта дополнительная услуга предоставляет альтернативный механизм для экземпляров VPC в частной подсети для доступа к Интернету, где ранее общее решение было экземпляром EC2 в общей подсети в VPC, функционирующей как "экземпляр NAT", обеспечивающий трансляцию сетевых адресов ( технически, преобразование адресов порта) для экземпляров в других частных подсетей, позволяющих этим машинам использовать публичный IP-адрес экземпляра NAT для исходящего доступа к Интернету.

Новая управляемая служба NAT принципиально не изменяет применимость следующей информации, но этот вариант не рассматривается в следующем ниже содержании. Экземпляр NAT можно использовать, как описано, или вместо него можно настроить службу управляемого шлюза NAT. Расширенная версия этого ответа, включающая дополнительную информацию о NAT Gateway и том, как она сравнивается с экземпляром NAT, будет доступна, так как они имеют отношение к частной/публичной парадигме подсети в VPC.

Обратите внимание, что Интернет-шлюз и шлюз NAT - это две разные функции. Все конфигурации VPC с доступом в Интернет будут иметь виртуальный объект Internet Gateway.

Чтобы понять различие между "private" и "общедоступными" подсетями в VPC Amazon, необходимо понимать, как работают IP-маршрутизация и трансляция сетевых адресов (NAT), и как они специально реализованы в VPC.

Основное различие между публичной и частной подсети в VPC определяется тем, что этот маршрут по умолчанию для подсети, в таблицах маршрутизации VPC.

Эта конфигурация, в свою очередь, диктует обоснованность использования или не использования общедоступных IP-адресов для экземпляров в этой конкретной подсети.

Каждая подсеть имеет ровно один маршрут по умолчанию, который может быть только одним из двух:

• объект VPC "Интернет-шлюз" , в случае "общедоступной" подсети или
• устройство NAT, то есть либо NAT-шлюз, либо экземпляр EC2, выполняющий роль "NAT-экземпляр" в случае подсети "private".

Интернет-шлюз не выполняет трансляции сетевых адресов для экземпляров без общедоступных IP-адресов, поэтому экземпляр без публичного IP-адреса не может подключаться наружу к Интернету - выполнять такие функции, как загрузка обновлений программного обеспечения или доступ к другим ресурсам AWS, таким как S3 ¹ и SQS - если маршрут по умолчанию в подсети VPC является объектом интернет-шлюза. Итак, если вы являетесь экземпляром в "общедоступной" подсети, вам нужен публичный IP-адрес, чтобы сделать значительное количество вещей, которые обычно нужно выполнять серверам.

Для экземпляров с только частным IP-адресом существует альтернативный способ исходящего доступа к Интернету. В этом случае Network Address Translation & sup2; и появляется экземпляр NAT.

Машины в частной подсети могут получить доступ к Интернету, поскольку маршрут по умолчанию в частной подсети не является объектом VPC "Интернет-шлюз" - это экземпляр EC2, настроенный как экземпляр NAT.

Экземпляр NAT - это экземпляр в общедоступной подсети с общедоступным IP-адресом и конкретной конфигурацией. Есть AMI, которые предварительно созданы для этого, или вы можете создавать свои собственные.

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

Таким образом, при доступе к внешнему интернет-ресурсу из частной подсети трафик обходит экземпляр NAT и появляется для адресата, исходящего из общедоступного IP-адреса экземпляра NAT... поэтому трафик ответа возвращается к NAT. Ни группа безопасности, назначенная для экземпляра NAT, ни группа безопасности, назначенная для частного экземпляра, не должны быть настроены так, чтобы "разрешать" этот ответный трафик, поскольку группы безопасности являются работоспособными. Они понимают, что трафик ответов коррелирован с сеансами, происходящими изнутри, поэтому он автоматически разрешен. Конечно, неожиданный трафик отклоняется, если группа безопасности не настроена на его разрешение.

В отличие от обычной IP-маршрутизации, где ваш шлюз по умолчанию находится в одной и той же подсети, способ, которым он работает в VPC, отличается: экземпляр NAT для любой частной подсети всегда находится в другой подсети, а другая подсеть всегда является общедоступной подсети, потому что экземпляр NAT должен иметь открытый внешний IP-адрес, а его шлюз по умолчанию должен быть объектом VPC "Интернет-шлюз" .

Аналогично... вы не можете развернуть экземпляр с открытым IP-адресом в частной подсети. Это не работает, потому что маршрут по умолчанию в частной подсети (по определению) является экземпляром NAT (который выполняет NAT в трафике), а не объектом интернет-шлюза (а это не так). Входящий трафик из Интернета попадает в общий IP-адрес экземпляра, но ответы будут пытаться маршрутизировать наружу через экземпляр NAT, который либо снизит трафик (поскольку он будет состоять из ответов на соединения, о которых он не знает, поэтому они 'd считается недопустимым) или переписывает трафик ответа на использование своего собственного общедоступного IP-адреса, который не будет работать, поскольку внешнее происхождение не будет принимать ответы, которые поступают с IP-адреса, отличного от того, который они пытались инициировать.

В сущности, тогда "private" и "общедоступные" обозначения на самом деле не касаются доступности или недоступности из Интернета. Они относятся к типам адресов, которые будут назначены экземплярам в этой подсети, что имеет значение из-за необходимости переводить или избегать перевода - эти IP-адреса для взаимодействия с Интернетом.

Поскольку VPC имеет неявные маршруты из всех подсетей VPC во все другие подсети VPC, маршрут по умолчанию не играет роли во внутреннем потоке VPC. Экземпляры с частными IP-адресами будут подключаться к другим приватным IP-адресам в VPC "от" своего частного IP-адреса, а не "от" их общедоступного IP-адреса (если они есть)... пока адрес назначения является другим частным адресом внутри VPC.

Если ваши экземпляры с частными IP-адресами никогда, ни при каких обстоятельствах, не должны исходить из исходящего интернет-трафика, тогда они технически могут быть развернуты в "общедоступной" подсети и все равно будут недоступны из Интернета... но при таких конфигурации, для них невозможно создать исходящий трафик в Интернет, который включает в себя соединения с другими службами инфраструктуры AWS, опять же, как S3 ¹ или SQS.

^{1. Что касается S3, в частности, говорить о том, что доступ к Интернету всегда необходим, это упрощение, которое, вероятно, будет увеличиваться с течением времени и распространяться на другие службы AWS, поскольку возможности VPC продолжают расти и развиваться. Существует относительно новая концепция, называемая конечной точкой VPCчто позволяет вашим экземплярам, ​​в том числе с частными IP-адресами, напрямую обращаться к S3 из выбранных подсет в VPC, не затрагивая "Интернет" и не используя NAT-экземпляр или шлюз NAT, но для этого требуется дополнительная настройка и только для доступа к ковшим в пределах того же региона AWS, что и ваш VPC. По умолчанию S3, который на момент написания этой статьи является единственным сервисом, который открыл возможность создания конечных точек VPC, доступен только изнутри VPC через Интернет. Когда вы создаете конечную точку VPC, создается префиксный список (pl-xxxxxxxx), который вы можете использовать в своих таблицах маршрутов VPC для отправки трафика, привязанного к этой конкретной службе AWS, непосредственно к службе через виртуальный объект "VPC Endpoint". Он также решает проблему ограничения исходящего доступа к S3 для конкретного экземпляра, поскольку список префикса может использоваться в исходящих группах безопасности вместо IP-адреса назначения или блока - и конечная точка S3 VPC может подвергаться дополнительным политическим утверждениям, ограничивая доступ к ведру изнутри, по желанию.}

^{2. Как отмечается в документации, на самом деле обсуждаются здесь как порт, так и трансляция сетевых адресов. Обычно, хотя технически немного неточно, ссылаться на комбинированную операцию как "NAT". Это несколько похоже на то, как многие из нас склонны говорить "SSL", когда мы на самом деле имеем в виду "TLS". Мы знаем, о чем мы говорим, но мы не используем наиболее правильное слово для его описания. " Примечание. Мы используем термин NAT в этой документации для соблюдения общей практики ИТ, хотя фактическая роль устройства NAT - это как преобразование адресов, так и трансляция адресов портов (PAT).}

Ответ 2

У меня нет репутации, чтобы добавить комментарий к Майклу выше, поэтому добавление моего комментария в качестве ответа.

Стоит отметить, что управляемый шлюз AWS в 3 раза дороже, чем на дату, когда по сравнению с запуском собственного экземпляра. Это, конечно, предполагает, что вам нужен только один экземпляр NAT (т.е. У вас нет нескольких экземпляров NAT, настроенных на переход на другой ресурс и т.д.), Что обычно справедливо для большинства сценариев с малым и средним использованием. Предполагая ежемесячную передачу данных в 100 ГБ через шлюз NAT,

Управляемый ресурс NAT ежемесячно = $33,48/месяц ($ 0,045/час * 744 часа в месяц) + $4,50 ($ 0,045 за обработанные данные в формате GB * 100 ГБ) + $10 ($.10/ГБ стандартная плата за передачу данных AWS для всех данных передается через шлюз NAT) = $47.98

t2.nano экземпляр, сконфигурированный как экземпляр NAT = $4.84/month ($ 0.0065 * 744 часа в месяц) + $10 ($.10/GB стандартная плата за передачу данных AWS для всех данных, переданных через экземпляр NAT) = $14.84

Это, конечно, меняется, когда вы переходите на избыточные экземпляры NAT, поскольку управляемый AWS шлюз NAT имеет встроенную избыточность для высокой доступности. Если вам не нужны дополнительные 33 долл. США в месяц, тогда управляемый экземпляр NAT определенно стоит уменьшенной головной боли, не имея необходимости поддерживать другой экземпляр. Если вы используете экземпляр VPN (например, OpenVPN) для доступа к вашим экземплярам в VPC, вы можете просто настроить этот экземпляр так же, как ваш шлюз NAT, а затем вам не нужно поддерживать дополнительный экземпляр только для NAT ( хотя некоторые люди могут недооценить идею объединения VPN и NAT).

Ответ 3

Я бы предложил разные подсечки "private" и ящики/шлюзы NAT. Они не нужны. Если вы не хотите, чтобы машина была доступна из Интернета, не помещайте ее в группу безопасности, которая допускает такой доступ.

Отбрасывая экземпляр/шлюз NAT, вы устраняете текущую стоимость экземпляра/шлюза, и вы устраняете ограничение скорости (будь то 250 или 10 Гбит).

Если у вас есть машина, которая также не нуждается в доступе к Интернету напрямую (и я бы спросил, как вы ее исправляете *), то, во всяком случае, не назначайте публичный IP-адрес.

* Если ответ здесь - это какой-то прокси-сервер, ну, у вас возникают накладные расходы, но каждый на свой счет.

Ответ 4

Ответ Michael - sqlbot делает неявное предположение, что частные IP-адреса требуются. Я думаю, что стоит поставить под сомнение это предположение - нужно ли вообще использовать частные IP-адреса? По крайней мере один комментатор задал тот же вопрос.

В чем преимущество сервера в частной подсети с экземпляром NAT [vs.] сервером [в общей] подсети с строгой политикой безопасности? - abhillman 24 июн 14 в 23:45

Представьте сценарий, в котором вы используете VPC, и назначаете публичные IP-адреса всем вашим экземплярам EC2. Не беспокойтесь, это не значит, что они обязательно доступны через Интернет, потому что вы используете группы безопасности для ограничения доступа точно так же, как с EC2 classic. Используя общедоступные IP-адреса, вы можете легко подвергать определенные услуги ограниченной аудитории без необходимости использовать что-то вроде ELB. Это освобождает вас от необходимости настраивать экземпляр NAT или шлюз NAT. И так как вам нужно вдвое меньше подсетей, вы можете выбрать меньшее распределение CIDR для своего VPC, или вы можете сделать большие подсети с VPC того же размера. И меньше подсетей означает, что вы также будете платить меньше за трафик между AZ.

Итак, почему бы нам не сделать это? Почему AWS говорит, что лучше использовать частные IP-адреса?

У Amazon Web Services ограниченный доступ к общедоступным IPv4-адресам, потому что Интернет в целом имеет ограниченный объем публичных адресов IPv4. В их интересах для вас использовать частные IP-адреса, которые являются фактически неограниченными, а не чрезмерно потребляют скудные общедоступные IPv4-адреса. Вы можете увидеть некоторые доказательства этого в том, как AWS оценивает эластичные IP-адреса; EIP, прикрепленный к экземпляру, является бесплатным, но неиспользованный EIP стоит денег.

Но ради аргумента предположим, что нас не волнует нехватка публичных IPv4-адресов в Интернете. В конце концов, мое приложение является особенным. Что будет дальше?

Существует только два способа подключения публичного IP-адреса к экземпляру EC2 в VPC.

1. Связанный публичный IP-адрес

Вы можете запросить общедоступный IP-адрес при запуске нового экземпляра EC2. Этот параметр отображается как флажок в консоли, а флаг - associate-public-ip-address при использовании aws-cli, и как флаг AssociatePublicIpAddress во встроенном объекте сетевого интерфейса при использовании CloudFormation. В любом случае публичный IP-адрес присваивается eth0 (DeviceIndex = 0). Вы можете использовать этот подход только при запуске нового экземпляра. Однако это связано с некоторыми недостатками.

Недостаток заключается в том, что изменение группы безопасности экземпляра, использующего объект встроенного сетевого интерфейса, заставит немедленную замену экземпляра, по крайней мере, если вы используете CloudFormation.

Другим недостатком является то, что публичный IP-адрес, назначенный таким образом, будет потерян, когда экземпляр будет остановлен.

2. Эластичный IP

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

... Но AWS ограничивает вас 5 EIP для каждого региона. Вы можете запросить больше, и ваш запрос может быть предоставлен. Но AWS может так же отрицать эту просьбу, основываясь на рассуждениях, упомянутых выше. Поэтому вы, вероятно, не хотите полагаться на EIP, если планируете когда-либо масштабировать свою инфраструктуру за пределами 5 экземпляров EC2 для каждого региона.

В заключение, использование общедоступных IP-адресов приносит некоторые полезные преимущества, но вы будете сталкиваться с проблемами администрирования или масштабирования, если вы попытаетесь использовать только публичные IP-адреса. Надеюсь, это поможет проиллюстрировать и объяснить, почему лучшие практики являются такими, какими они есть.