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


9

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

Як очікувалося, під час переходу до імені / URL-адреси DNS (наприклад, www.something.com), балансир завантаження обслуговує сторінку з одного із зворотних веб-серверів Apache. URL-адреса браузера залишається www.something.com . З того, що я розумію, балансовий навантажувач у цьому випадку просто пересилає пакети між браузером та Apache, завжди залишаючись на шляху.

Однак, якщо я перейду до IP-адреси, на яку відображено DNS, тоді завантажувальний балансир повертає HTTP 302 Знайдено, із заголовком Location встановлено на DNS-адресу одного з Apaches. URL-адреса браузера змінюється на сервері DNS-сервера.

Чому балансовий навантажувач перенаправляє, коли запитується через IP, але правильно пересилає по шляху, коли запитується через ім'я DNS.

Відповіді:


10

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

По-перше, що стосується вашої проблеми, то балансир навантаження робить саме так, як і належить, і я думаю, що ваші сервери можуть бути неправильно налаштовані для відповіді на запит на їх IP-адресу. Якщо ви перевіряли це на балансуванні навантаження, ви можете встановити доменне ім'я у файлі хостів локального клієнта, позаду брандмауера з сервером та отримати доступ до нього як з доменним ім'ям, так і з внутрішнім IP-адресою. Напевно ви отримаєте той самий результат, який ви бачите зараз.

Я здогадуюсь, що у вас увімкнено віртуальний хостинг (для підтримки декількох доменів на одному сервері), а "за замовчуванням" не обслуговуються ті самі сторінки, що і ваш домен. В обох випадках ви повертаєте веб-сторінку з сервера. Якщо вам потрібна допомога з налаштуванням вашого веб-сервера, ви можете спробувати на ServerFault .

По-друге, розібратися трохи детальніше. Балансир навантаження зазвичай працює на L7 принаймні кластери HTTP та HTTPS. Це означає, що вони не просто дивляться на IP-адресу та передають її, а також не "перенаправляють" сторінку.

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

Я рекомендую вам витратити деякий час, повністю читаючи документи постачальника, щоб краще зрозуміти, як працює балансування навантажень (за допомогою Fortigate ви можете прочитати як їх, так і Coyote Point - придбану ще одну компанію Fortigate, що балансує навантаження). Розуміння того, що він робить, допоможе вам у подібних випадках і дозволить вам розблокувати можливості, які ви не усвідомлювали, що існували.


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

3

Ознайомившись з балансуванням навантаження на основі хоста HTTP у документі Документ балансування навантаження Fortigate , я можу побачити, як у вас може бути нетипова конфігурація балансування навантаження, яка може призвести до того, що ви описуєте. Однак без частини вашої конфігурації ми не можемо бути впевнені, чи так це для вас.

Fortigate FortiOS дозволяє створити віртуальний сервер, прив’язаний до реальних серверів, кожен з яких має різну конфігурацію заголовка хоста . Якщо будь-які запити відповідають VIP-коду вашого віртуального сервера, запити, збалансовані по завантаженню, перейдуть лише до реальних серверів, які відповідають цьому host header. Найважливіша частина, яка добре пояснює ваші симптоми, - це те, що один із реальних серверів може опустити заголовок хоста, щоб він відповідав будь-якому заголовку хоста.

Справжній сервер без хост-заголовка, можливо, був налаштований як свого роду "загальний доступ", який розташовується на сайті, який виконує переадресацію.

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

налаштування vip брандмауера
 редагувати "http-host-ldb"
  встановити тип сервера-навантаження-баланс
  встановити extip 192.0.2.1
  встановити extintf "lan"
  встановити http-тип сервера
  встановити http-хост ldb-методу
  встановити експорт 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)
Ricky Beam

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

@RickyBeam, лише перші, хто переходить на рингер, ідентифікують ім'я хоста. Останній резервер відповідатиме VIP-адресі як хосту.
generalnetworkerror

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