В настоящее время мы испытываем некоторые проблемы с настройкой сети, которую мы до сих пор не использовали, и я надеюсь получить дополнительные сведения о том, как их обойти.
В сети одного из наших клиентов используется 4 JBoss экземпляры на разных серверах, на которых установлена одна и та же версия нашего программного обеспечения. Они разделяют общая база данных и работают по мере необходимости. Программное обеспечение работает и готов к использованию. Мы не реплицируем сеансы - каждый JBoss управляет своим собственным пулом сеансов.
4 экземпляра JBoss разделены на 2 разных сегменты с 2 JBoss каждый. Каждый из этих сегментов маршрутизируется с использованием 2 разных веб-серверов Apache с использованием mod_jk для простой балансировки нагрузки. Используемый разъем AJP между JBoss и серверами Apache.
Оба веб-сервера Apache подключены к оборудованию. балансировщик нагрузки / маршрутизатор (наш клиент на данный момент не очень ясно понимает, что маршруты внутренний Запросы (интранет) к одному и внешний Запросы (Интернет) на другой веб-сервер. Итак, у нас есть один сегмент для внутренних, а другой - для внешних пользователей.
Клиенты используют SSL зашифрованный HTTP подключение через их браузеры - это веб-приложение. SSL-шифрование прекращается аппаратным балансировщиком нагрузки.. Каналом между аппаратным балансировщиком нагрузки и двумя веб-серверами является HTTP (нет SSL больше).
Эта проблема:
В конце строки JBoss не знает о какой-либо связи SSL / HTTP и поэтому отображает некоторые 302 редиректа с полным http: // адреса вместо https: //. Клиентский браузер на другом конце для этого переключается с https: //, который он изначально использует для подключения к веб-приложению, на http: // в случае перенаправления 302 из JBoss.
Наше решение:
Мы предложили два решения. Один из них - простое правило перезаписи на последнем конце - аппаратный балансировщик нагрузки - который перезаписывает весь трафик http: // на https: //. Это сработает и позволит клиенту оставаться на связи, но наш клиент отвергает его, потому что это необычно и не решает исходную проблему.
Другим решением было бы расширить шифрование SSL до веб-серверов, которые могли бы пересылать безопасный флаг, сигнализирующий о связи SSL, JBoss через AJP, а JBoss подхватит это и правильно перенаправит. Это решение отклонено из-за соображений внутренней безопасности и рекомендаций.
Что еще?
Итак, в настоящее время мы застряли, и фронты ужесточаются. Есть ли альтернативы нашим 2 решениям?
У нас была такая же проблема. Решением было установить атрибуты «scheme» и «secure» на коннекторе AJP в JBoss / Tomcat. Установите для схемы https и для защиты значение true, чтобы веб-контейнеры знали, какой протокол используется спереди. Если вы используете и http, и https, настройте второй коннектор для https и подключитесь с помощью Apache vhost и других настроек ajp. Возможно, вам также нужно установить атрибут proxyName.
Предполагая, что они должны справляться как с трафиком http, так и с https, вы можете попробовать дополнительно предложить одно из следующего: -
1) Они могут добавить определенный заголовок к запросам от балансировщика нагрузки, которые поступают по https, чтобы экземпляр jboss знал, что это изначально был запрос https.
2) Вы можете предложить, чтобы запросы https отправлялись на другой порт в apache (скажем, например, 8080 или даже 443, но в незашифрованном виде), чтобы apache знал, что они с https.
Другой вариант - использовать mod_headers в Apache для изменения заголовка ответа Location:
Header edit Location ^http:(.*)$ https:$1