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» або апаратних балансувальник навантаження.
Підкажіть як в ARR обмежити кількість одночасних запитів, що відправляються на кожен з серверів ферми.
У нас в якості серверів використовуються спеціальні web-служби з кількістю одночасних підключень = 8. Відповідно, потрібно, щоб ARR віддавав велику чергу запитів серверів поступово.
Михайло:
Підкажіть як в ARR обмежити кількість одночасних запитів, що відправляються на кожен з серверів ферми.
У нас в якості серверів використовуються спеціальні web-служби з кількістю одночасних підключень = 8. Відповідно, потрібно, щоб ARR віддавав велику чергу запитів серверів поступово.
Failed request повертають статус 502.3.
Якщо обмежити неможливо, підкажіть як змусити ARR автоматично повторювати невиконаний запит на іншому сервері ферми?
Такого ARR робити не вміє, та й сенсу в цьому я абсолютно не бачу - це вже завдання клієнта повторити запит, якщо його відшили.
Кількість запитів на сервер обмежити теж не можна, але якщо у вас багато серверів в фермі, можете налаштувати розподіл навантаження в «Load Balance» по типу «Least current request», або зовсім серйозно заморочити з «Health Test», щоб певний сервер виключався з ферми .
«Важливо пам'ятати, що« URL Rewrite »доступний як на рівні всього сервера, так і на рівні окремих сайтів і додатків, розташованих в цих сайтах.»
Тобто виходить можна на наявному сервері з IIS, на якому є вже сайт типу a1.domain.com (default site), за допомогою ARR додати перенаправлення запитів ще й на інші web сервери, що знаходяться в локальній мережі організації і працюють під іншими зовнішніми доменними іменами b1. domain.com, c1.domain.com?
Якщо я правильно зрозумів, що саме ви мали на увазі, то все вірно - можна. Правда, я б назвав це Proxy'рованіем, а не перенаправленням. Перенаправлення - це коли клієнт сам безпосередньо звертається по новому імені і для реалізації цього сценарію у IIS'а є штатний модуль. З іншого боку, навіть для цілей перенаправлення, ARR набагато більш гнучкий і функціональний.