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

AWS: шлюз NAT в общедоступной подсети. Зачем?

Насколько я понимаю, общедоступная подсеть - это та, которая может направлять трафик в Интернет через Интернет-шлюз, а частная подсеть - это подсеть, которая не может (не может получить доступ к Интернету и не может быть достигнута из него). Чтобы получить доступ к Интернету, частная подсеть должна направлять трафик через шлюз NAT.

Я могу подтвердить это, потому что на самом деле я успешно использую эту настройку.

Но Документы Amazon скажем иначе (выделено мной жирным шрифтом):

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

Имеет ли значение, где находится шлюз NAT? Если да, то каковы варианты использования его в частной / публичной подсети?

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

Вот что делает общедоступную подсеть общедоступной.

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

Напротив, частная подсеть - это подсеть без такого маршрута. Обычно маршрут по умолчанию для частной подсети указывает на устройство NAT, хотя он может указывать на аппаратное соединение VPN или Direct Connect.

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

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

Если вы думаете в терминах LAN, естественным предположением является то, что устройство NAT должно быть "включено" как минимум в 2 подсети, внешнюю (общедоступные) подсети и внутреннюю (частные адреса) подсеть, но сеть VPC является не LAN, как кажется. Это программно определяемая сеть уровня 3, которая очень чисто имитирует Ethernet, но это не Ethernet.

NACL и таблицы маршрутов применяются к NAT-шлюзу, поэтому вы можете рассматривать NAT-шлюз как еще один экземпляр EC2, и, следовательно, он должен находиться в общедоступной подсети для доступа к интернет-шлюзу и маршрутизации трафика.

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

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

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