Стрелки на диаграмме указывают только направление установления соединения, а не поток трафика.
Да, обратный трафик возвращается через 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, судя по всему, работает с сетевой инфраструктурой.
and unlike the other two types of balancers, the instances need to be on public subnets, and use their own public IPs for this.
Я очень рад прочитать это. Можете ли вы дать ссылку на эту информацию?В соответствии с документацией 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-адреса.
Надеюсь, это поможет.
источник