Reverse proxy на базі iis, записки сисадміна
Даний пост з'явився в результаті демонстрації, проведеної для мене Олександром Станкевичем. Про можливість організувати Reverse Proxy-сервер на базі IIS я до цього не знав. У стандартному комплекті IIS цієї можливості немає - потрібно встановити спеціальний компонент IIS, який називається Application Request Routing.
На базі модуля «URL Rewrite» і можна побудувати Reverse Proxy-сервер. Важливо пам'ятати, що «URL Rewrite» доступний як на рівні всього сервера, так і на рівні окремих сайтів і додатків, розташованих в цих сайтах. Тому Reverse Proxy на базі IIS сервера можна дуже гнучко налаштовувати.
Для початку має сенс створити ферму серверів, які будуть одержувачами трафіку, пересилається Reverse Proxy-сервером:
Потім треба буде вказати ім'я ферми і додати імена серверів. З цікавого - в додаткових настройках серверів можна вказати які порти будуть слухати HTTP / HTTPS-трафік, а так само вага сервера:
Останнім кроком буде запропоновано створити правило, яке буде перенаправляти весь вхідний трафік на нову ферму. Має сенс з цим погодитися.
Бонусів в створенні ферми досить багато. Для ферми ми можемо включити кешування, налаштувати перевірку доступності нашого Web-сервера, балансування (доступна велика кількість умов, за якими можна виконувати балансування) і т. Д. Повний набір доступних функцій нижче:
По завершенні створення ферми можна подивитися на щойно створене правило. Воно буде знаходитися на рівні сервера IIS в «URL Rewrite» і називатися «ARR_FarmName_loadbalance». Правило пересилає всі запити, що приходять на сервер IIS і підходять під шаблон «*», на нашу нову ферму і по завершенні зупиняє виконання інших правил:
Зупинимося докладніше на правилах. Правила складаються з чотирьох компонентів:
- Match URL - фільтр URL, який вибирає тільки ті запити для обробки правилом, які підходять під шаблон, зазначений у фільтрі
- Conditions - умови, які визначають додаткову логіку роботи правила з тими запитами, які пройшли фільтр URL
- Action - дії, які виконуються з запитами, які пройшли фільтр URL і задовольняють умовам, зазначеним в Conditions
Запити, що проходять через наш Reverse Proxy-сервер, містять URL сервера, до якого звертається клієнт. У загальному випадку він виглядає наступним чином:
Match URL працює з
Для фільтрації використовуються шаблони на основі регулярних виразів або символів узагальнення (wildcards). Можна робити інвертовані правила (які обробляють всі запити, що не відповідають даним шаблоном). Так само є можливість включити / виключити ігнорування малих і великих літер в запиті.
Для використання додаткових умов фільтрації доступні змінні, зазначені вище. Можна вимагати одночасного виконання всіх умов, або будь-якої умови зі списку (Match All або Match Any). Наприклад, на зображенні нижче, ми вказали, щоб в фільтр потрапляли всі запити, в яких міститься URL з доменним ім'ям «cwapp.domain.com» і доступ здійснювався по HTTPS:
Крім стандартних змінних, список яких я вказав вище, можна використовувати будь-які змінні, що знаходяться в HTTP-запиті, який проходить через Reverese Proxy. Ім'я такої нової змінної збирається наступним чином:
- Всі знаки «-» замінюються на знаки «_»
- Всі букви замінюються на заголовні
- Спереду дописується приставка «HTTP_»
Прекрасним прикладом використання змінних може служити правило, створене на сервері переднього плану Lync, для мобільних клієнтів:
В Action вказується дію, якому піддається HTTP-запит, що задовольняє Match URL і Conditions. Доступні наступні дії:
Потім вводимо, на який сервер перенаправляти запити:
У підсумку отримуємо найпростіше правило, яке буде перенаправляти запити, які надходять до нашого сайту, на сервер переднього плану Lync (або на будь-який інший, який вкажемо).
Використовуючи нові знання, можна спробувати налаштувати більш хитре зворотне Proxy'рованіе запитів, що приходять на наш сайт IIS (і не тільки на нього).
Далі потрібно буде вказати назву для правила, а так же шаблон для запитів, що потрапляють під його дію (можна використовувати підстановку «*»):
У додаткових умовах вказуємо ім'я хоста (meet.domain.com) і використання в запиті HTTPS-протоколу:
В діях правила вказуємо перенаправляти запит на ферму серверів Lync по HTTPS. Не забуваємо включити настройку відключення виконання інших правил:
Таким чином, рішення на базі сервера IIS і додаткового компонента «Application Request Routing» цілком може замінити, в деяких випадках, більш важкі рішення на базі «Microsoft Threat Management Gateway» або апаратних балансувальник навантаження.
10 Responses to "Reverse Proxy на базі IIS"
502 - Web server received an invalid response while acting as a gateway or proxy server
Усередині мережі - три web сервера:
Чи можна вирішити цю задачу за допомогою Reverse Proxy-сервер.
Встановив ARR налаштував все б добре, але тільки мобільний клієнт Lync через кожні приблизно 5-10 хвилин говорить що конфігурація сервера змінилася перезавантажте клієнта. Є припущення що проблема в AplicationPool - там повинен бути якийсь параметр при якому перевантажується пул і лінк думає що змінилася конфігурація. Хто що може підказати.
"Важливо пам'ятати, що« URL Rewrite »доступний як на рівні всього сервера, так і на рівні окремих сайтів і додатків, розташованих в цих сайтах."
Тобто виходить можна на наявному сервері з IIS, на якому є вже сайт типу a1.domain.com (default site), за допомогою ARR додати перенаправлення запитів ще й на інші web сервери, що знаходяться в локальній мережі організації і працюють під іншими зовнішніми доменними іменами b1. domain.com, c1.domain.com?