Может ли сервисная структура Azure использовать обратный прокси-сервер в качестве пограничного прокси-сервера после балансировщика нагрузки

Какой в ​​этом смысл, если не использовать его в качестве общедоступного шлюза? Где сказано, что не рекомендуется размещать публичный www? - person Mardoxx; 07.05.2017

Вот почему я задал этот вопрос. Использует ли этот обратный прокси-сервер http.sys? Веб-прослушиватель нельзя использовать в службе с отслеживанием состояния. Пустельга не может быть лицом к лицу. Кажется, что обратный прокси-сервер должен быть общедоступным при маршрутизации трафика в службу с отслеживанием состояния. Структура службы Azure должна предоставить подтверждение, может ли обратный прокси-сервер работать или нам нужен другой более надежный прокси-сервер между обратным прокси-сервером и балансировщиком нагрузки. - person lixuanzhu; 08.05.2017

На странице документации: docs.microsoft.com/en -us/azure/service-fabric/, в разделе Доступ к микросервисам через обратный прокси из-за пределов кластера, MS описывает, что вы можете настроить свой LB для использования порта вашего прокси. Это означает, что MS по-прежнему хочет, чтобы вы использовали LB впереди, если это так. - person Per B; 09.05.2017

Что касается Kestrel, MS работает над тем, чтобы сделать его более сильным, чтобы его можно было использовать извне без IIS или LB впереди, если это так. Команда .net подтвердила это несколько месяцев назад. Я не удивлюсь, если они объявят об этом, когда .Net Core 2 станет RTW. Это имеет смысл, если команда SF ждет этого. Когда Kestrel поддерживается, они могут сказать, что вы можете использовать внешний обратный прокси-сервер без LB. - person Per B; 09.05.2017

Для службы Azure Fabric балансировщик нагрузки уже предоставляется, если вы заказываете кластер. Достаточно ли хорош этот балансировщик нагрузки — обратный прокси-сервер — конфигурация пустельги даже сейчас? - person lixuanzhu; 09.05.2017

Вам по-прежнему нужен балансировщик нагрузки перед вашим обратным прокси-сервером или службами, потому что обратный прокси-сервер — это не что иное, как служба, подобная вашим службам приложений, и она будет работать на всех узлах в вашем кластере, балансировщик нагрузки будет балансировать нагрузку, чтобы избежать только один прокси-сервер обрабатывает все запросы и делает ваши службы более устойчивыми. Kestrel недостаточно безопасен, чтобы его можно было раскрыть, поэтому у вас должен быть доступ к нему только внутри вашего кластера. Как описано @PerB, вам все еще нужен уровень защиты, и он будет находиться перед вашим балансировщиком нагрузки. - person Diego Mendes; 10.05.2017

@DiegoMendes Azure LB — это L4 LB, поэтому не обеспечивает никакой защиты. Так небезопасно ли просто использовать PublicIP -> Azure LB -> Resolve to SF RP? - person Mardoxx; 17.05.2017

@Mardoxx, как я сказал в последней части своего сообщения, «вам все еще нужен уровень защиты, и он будет находиться перед вашим балансировщиком нагрузки». Клиент -> Домен -> WAF -> LoadBalancer -> Прокси -> SF Services с пустельгой - person Diego Mendes; 19.05.2017

Обратный прокси-сервер @DiegoMendes построен на API, аналогичном http.sys, поэтому, возможно, в этом нет необходимости? - person Mardoxx; 19.05.2017

Обратный прокси-сервер, включенный в сервисную структуру, представляет собой приложение, работающее внутри ваших серверов, и не защищает ваши приложения от DDos-атак, ограничения скорости (злоупотребления), IP-фильтрации и многих других сценариев атак, которые WAF способен поддерживать, не позволяя злоумышленнику ваших серверов — лучший вариант, на более высоком уровне это будет стоить вам меньше, чем обработка этого внутри ваших приложений и серверов. - person Diego Mendes; 19.05.2017