Проблема с IP-адресом клиента по протоколу https с помощью Rackspace Cloud Load Balancers

ProgramBox

Проблема с IP-адресом клиента по протоколу https с помощью Rackspace Cloud Load Balancers

Post author:admin
Запись опубликована:12 апреля, 2023
Post category:Вопросы по программированию

#https #ip-address #load-balancing #reverse-proxy #rackspace-cloud

#https #ip-адрес #балансировка нагрузки #обратный прокси #rackspace-облако

Вопрос:

В настоящее время мы используем Lighttpd с FastCGI для обслуживания PHP наших клиентов. Недавно мы добавили балансировку нагрузки через RackSpace Cloud, чтобы помочь нам обрабатывать наш трафик, однако IP-адрес клиента теперь является IP-адресом балансировщика нагрузки. Весь трафик проходит через HTTPS.

Мы включили mod_extforward и перепробовали все различные конфигурации для использования нашего LB IP и разных заголовков («X-Forwarded-For», «Forwarded-For», «X-Cluster-Client-Ip»), и, похоже, у нас не получается заставить это работать!

Есть идеи? Спасибо!

1. Итак, ваш вопрос заключается в том, «В каком заголовке RackSpace Cloud отправляет IP-адрес клиента?» Должно быть «X-Forwarded-For», но почему бы просто не сбросить заголовки и не посмотреть самим.

2. Я не совсем уверен, как это сделать. Есть какая-нибудь помощь?

3. Вы уже пытались просмотреть выходные данные phpinfo() для вашего IP-адреса? В PHP 5.4 вы могли бы использовать getallheaders() , для более ранних версий самый простой способ, вероятно, использовать tcpdump -s 2000 -w dump , а затем выбросить этот дамп в Wireshark.

4. Спасибо за помощь. Мы завершили развертывание нашей собственной балансировки нагрузки вместо использования RackSpace и решили проблему. Как бы то ни было, их служба поддержки закрыла наш запрос и не стала нам помогать. 🙁

5. вы пробовали настраивать true-client-ip?

Ответ №1:

Если вы используете облачные балансировщики нагрузки Rackspace, вы не сможете получить IP-адрес клиента по протоколу SSL.

Для обычного HTTP балансировщики могут выполнять интеллектуальные действия (страница «служба недоступна», перенаправление X и т.д.) Однако балансировщики нагрузки не могут делать ничего, кроме передачи байтов между клиентом и сервером по протоколу HTTPS, потому что без закрытого ключа нет способа изменить поток (кроме как сделать его недействительным).)

Кто-то задавал этот вопрос на форумах Rackspace некоторое время назад.

Ответ №2:

Согласно Rackspace, завершение SSL не должно использоваться, если ваше веб-приложение передает личную идентифицируемую информацию (PII)

http://www.rackspace.com/knowledge_center/product-faq/cloud-load-balancers

Мне приходится прибегать к настройке IP-адреса клиента в файле cookie. Файл cookie установлен в javascript. IP-адрес клиента получается путем вызова jsonp на сервер (не за балансировщиком нагрузки), который предоставляет общедоступный IP-адрес клиента. Это все, что я могу придумать о том, где я все еще могу использовать Rackspace Cloud Load Balancer.

1. Это не юридическое заявление об отказе от ответственности, а совет. Если незашифрованный трафик проходит только через внутреннюю сеть Rackspace, это довольно безопасно. Согласно Rackspace; «»»Аарон М (26/01/2017, 14:20:29): Вам не придется беспокоиться о трафике, интерфейсы настроены так, чтобы не разрешать прослушивание / захват пакетов с уровня гипервизора, поэтому захват с другого сервера был бы невозможен «»»

Ответ №3:

Rackspace добавила SSL-завершение, так что вы можете заставить балансировщик нагрузки расшифровывать трафик и передавать незашифрованный трафик на свои серверные узлы. Смотрите это для получения дополнительной информации. Конечно, это означает, что вы отправляете трафик по тому, что фактически является общедоступной ссылкой от балансировщика нагрузки на ваши веб-серверы. И он доступен только через их API, а не через веб-консоль, что отстойно.

Ответ №4:

На самом деле вы можете увидеть здесь:

http://www.rackspace.com/knowledge_center/article/why-does-every-visitor-to-my-cloud-sites-website-have-the-same-ip-address

Правильная переменная PHP для SSL — это:

 $_SERVER['HTTP_X_FORWARDED_FOR']

Ответ №5:

Я устанавливаю mod_rpaf для серверов в системах балансировки нагрузки и Rackspace. Тогда любой PHP-код работает так же, как и раньше, с REMOTE_ADDR

1. Ссылка? Пример конфигурации? Почему / как это решает проблему?

2. mod_rpaf может быть легко настроен в Apache 2.2 для перезаписи REMOTE_ADDR на основе значения X-Forwarded-For или другого HTTP-заголовка. Это приведет к тому, что как стандартные журналы, так и интерпретаторы, такие как PHP, получат исправленный REMOTE_ADDR с IP-адресом клиента, а не с IP-адресом балансировщика нагрузки. В Apache 2.4 стандартный mod_remoteip модуль выполняет аналогичную работу.

Ответ №6:

Один из способов, который я нашел для решения этой проблемы, — использовать CloudFlare. Помимо всех дополнительных функций и преимуществ, которые он предоставляет, он фактически сам является прокси-сервером и будет включать свой собственный заголовок x-forwarded-for.

Это позволяет обойти проблему, поскольку заголовок x-forwarded-for уже присутствует до того, как он попадет в rackspace load balancer, поэтому ему не нужно ничего добавлять. IP-адрес клиента уже будет указан в заголовке.

Пожалуйста, обратите внимание: этот метод не является полностью надежным, даже со списком доверенных прокси. Можно подделать ваш IP-адрес, изменив файл хоста вашего компьютера и минуя cloudflare, подключившись напрямую к балансировщику нагрузки. Я бы не стал использовать этот метод для чего-либо, что требует высокой безопасности.