Направляет ли ELB также исходящий ответный трафик в AWS?

8

Я пытался понять, как работает маршрутизация в AWS VPC с публичными / частными подсетями.

У меня есть настройки, рекомендованные Amazon с ELB и NAT в общедоступной подсети и веб-сервером в частной подсети. У меня есть группы безопасности (SG), настроенные согласно http://blogs.aws.amazon.com/security/blog/tag/NAT, и все это работает, как и ожидалось. Большой!

Эталонная архитектура с конфигурацией Amazon VPC

Что я еще не понимаю, так это то, как ответы HTTP возвращаются из экземпляра веб-сервера в приведенной выше архитектуре.

Таким образом, веб-запрос поступает из общедоступного Интернета через HTTP, 80 обращаются к ELB, и ELB передает его на частный IP веб-сервера, круто. Теперь веб-сервер должен ответить. Из того, что я понимаю, ответ будет через другой более высокий порт TCP (1024-65535). NAT SG разрешает только исходящий трафик через порты 80 и 443. Так как же этот ответ возвращается в общедоступный Интернет? Это не может пройти через NAT. Означает ли это, что ответ возвращается через ELB? Диаграмма Amazon не указывает стрелку направления трафика ELB как двунаправленную, а также в документации ELB не говорится, что ELB ведет себя как NAT с состоянием. Является ли?

Али
источник

Ответы:

11

Стрелки на диаграмме указывают только направление установления соединения, а не поток трафика.

Да, обратный трафик возвращается через ELB.

Но это не NAT с отслеживанием состояния - это прокси TCP-соединения. Машины ELB принимают TCP-соединения через настроенные порты прослушивания, завершают сеанс SSL, если он настроен таким образом, и устанавливают новое TCP-соединение с внутренним сервером. Если прослушиватель настроен на HTTP, ELB работает в режиме анализа с учетом полезной нагрузки, регистрации и пересылки HTTP-запросов на сервер, в противном случае он не зависит от полезной нагрузки, устанавливая новое соединение TCP 1: 1 с серверной частью. для каждого входящего соединения и «связывания каналов» (без учета или модификации уровня HTTP).

В любом случае, исходный адрес входящего соединения с вашим приложением будет адресом узла ELB, а не исходного клиента. Вот как ответный трафик возвращается в ELB для возврата клиенту.

В режиме http ELB добавляет (или добавляет) X-Forwarded-Forзаголовок, чтобы ваше приложение могло идентифицировать исходный клиентский IP-адрес, а также X-Forwarded-Proto: [ http | https ]указать, использует ли клиентское соединение SSL и X-Forwarded-Portуказать интерфейсный порт.


Обновление: приведенное выше относится к типу балансировщика нагрузки, который теперь известен как «ELB Classic» или ELB / 1.0 (находится в строке агента пользователя, которую он отправляет с проверками работоспособности HTTP).

Более новый балансировщик уровня 7, Application Load Balancer или ELB / 2.0 работает аналогично в отношении потока трафика. Возможность Уровня 4 («прозрачный» TCP) удалена из ALB, а функции уровня 7 значительно улучшены.

Балансировщик нагрузки новейшего типа - сетевой балансировщик нагрузки - это балансировщик уровня 3. В отличие от двух других, он ведет себя очень похоже на динамический NAT, обрабатывая только входящие (внешние) подключения, сопоставляя порт source-addr + через порт EIP-addr + с портом instance-private-ip: adde + - с помощью EIP привязанный к «балансировщику» - и в отличие от двух других типов балансировщиков, экземпляры должны находиться в общедоступных подсетях и использовать для этого свои публичные IP-адреса.

Концептуально говоря, балансировщик сетевой нагрузки, по-видимому, фактически изменяет поведение интернет-шлюза, который сам по себе является логическим объектом, который нельзя отключить, заменить или испытать сбой в каком-либо значимом смысле. Это в отличие от ELB и ALB, которые фактически работают на «скрытых» экземплярах EC2. NLB, судя по всему, работает с сетевой инфраструктурой.

Майкл - sqlbot
источник
Спасибо. Не могли бы вы рассказать о режимах, учитывающих полезную нагрузку и не зависящих от нагрузки? Также может ли веб-сервер знать, было ли исходное соединение через SSL?
Али
Я добавил дополнительную информацию к ответу, чтобы решить эти вопросы.
Майкл - sqlbot
and unlike the other two types of balancers, the instances need to be on public subnets, and use their own public IPs for this. Я очень рад прочитать это. Можете ли вы дать ссылку на эту информацию?
Фелипе Альварес
1
@FelipeAlvarez, как оказалось, полная картина существенно сложнее. Хотя это наиболее интуитивно понятная конфигурация, Network Load Balancer интегрирован с реальной сетевой инфраструктурой таким образом, что он захватывает потоки TCP (предположительно через таблицы состояний сети) из целевых экземпляров и может переписать их и работать, как ожидается, даже если экземпляры не настроены таким образом. Целевым экземплярам нужен маршрут по умолчанию, объявленный в VPC - он не учитывается для возвращаемых пакетов, но все равно должен присутствовать. Отсутствие маршрута по умолчанию создает черную дыру.
Майкл - sqlbot
1

В соответствии с документацией AWS для NLB, это уровень 4, а не уровень 3. Также необязательно, чтобы внутренние или целевые серверы находились в общедоступной подсети. Фактически диапазоны IP-адресов целевых групп должны быть одним из следующих: Ниже перечислены возможные типы целевых объектов:

Экземпляр Цели определяются идентификатором экземпляра.

ip Цели указаны по IP-адресу.

Когда целевым типом является ip, вы можете указать IP-адреса из одного из следующих блоков CIDR:

Подсети VPC для целевой группы

10.0.0.0/8 (RFC 1918)

100.64.0.0/10 (RFC 6598)

172.16.0.0/12 (RFC 1918)

192.168.0.0/16 (RFC 1918)

Важный

Вы не можете указать общедоступные IP-адреса.

Надеюсь, это поможет.

КПБ
источник