Объясните механизм, благодаря которому виртуальная машина в приватной подсети может инициировать соединения в интернет без входящей доступности из интернета.
Виртуальная машина отправляет исходящий трафик через NAT-шлюз, размещённый в публичной подсети. NAT заменяет её приватный адрес на свой публичный адрес и сохраняет состояние соединения, поэтому ответы возвращаются к инициатору, а новые входящие подключения к виртуальной машине не создаются.
Приватные адреса не маршрутизируются напрямую через публичный интернет. NAT появился как способ экономить ограниченное пространство IPv4-адресов и позволять множеству внутренних узлов использовать один или несколько публичных адресов.
В облаках этот механизм дополнительно решает задачу изоляции: вычислительные ресурсы могут получать обновления и обращаться к внешним сервисам, не получая собственных публичных адресов.
В приватной подсети у виртуальной машины обычно нет публичного адреса и маршрута, по которому интернет мог бы напрямую доставить ей пакет. При этом приложению могут требоваться внешние зависимости: репозитории пакетов, платёжные сервисы, системы мониторинга или API поставщиков.
Если выдать машине публичный адрес, упрощается исходящий доступ, но увеличивается поверхность атаки. Если полностью запретить выход, повышается изоляция, однако ломаются обновления и интеграции. Ошибка в маршруте или обратном пути приводит к тайм-аутам даже при корректно работающем NAT.
Для исходящего соединения приватная машина отправляет пакет на маршрут по умолчанию, ведущий к NAT-шлюзу. Шлюз меняет исходный приватный IP-адрес и, как правило, исходный порт на собственный публичный адрес и уникальный порт, после чего отправляет пакет через интернет-шлюз.
NAT хранит таблицу соответствий между внутренним соединением и внешним отображением. Когда удалённый сервер отвечает, NAT по этой таблице восстанавливает адрес и порт приватной машины и передаёт пакет обратно. Поэтому ответ на соединение, инициированное изнутри, разрешается, а произвольный новый входящий трафик без существующего соответствия отбрасывается.
Обычно приватная подсеть направляет внешний трафик на NAT-шлюз, а публичная подсеть самого NAT-шлюза имеет маршрут к интернет-шлюзу. NAT-шлюз не заменяет правила сетевой безопасности: группы безопасности, списки доступа и сетевые политики по-прежнему могут разрешать или запрещать исходящие соединения.
Такой подход имеет стоимость и ограничения. Управляемый NAT-шлюз обычно оплачивается за время работы и объём обработанного трафика, а его отказ или исчерпание доступных портов может нарушить исходящие соединения. Для доступа к облачным объектным хранилищам и другим внутренним сервисам часто выгоднее использовать частные конечные точки, чтобы не отправлять трафик через NAT.
NAT не является полноценным средством защиты приложения: если приватная машина сама установила соединение с вредоносным или скомпрометированным узлом, ответы и дальнейший трафик этого соединения могут проходить. Кроме того, исходящий NAT обычно затрудняет входящие подключения по инициативе внешнего узла и может мешать протоколам, которым требуется адресуемость с обеих сторон.
Приватные серверы приложения должны скачивать обновления и обращаться к внешнему API, но принимать соединения они должны только от внутренного балансировщика. Рассматривались три варианта: выдать серверам публичные адреса, полностью закрыть интернет-доступ или направить трафик через NAT-шлюз.
Публичные адреса упростили бы маршрутизацию, но увеличили бы поверхность атаки и требования к защите каждого сервера. Полный запрет выхода повысил бы изоляцию, однако потребовал бы ручного зеркалирования пакетов и усложнил интеграции. Выбран был NAT-шлюз с ограниченными исходящими правилами, а для часто используемых облачных сервисов — частные конечные точки.
В результате серверы сохранили доступ к необходимым внешним ресурсам без публичных адресов, а трафик к внутренним сервисам перестал зависеть от NAT. Дополнительно контролировались расходы, лимиты соединений и доступность NAT-шлюзов в зонах отказа.
Ответ: NAT обрабатывает уже доставленный ему трафик, но не создаёт маршрут автоматически. Таблица маршрутизации приватной подсети должна направлять внешний трафик на NAT-шлюз, а подсеть NAT-шлюза — на интернет-шлюз. Если любой из этих маршрутов отсутствует или указывает не на тот компонент, пакет не дойдёт до NAT либо ответ не вернётся обратно.
Ответ: NAT должен различать одновременные потоки по комбинации адресов и портов и хранить соответствующие записи. Для одного публичного адреса доступен конечный диапазон исходных портов, а записи также некоторое время живут в состоянии ожидания после закрытия соединения. При высокой конкуренции возможны исчерпание портов и рост задержек; проблему решают уменьшением числа соединений, повторным использованием соединений, распределением нагрузки по нескольким NAT-адресам или переходом к частным конечным точкам там, где это возможно.
Ответ: Исходящий NAT создаёт отображение только после того, как внутренний узел сам начал соединение. У внешнего клиента заранее нет соответствующей записи, поэтому его новый входящий пакет не знает, к какой приватной машине и порту его направлять. Для контролируемого входящего доступа применяют балансировщик, обратный прокси, VPN, bastion-хост или явно настроенное перенаправление портов; выбор зависит от требуемой модели доступа и уровня изоляции.