Разница в балансировке нагрузки между DNS и IP - перенаправление против перенаправления


9

Я столкнулся с ситуацией, которую не могу понять. У нас есть межсетевой экран Fortigate, который мы позволили выполнить балансировку нагрузки на двух внутренних веб-серверах Apache. DNS-имя затем сопоставляется с виртуальным IP-адресом на балансировщике нагрузки.

Как и ожидалось, когда вы переходите на DNS- имя / URL (например, www.something.com), балансировщик нагрузки отображает страницу с одного из внутренних веб-серверов Apache. URL в браузере остается www.something.com . Насколько я понимаю, балансировщик нагрузки в этом случае просто пересылает пакеты между браузером и Apache, всегда оставаясь в пути.

Однако, если я перехожу к IP-адресу , на который сопоставлен DNS, то балансировщик нагрузки возвращает HTTP 302 Found с заголовком Location, установленным на URL-адрес DNS одного из Apache. URL-адрес в браузере изменится на внутренний сервер DNS.

Почему балансировщик нагрузки перенаправляется при запросе по IP, но правильно перенаправляет в пути при запросе по DNS-имени.

Ответы:


10

Я не использовал Fortigate FW для балансировки нагрузки, поэтому я отвечу на некоторые вопросы более широко.

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

Я предполагаю, что у вас включен виртуальный хостинг (для поддержки нескольких доменов на одном сервере) и «default» не обслуживает те же страницы, что и ваш домен. Вы получаете веб-страницу обратно с сервера в обоих случаях. Если вам нужна помощь в настройке вашего веб-сервера, вы можете попробовать ServerFault .

Во-вторых, немного подробнее. Балансировщик нагрузки обычно работает на уровне L7 как минимум для кластеров HTTP и HTTPS. Это означает, что они не просто смотрят на IP-адрес и пересылают его, а также не «перенаправляют» страницу.

Когда они получают запрос, они фактически анализируют запрос и направляют его на сервер после обработки запроса. В этот момент они могут многое сделать, например, переписать заголовки в обоих направлениях, потенциально добавить файлы cookie (для сохранения) в данные, возвращаемые клиенту, завершить сеансы SSL, сопоставить на основе URL-адреса и т. Д.

Я рекомендую вам потратить некоторое время на полное чтение документов поставщика, чтобы лучше понять, как работает балансировка нагрузки (с Fortigate вы можете прочитать и их, и Coyote Point - еще одна компания по балансировке нагрузки, приобретенная Fortigate). Понимание того, что он делает, поможет вам в подобных случаях и позволит вам раскрыть возможности, о которых вы даже не подозревали.


Проблема заключалась в конфигурации на внутреннем веб-сервере Apache. Новое DNS-имя необходимо добавить как псевдоним.
Юсуф

3

Прочитав HTTP-балансировку нагрузки на хосте в документе Fortigate Load Balancing , я могу увидеть, как у вас может быть нетипичная конфигурация балансировки нагрузки, которая может привести к тому, что вы описываете. Однако, без части вашей конфигурации, мы не можем быть уверены, что это так для вас.

Fortigate FortiOS позволяет создавать виртуальный сервер, связанный с реальными серверами, каждый из которых имеет свою конфигурацию заголовка узла . Если какие-либо запросы соответствуют VIP вашего Виртуального сервера, запросы с балансировкой нагрузки будут отправляться только тем реальным серверам, которые соответствуют этому host header. Самая важная часть, которая хорошо объясняет ваши симптомы, состоит в том, что один из реальных серверов может опустить заголовок узла, чтобы он совпадал с любым заголовком узла.

Реальный сервер без заголовка узла мог быть настроен как своего рода «ловушка», которая попадает на сайт, который выполняет перенаправление.

Используя приведенный ниже пример, только 1-й и 2-й серверы обрабатывают трафик, соответствующий предпочитаемому DNS-имени, через заголовок узла, но 3-й сервер берет все, что соответствует всем другим заголовкам хоста, включая сам DNS DNS, и отправляет на сайт, который может выполнить перенаправление ,

Конфигурация брандмауэра VIP
 редактировать "http-host-ldb"
  установить тип server-load-balance
  set extip 192.0.2.1
  установить extintf "LAN"
  установить http-тип сервера
  установить ldb-метод http-host
  установить extport 80
  конфиг реальные серверы
    редактировать 1
      установить http-хост "www.example.com"
      установить IP 192.168.2.1
      установить порт 80
      следующий
    редактировать 2
      установить http-хост "www.example.com"
      установить IP 192.168.2.2
      установить порт 80
      следующий
    редактировать 3
      установить IP 192.168.2.3
      установить порт 80
      следующий
    конец
 конец

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


В этой конфигурации он устанавливается на соответствие имени. И это проблема. Если вы идете к VIP по адресу, он не будет знать, что с ним делать. (тогда будут применяться нормальные правила NAT)
Рикки Бим

Основная причина, по которой я не верил, что это ответ, заключается в том, что никакой FW / балансировщик нагрузки, о котором я знаю, не вернет 302 с расположением, заданным как имя хоста / домен внутреннего ресурса (по крайней мере, без специальной настройки для этого. так, что не похоже на случай, основанный на вопросе).
YLearn

@RickyBeam, только первые серверы выполняют сопоставление имен хостов. Последний rserver будет соответствовать VIP-адресу в качестве хоста.
generalnetworkerror

@YLearn, я согласен, что это было бы странно; Я говорил, что сервер, а не LB, выполнил бы 302 и был бы настроен на это. Я не знаю ни одного LB, который бы сделал это.
generalnetworkerror
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.