Адрес выдачи IP-адреса клиента через https с балансировщиками нагрузки Rackspace Cloud

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

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

Любые идеи? Спасибо!


https load-balancing reverse-proxy ip-address rackspace-cloud
person Kaiser    schedule 09.11.2011    source источник
comment
Итак, ваш вопрос: в каком заголовке RackSpace Cloud отправляет IP-адрес клиента? Должно быть X-Forwarded-For, но почему бы просто не сбросить заголовки и не поискать самому.   -  person AndreKR    schedule 09.11.2011
comment
Я не совсем уверен, как это сделать. Любая помощь там?   -  person Kaiser    schedule 09.11.2011
comment
Вы уже пробовали смотреть на вывод phpinfo() для вашего IP-адреса? В PHP 5.4 вы можете использовать getallheaders(), для более ранних версий проще всего использовать tcpdump -s 2000 -w dump, а затем закинуть этот дамп в Wireshark.   -  person AndreKR    schedule 09.11.2011
comment
Спасибо за помощь. Мы прекратили развертывание собственной балансировки нагрузки вместо использования RackSpace, и проблема была решена. Что бы это ни стоило, их поддержка закрыла наш билет и не помогла бы нам. :(   -  person Kaiser    schedule 10.11.2011
comment
Вы пытались настроить true-client-ip?   -  person Ben Sewards    schedule 20.01.2014

Ответы (6)


arrow_upward
8
arrow_downward

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

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

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

person jon    schedule 29.02.2012
comment
Ссылка на этот вопрос не работает, к сожалению - person Arth; 02.11.2020

arrow_upward
1
arrow_downward

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

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

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

person Bombastar    schedule 01.05.2014
comment
Это не юридическая оговорка, а совет. Если незашифрованный трафик проходит только через внутреннюю сеть Rackspace, это довольно безопасно. По данным Rackspace; Aaron M (26.01.2017, 14:20:29): Вам не придется беспокоиться о трафике, интерфейсы настроены так, чтобы не допускать перехвата/перехвата пакетов с уровня гипервизора, поэтому перехват невозможен с другого сервера - person MagicLAMP; 26.01.2017

arrow_upward
0
arrow_downward

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

person Mike P    schedule 26.08.2012

arrow_upward
0
arrow_downward

Собственно здесь можно увидеть:

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']
person mrc0der    schedule 11.11.2012

arrow_upward
0
arrow_downward

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

person Dave Steer    schedule 15.10.2014
comment
Ссылка на сайт? Пример конфига? Почему/как это решает проблему? - person Synchro; 15.10.2014
comment
mod_rpaf можно легко настроить в Apache 2.2 для перезаписи REMOTE_ADDR на основе значения X-Forwarded-For или другого заголовка HTTP. Это приведет к тому, что как стандартные журналы, так и интерпретаторы, такие как PHP, получат исправленный REMOTE_ADDR с IP-адресом клиента, а не с IP-адресом балансировщика нагрузки. В Apache 2.4 стандартный модуль mod_remoteip выполняет аналогичную работу. - person gid; 18.02.2015

arrow_upward
0
arrow_downward

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

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

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

person jakraska    schedule 17.12.2014