это и этот и этот вполне связаны с моим вопросом. Хотя это, кажется, ответило на довольно многие сомнения людей, я все еще изо всех сил пытаюсь понять, относится ли эта настройка к AWS или к сетям в целом. Если последнее, то мне нужно вернуться к своим основам. Подозреваю, что уже и отсюда вопрос.
Мое понимание
Если частная сеть подключена к Интернету, то ее узлы должны иметь общедоступные IP-адреса, чтобы их можно было однозначно идентифицировать в Интернете. Весь трафик в Интернет, входящий или исходящий, происходит с этого общедоступного IP-адреса. Хост из этой сети при подключении к Интернету получает общедоступный IP-адрес. Пакет, исходящий от этого хоста, чтобы сказать www.google.com, будет иметь частный адрес хоста в пакете, который в конечном итоге будет заменен его общедоступным IP-адресом устройством NAT (которое установлено на маршрутизаторе / шлюзе по умолчанию), которое является как показано Вот. Так работает большая часть Интернета (кроме IPV6).
Теперь в AWS
когда вы создаете Частная подсеть (не подключая его к Интернет-шлюзу), вы держите это в секрете. Затем мы сознательно следим за тем, чтобы автоматическое назначение общедоступного IP-адреса отключен. Когда мы запускаем экземпляры EC2 внутри этой частной подсети, мы не видим общедоступные IP-адреса на консоли EC2. Это также означает, что экземпляры в этой подсети не видны в Интернете. Теперь, если я подключу эту частную подсеть к устройству NAT (которое, конечно, находится в общедоступной подсети) (пожалуйста, не путайте меня с тем, что шлюз NAT делает лучше на данный момент), то, по сути, я оставляю устройство NAT для определения общедоступного IP-адреса для назначения для определенного хоста X из частной подсети, которая запросила связь с Интернетом как общедоступный IP-адрес. является необходимо для связи с Интернетом.
Сейчас,
Я думаю, вы неправильно поняли функция шлюза NAT и это приводит ко всем остальным недоразумениям.
NAT не назначает адреса внутренним / частным хостам случайным образом.
Устройство NAT обычно имеет два интерфейса - внутренний с частным IP, например 10.0.0.1. И внешний с публичным IP, например 1.2.3.4.
Хосты из внутренней сети, у которых например есть 10.0.0.x адрес (а не общедоступный) отправляет весь исходящий трафик на Шлюз NAT и этот шлюз NAT заменяет исходный IP в пакете (например, 10.0.0.123) со своим публичный IP (т.е. 1.2.3.4). Затем он отправляет пакет в пункт назначения в Интернете, например загуглить.
Пакеты TCP имеют не только источник и назначение адреса но также источник и место назначения порты. Порт источника также может быть заменен шлюзом NAT, чтобы избежать коллизий, когда несколько хостов пытаются связаться с одними и теми же портами источника.
Объяснение NAT:
Внутренний хост 10.0.0.123 хочет скачать что-то из google.com в 216.58.203.110 через HTTPS, т.е. порт 443.
Он отправляет пакет с источником 10.0.0.123:12345 (адрес: случайный локальный порт) и пункт назначения 216.58.203.110:443 (адрес: порт https) к шлюзу NAT, потому что это лучший следующий прыжок для всех адресов, которые не 10.0.0.x.
Шлюз NAT заменяет источник из 10.0.0.123:12345 на собственный публичный IP-адрес и случайный порт 1.2.3.4:54321.
Он записывает, что соединение с 10.0.0.123:12345 к 216.58.203.110:443 был переведен на 1.2.3.4:54321 в его таблица отслеживания подключений.
Когда ответный пакет от Google приходит на шлюз NAT с местом назначения 1.2.3.4:54321, шлюз ищет эту запись (адрес: порт) и видит, что он должен преобразовать ее обратно в 10.0.0.123:12345 и отправьте его этому хосту на этот порт.
Если в то же время другой хост из локальной сети (например, 10.0.0.99) пытается что-то скачать из Google вот что происходит:
Шлюз NAT снова переводит исходный IP-адрес в свой собственный общедоступный IP-адрес. 1.2.3.4 но исходный порт будет другим, чем раньше, например 56789.
Теперь Google видит два соединения от нашего NAT-шлюза.
1.2.3.4:54321 - чтобы - 216.58.203.110:443 (где шлюз NAT знает, что исходный источник на самом деле 10.0.0.123:12345)1.2.3.4:56789 - чтобы - 216.58.203.110:443 (NAT GW знает, что первоисточник 10.0.0.99:12345).Оба соединения появиться приходить от шлюза NAT, но на самом деле они были инициированы от разных хозяев во внутренней сети. Отображение известно только шлюзу NAT.
Вот и все в двух словах.
Теперь пара замечаний:
Ты не можешь положить начало связи снаружи к хосту за NAT. Вы можете отправлять ответы только на пакеты, инициированные изнутри.
Это потому, что соответствие между внутренними IP:port и шлюз NAT IP:port выполняется, когда внутренний хост отправляет первый пакет.
Если вы хотите использовать SSH для 10.0.0.123:22 извне, как бы вы это сделали? Вы можете отправить пакет SSH на IP-адрес шлюза NAT. 1.2.3.4 но какой порт? Видите ли, нет никакого сопоставления, поэтому невозможно инициировать соединение извне.
Маршрутизаторы с другой стороны, не меняйте IP-адреса или порты (в отличие от шлюзов NAT). Они пропускают пакеты практически без изменений.
В контексте AWS Маршрутизатор является IGW = Интернет-шлюз. NAT может быть либо NAT-шлюз или Экземпляр NAT, они делают то же самое.
Надеюсь, это объясняет это :)
Это скорее (большой) вспомогательный комментарий к ответу @ MLu выше, в котором цитируются соответствующие фрагменты из официальных документов AWS, которые проливают свет на то, что Internet Gateway и NAT-устройства делают в AWS.
Из Документация AWS »Amazon VPC» Руководство пользователя »Сетевые компоненты VPC» NAT:
Мы используем термин NAT в этой документации, чтобы следовать общепринятой ИТ-практике, хотя фактическая роль устройства NAT заключается как в преобразовании адресов, так и в преобразовании адресов портов (PAT).
Устройство NAT специально предназначено для того, чтобы позволить хостам в частной сети получать доступ к внешней сети (Интернету) через Устройство NAT, которое выполняет PAT.
Итак, если в частной подсети есть хост с IP-адресом 10.0.1.1/32, и он отправляет запрос на google.com (216.58.211.174/32), устройство NAT записывает сопоставление из 10.0.1.1:SOMESOURCEPORT в 216.58.211.174:SOMEDESTPORT и изменяет исходный IP-адрес в запросе (пакете) на это публичный NAT-PUB-IP: SOMERANDOMPORT.
Записанное сопоставление будет: 10.0.1.1:SOMESOURCEPORT --❯ NAT-PUB-IP:SOMERANDOMPORT
Когда он снова получит ответ NAT-PUB-IP:SOMERANDOMPORT, то поиск записанных сопоставлений покажет, что ответ должен вернуться к 10.0.1.1.
Все внутренние IP-адреса преобразуются в единственный общедоступный IP-адрес, назначенный устройству NAT. Мультиплексирование соединений зависит от устройства NAT, которое однозначно идентифицирует внутренние хосты на основе SOMERANDOMPORT.
Это также означает, что если внутренним хостам назначен публичный IP-адрес, для устройства NAT это не имеет значения, поскольку оно выполняет PAT только для внутренних IP-адресов.
Это также выполняет NAT, но в отличие от вышеупомянутого, он выполняет статический NAT. Проще говоря, статическая запись выглядит следующим образом:
Internal HOST IP <-> Public IP Assigned to the Internal Host
Обратите внимание, что хост внутри AWS VPC знает только о своем собственном частном IP-адресе в VPC. Назначенный ему публичный IP-адрес используется только Интернет-шлюзом.
Для того же запроса, что и выше (внутренний хост для google.com), если
10.0.1.1 -> Public_IP_Of_Internal_Host
и когда он получает ответ с местом назначения Public_IP_Of_Internal_Host это просто переводится обратно на 10.0.1.1
Из https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Internet_Gateway.html
Интернет-шлюз служит двум целям: предоставить цель в таблицах маршрутов VPC для маршрутизируемого из Интернета трафика и выполнить преобразование сетевых адресов (NAT). для экземпляров, которым были назначены общедоступные адреса IPv4.
Как указывалось ранее, причина, по которой требуется назначенный общедоступный IP-адрес, заключается в том, что IGW может выполнять только статический NAT и, следовательно, требует общедоступного IP-адреса для создания сопоставления между этим и внутренним IP-адресом хоста.