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

Question 1

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

Да, обратный трафик проходит через 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+port через EIP-addr+port с instance-private-ip:adde+port — с EIP, привязанным к «балансировщику» — и в отличие от двух других типов балансировщиков, экземпляры должны находиться в публичных подсетях и использовать для этого свои собственные публичные IP-адреса.

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

Answer

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

Да, обратный трафик проходит через 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+port через EIP-addr+port с instance-private-ip:adde+port — с EIP, привязанным к «балансировщику» — и в отличие от двух других типов балансировщиков, экземпляры должны находиться в публичных подсетях и использовать для этого свои собственные публичные IP-адреса.

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

Question 2

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

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

ip Цели указываются по IP-адресу.

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

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

10.0.0.0/8 (RFC 1918)

100.64.0.0/10 (RFC6598)

172.16.0.0/12 (RFC 1918)

192.168.0.0/16 (RFC 1918)

Важный

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

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

Answer