Маршрутизирует ли ELB также исходящий ответный трафик в AWS?
Я пытался понять, как работает маршрутизация в AWS VPC с общедоступными / частными подсетями.
У меня есть установка, рекомендованная Amazon, с ELB и NAT в общедоступной подсети и веб-сервером в частной подсети. У меня есть группы безопасности (SG), настроенные согласно http://blogs.aws.amazon.com/security/blog/tag/NAT и все работает как положено. Большой!
Я еще не понимаю, как HTTP-ответы возвращаются от экземпляра веб-сервера в вышеупомянутой архитектуре.
Таким образом, веб-запрос приходит из общедоступного Интернета через HTTP, 80 обращений к ELB, а ELB переводит его на частный IP-адрес веб-сервера, круто. Теперь веб-сервер должен ответить. Насколько я понимаю, ответ будет через другой TCP-порт более высокого уровня (1024-65535). NAT SG разрешает исходящий трафик только через порты 80 и 443. Итак, как этот ответ возвращается в общедоступный Интернет? Он не может проходить через NAT. Означает ли это, что ответ возвращается через ELB. На диаграмме Amazon стрелка направления трафика ELB не указана как двунаправленная, а в документации ELB не указано, что ELB ведет себя как NAT с отслеживанием состояния. Является ли?
Стрелки на схеме указывают только направление установления соединения, но не поток трафика.
Да, обратный трафик идет обратно через 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 значительно улучшены.
Новейший тип балансировщика нагрузки, Network Load Balancer, представляет собой балансировщик уровня 3. В отличие от двух других, он ведет себя очень похоже на динамический NAT, обрабатывая только входящие (исходящие извне) соединения, сопоставляя source-addr + port через EIP-addr + port с instance-private-ip: adde + port - с EIP привязаны к «балансировщику» - и в отличие от двух других типов балансировщиков, экземпляры должны находиться в общедоступных подсетях и использовать для этого свои собственные общедоступные IP-адреса.
С концептуальной точки зрения, балансировщик сетевой нагрузки, кажется, фактически изменяет поведение Интернет-шлюза, который сам по себе является логическим объектом, который нельзя отключить, заменить или вызвать сбой в каком-либо значимом смысле. В этом отличие от ELB и ALB, которые фактически работают со «скрытыми» экземплярами EC2. NLB, судя по всему, оперирует самой сетевой инфраструктурой.
Согласно документации AWS для NLB, это уровень 4, а не уровень 3. Также не требуется, чтобы бэкэнд или целевые серверы находились в общедоступной подсети. На самом деле диапазоны IP-адресов целевых групп должны быть одним из следующих: Ниже перечислены возможные типы целей:
instance Цели указываются идентификатором экземпляра.
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-адреса.
Надеюсь, это поможет.