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

127

В настройке AWS VPC есть 4 сценария . Но давайте посмотрим на эти два:

  • Сценарий 1: 1 общедоступная подсеть.
  • Сценарий 2: 1 общедоступная подсеть и 1 частная подсеть.

Поскольку любой экземпляр, запущенный в общедоступной подсети, не имеет EIP (если он не назначен), к нему уже нельзя обращаться из Интернета. Затем:

  • Зачем нужна частная подсеть?
  • В чем именно разница между частной и общедоступной подсетями?
Томми
источник
4
Частная подсеть, даже после назначения общедоступного IP-адреса машинам внутри, по-прежнему недоступна из общедоступного Интернета. Я создаю настройки VPC, например, с веб-сервером в общедоступной подсети и моей базой данных в частной подсети. Я могу подключиться к клиентскому шлюзу для доступа к машинам как в частной, так и в общедоступной подсети.
user602525 05

Ответы:

239

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

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

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


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

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

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

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

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

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

Для экземпляров, имеющих только частный IP-адрес, есть альтернативный способ исходящего доступа в Интернет. Здесь на помощь приходят преобразование сетевых адресов² и экземпляр 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 для трафика), а не объект Internet Gateway (который не работает). Входящий трафик из Интернета будет попадать на общедоступный IP-адрес экземпляра, но ответы будут пытаться направить наружу через экземпляр NAT, что либо отбросит трафик (поскольку он будет состоять из ответов на подключения, о которых он не знает, поэтому они 'будет считаться недействительным) или перепишет ответный трафик, чтобы использовать свой собственный общедоступный IP-адрес, что не будет работать, поскольку внешний источник не будет принимать ответы, пришедшие с IP-адреса, отличного от того, с которым они пытались инициировать связь. ,

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

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

Если вашим экземплярам с частными IP-адресами никогда и ни при каких обстоятельствах не потребуется исходящий интернет-трафик, то они технически могут быть развернуты в «общедоступной» подсети и по-прежнему будут недоступны из Интернета ... но при такой конфигурации, для них невозможно создать исходящий трафик в Интернет, который включает соединения с другими сервисами инфраструктуры AWS, опять же, такими как S3 1 или 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)».

Майкл - sqlbot
источник
16
Подробный ответ, но мне все еще интересно. В чем преимущество сервера в частной подсети с экземпляром NAT и общедоступной подсети сервера со строгой политикой безопасности?
abhillman
13
@abhillman на самом деле не о преимуществах. Речь идет о том, как работает сеть в VPC. Все экземпляры в данной подсети должны использовать один и тот же шлюз по умолчанию, который будет либо виртуальным объектом «Интернет-шлюз», который не будет выполнять NAT, либо это будет экземпляр NAT, который не будет «не выполнять» NAT. , Если все ваши машины не имеют общедоступных IP-адресов или ни одна из них не имеет, вам понадобятся оба типа подсетей. Если все является веб-сервером с выходом в Интернет, конечно, вам может понадобиться только общедоступная подсеть, и при правильной настройке безопасности недостатка нет.
Майкл - sqlbot
1
Фактически, теперь можно получить доступ к некоторым ресурсам AWS, таким как S3, из VPC aws.amazon.com/blogs/aws/new-vpc-endpoint-for-amazon-s3 .
avloss
2
@avloss, спасибо, что вернули мое внимание к этому моменту и его значимости для этого ответа. Прошло почти два года без серьезного редактирования, и вы правы - дела продолжают развиваться. Я обновлю это, чтобы упомянуть конечные точки VPC.
Майкл - sqlbot
4
@VirtualJasper вы не должны хотеть , чтобы использовать все-публичные адреса. По возможности рекомендуется использовать частные адреса IPv4. Это уменьшает вашу поверхность атаки. Это дает лучший контроль на выходе. Адресное пространство IPv4 ограничено, и его становится все больше, поэтому есть этический аспект в использовании большего количества этого ресурса, чем вам нужно. Также кажется логичным, что если вы продолжите просить службу поддержки AWS об увеличении разрешенного количества адресов, они в какой-то момент начнут задавать вопросы. VPC был разработан для работы именно таким образом. Можете ли вы взломать систему и использовать все публичные IP-адреса? Да. Это хорошая идея? Нет.
Майкл - sqlbot
27

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

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

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

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

Фил
источник
5
Я не мог с этим согласиться. Чем больше я работаю над вопросами, тем меньше я вижу частные подсети. Это больше похоже на пережиток того, как раньше выглядели локальные сети, и что их существование заключается в основном в знакомстве. Я уверен, что есть крайние случаи, когда они все еще могут быть действительными, но в целом я говорю, что не используйте их. Тот факт, что верхний (и очень длинный ответ) на этот вопрос не касается самого вопроса, указывает на их избыточность.
Карл,
1
Я полностью согласен с теорией здесь, но на практике я обнаружил, что AWS по умолчанию ограничивает вас 20 EIP на регион, и я скептически отношусь к тому, что они захотят увеличить этот лимит, чтобы разрешить сотни общедоступных адресов IPv4. Это скудные ресурсы в Интернете.
Nic
1
@Nic Вам не нужны EIP, помните, речь идет об отказе от NAT - нас не волнует, какой публичный IP-адрес любой безликой машины, и нам все равно, если он изменится.
Фил
1
Сегодня AWS выпустила IPv6 во всем мире. Пусть умрет IPv4. :-)
Фил
3
Отказ от частных подсетей предполагает, что ошибок никогда не бывает. С десятками экземпляров и сотнями пересекающихся между собой правил безопасности и множеством сотрудников, участвующих в обслуживании, нельзя упускать из виду возможность того, что кто-то случайно откроет порт для мира. Защитная позиция, ограничивающая публичный доступ по дизайну несколькими экземплярами, которые в нем нуждаются, - лучший подход к безопасности. Для тех из вас, кто непогрешим, ждите. Для остальных из нас, простых смертных, проявление осторожности - не такая уж ужасная идея.
Джим Уокер
23

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

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

Ежемесячная стоимость управляемого инстанса NAT = 33,48 доллара США в месяц (0,045 доллара США в час * 744 часа в месяц) + 4,50 доллара США (0,045 доллара США за обработанный ГБ данных * 100 ГБ) + 10 долларов США (0,10 доллара США за 1 ГБ стандартной платы за передачу данных AWS для всех данных, передаваемых через NAT-шлюз) = 47,98 $

Экземпляр t2.nano, настроенный как экземпляр NAT = 4,84 доллара США в месяц (0,0065 доллара США * 744 часа в месяц) + 10 долларов США (0,10 доллара США за гигабайт стандартной платы за передачу данных AWS для всех данных, передаваемых через экземпляр NAT) = 14,84 доллара США.

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

Джим Уокер
источник
4
Согласен - однако с экземпляром t2.nano вы увидите максимальную пропускную способность, возможно, 250 Мбит / с по сравнению с кричащим пиком 10 Гбит / с от шлюза NAT. Не поймите меня неправильно, я считаю, что цены тоже немного завышены, и есть другие ограничения - я все еще использую экземпляры NAT практически везде ... но, честно говоря, вы частично платите за довольно серьезная мощность коммутации сырых пакетов и сетевое соединение со шлюзом.
Майкл - sqlbot
1
Но почему NAT Gateway такой дорогой? Требуется ли много компьютерных ресурсов для перевода адресов? Я могу понять, что для действительно огромных приложений NAT может проксировать множество запросов из VPC, но если мы говорим об обычном среднем бизнесе и небольших проектах, 0,045 доллара в час, а каждый гигабайт - это довольно завышенная оценка.
Сергей Черепанов
15

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

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

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

Так почему бы нам этого не сделать? Почему 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, вы можете свободно присоединять / отсоединять эластичный IP-адрес в любое время, и у вас есть свобода изменять группы безопасности, применяемые к вашим экземплярам EC2.

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

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

Nic
источник
4
По умолчанию ограничение для EIP составляет 5 на регион , а не 20. «В конце концов, мое приложение особенное». Это предложение заслуживает отдельной оценки.
Майкл - sqlbot
4
Откуда взялась идея, что вы не можете менять группы безопасности на лету для машины с общедоступным IP-адресом, который не является EIP? Это просто неправда!
Фил
1
@ Фил Правильно. Это утверждение неверно. Утверждение, что вы не можете изменить группу безопасности экземпляра, к которому привязан общедоступный IP-адрес, как бы аннулирует весь его ответ. Я знаю, что это может быть довольно жестко, но как вы можете вводить читателей в заблуждение ложными утверждениями, которые лежат в основе вашего сообщения. В любом случае, я согласен с Ником в том, что вы можете отказаться от частных подсетей и просто использовать общедоступные с надлежащей настройкой брандмауэра,
Geo C.
1
Я удалил неправильные утверждения о невозможности изменить группу безопасности.
JP
Некоторые из этих заявлений до сих пор там;)
Тим Мэлоун