AWS Сбой отслеживания подключения к группе безопасности для ответов с текстом в ASP. NET Базовое приложение, работающее в ECS + Fargate - PullRequest
Новая
       75

AWS Сбой отслеживания подключения к группе безопасности для ответов с текстом в ASP. NET Базовое приложение, работающее в ECS + Fargate

4 голосов
/ 07 мая 2020

В моем приложении:

  • ASP. NET Core 3.1 с Kestrel
  • Запуск AWS ECS + Fargate
  • Службы работают в a publi c su bnet в VP C
  • Задачи слушают только порт 80
  • Publi c Network Load Balancer с завершением SSL

Я хочу настроить группу безопасности, чтобы разрешить входящие соединения из любого места (0.0.0.0/0) на порт 80 и запретить любое исходящее соединение изнутри задачи (за исключением, конечно, ответа на разрешенные запросы).

Как Группы безопасности с отслеживанием состояния , отслеживание соединения должно разрешить выход ответа на запросы.

В моем случае это соединение отслеживание работает только для ответов без тела (только заголовки). Когда у ответа есть тело (в моем случае файл размером> 1 МБ), они не работают. Если я разрешаю исходящие TCP-соединения с порта 80, они также не работают. Но если я разрешаю исходящие TCP-соединения для всего диапазона портов (0-65535), он работает нормально.

Я думаю, это потому, что когда ASP. NET Core + Kestrel записывает тело ответа, он инициирует новое соединение, которое не распознается отслеживанием соединений группы безопасности.

Могу ли я разрешить только ответы на запросы, а не другие исходящие соединения, инициированные приложением?

1 Ответ

3 голосов
/ 29 мая 2020

Значит, мы говорим о чем-то подобном? 

Client 11.11.11.11 ----> AWS NLB/ELB public 22.22.22.22 ----> AWS ECS network router or whatever (kubernetes) --------> ECS server instance running a server application 10.3.3.3:8080 (kubernetes pod)

Вы настраиваете группу безопасности на AWS NLB или на AWS ECS? (Я думаю, оба?)

Группы безопасности должны разрешать входящий трафик c, если вы разрешаете 0.0.0.0/0 порт 80.

Они действительно сохраняют состояние. Они позволят соединению продолжаться в обоих направлениях после его установки (то есть приложение может отправлять ответ).

Однако состояние брандмауэра обычно не сохраняется более 60 секунд (не уверен, какая технология AWS используется using), поэтому соединение может быть "потеряно", если серверу потребуется более 1 минуты для ответа. Требуется ли время для генерации ответа HTTP-серверу? Если это веб-сокет или TCP-сервер, время от времени он тратит целые минуты, не отправляя и не получая никакого трафика c?

Как я это вижу. У нас есть два межсетевых экрана с отслеживанием состояния. Первый с NLB. Второй с ECS.

ECS эквивалентен kubernetes, он должен выполнять тонну iptables magi c для распределения трафика c и отслеживания соединений. (Для справки, обычные кубернеты хорошо работают с iptables, а iptables имеет множество очень важных настроек, таких как длительность соединения и тайм-ауты).

Хорошие новости. Если ломается при открытии inbound 0.0.0.0:80, но работает при открытии inbound 0.0.0.0:80 + outbound 0.0.0.0:*. Это определенно проблема из-за того, что брандмауэр разрывает соединение, скорее всего, из-за потери состояния. (или это вообще не отслеживание состояния, но я почти уверен, что группы безопасности сохраняют состояние).

Отключение может произойти на любом из двух межсетевых экранов. У меня никогда не было проблем с одним голым NLB / ELB, поэтому я предполагаю, что проблема в ECS или их взаимодействии.

К сожалению, мы не можем отладить это, и у нас есть очень мало информации о том, как это работает внутри. Единственный вариант - обратиться в службу поддержки AWS для расследования.

...