Reverse Proxy на базе IIS

Данный пост появился в результате демонстрации, проведённой для меня Александром Станкевичем. О возможности организовать Reverse Proxy-сервер на базе IIS я до этого не знал. В стандартном комплекте IIS этой возможности нет — нужно установить специальный компонент IIS, который называется Application Request Routing.

После установки ARR в окне просмотра функций нашего IIS сервера (в оснастке Internet Information Services Manager) появится «URL Rewrite», а в дереве сайтов — пункт «Server Farms»:

На базе модуля «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 сервера, к которому обращается клиент. В общем случае он выглядит следующим образом:

http(s)://<host>:<port>/<path>?<querystring>

Match URL работает с <path> из части запроса URL. Части <host>, <port> и <querystring> доступны в Conditions через переменные «HTTP_HOST», «SERVER_PORT» и «QUERY_STRING». Так же в Conditions доступны переменные «SERVER_PORT_SECURE» и «HTTPS» для обработки HTTP-запросов.

Подробнее о компонентах.

Match URL

Для фильтрации используются шаблоны на основе регулярных выражений или подстановочных знаков (wildcards). Можно делать инвертированные правила (которые обрабатывают все запросы, не удовлетворяющие данному шаблону). Так же есть возможность включить/выключить игнорирование строчных и прописных букв в запросе.

Conditions

Для использования дополнительных условий фильтрации доступны переменные, указанные выше. Можно требовать одновременного выполнения всех условий, либо любого условия из списка (Match All или Match Any). Например, на картинке ниже, мы указали, чтобы в фильтр попадали все запросы, в которых содержится URL с доменным именем «cwapp.domain.com» и доступ осуществлялся по HTTPS:

Помимо стандартных переменных, список которых я указал выше, можно использовать любые переменные, находящиеся в HTTP-запросе, который проходит через Reverese Proxy. Имя такой новой переменной собирается следующим образом:

• Все знаки «–» заменяются на знаки «_»
• Все буквы заменяются на заглавные
• Спереди дописывается приставка «HTTP_»

Прекрасным примером использования переменных может служить правило, созданное на сервере переднего плана Lync,  для мобильных клиентов:

Action

В Action указывается действие, которому подвергается HTTP-запрос, удовлетворяющий Match URL и Conditions. Доступны следующие действия:

• Rewrite – Заменяется URL входящего запроса на тот, который мы укажем. Следует помнить, что в случае использования абсолютного URL-пути запрос будет выполняться по всем правилам, то есть за пределами сервера, реализуя тем самым полноценный Reverse Proxy.
• Redirect – Клиент получает ответ о перенаправлении HTTP-запроса на URL, который мы укажем, клиенту при этом возвращается статус 301, 302, 303 или 307. Указываемый в URL путь может быть абсолютным (http://cwapp.domain.com/default.aspx) или относительным (test/index.htm)
• Route to Server Farm – Доступен только при наличии фермы и только на глобальном уровне (на уровне сайта или приложения не доступен). Запрос перенаправляется на ферму.
• CustomResponse – Клиенту возвращается указанный статус и причина возвращения запроса.
• AbortRequest – Отбрасывается клиентский запрос.
• None – Никаких действий не производится.

Возвращаемся к Reverse Proxy. Предположим, нам необходимо перенаправлять запросы, идущие к «http://cwapp.domain.com», на сервер переднего плана Lync. Для этого укажем по какому IP-адресу будет отвечать наш сайт, отвечающий за Reverse Proxy. В DNS необходимо будет прописать хост «cwapp.domain.com» с IP-адресом, который мы закрепили за Web-сайтом. Затем, на уровне сайта заходим в URL Rewrite и добавляем правило (Add Rule(s)…), указываем тип правила — «Reverse Proxy»:

Затем вводим, на какой сервер перенаправлять запросы:

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

Используя новые знания, можно попробовать настроить более хитрое обратное Proxy’рование запросов, приходящих на наш сайт IIS (и не только на него).

Попробуем настроить перенаправление клиентских запросов к «https://meet.domain.com». Для этого на уровне сервера IIS заходим в «URL Rewrite» и создаём новое правило:

Далее нужно будет указать название для правила, а так же шаблон для запросов, попадающих под его действие (можно использовать подстановку «*»):

В дополнительных условиях указываем имя хоста (meet.domain.com) и использование в запросе HTTPS-протокола:

В действиях правила указываем перенаправлять запрос на ферму серверов Lync по HTTPS. Не забываем включить настройку отключения выполнения других правил:

Таким образом, решение на базе сервера IIS и дополнительного компонента «Application Request Routing» вполне может заменить, в некоторых случаях, более тяжёлые решения на базе «Microsoft Threat Management Gateway» или аппаратных балансировщиков нагрузки.

Особая благодарность выражается Александру Станкевичу за помощь в написании данной статьи. Если вас заинтересовала данная тема, можете посмотреть его видео-демонстрацию по установке и настройке «Application Request Routing» в контексте использования для «Lync Mobility».