Меню

настройка iis reverse proxy

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

Читайте также:  настройка freestyle dash для xbox 360

и доступны в Conditions через переменные «HTTP_HOST», «SERVER_PORT» и «QUERY_STRING». Так же в Conditions доступны переменные «SERVER_PORT_SECURE» и «HTTPS» для обработки HTTP-запросов.

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

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

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

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

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

В 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»:

Читайте также:  htc d600 сброс настроек

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

В итоге получаем простейшее правило, которое будет перенаправлять запросы, приходящие к нашему сайту, на сервер переднего плана 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».

источник

IIS как обратный прокси-сервер (reverse proxy)

Понадобилось мне как-то раз настроить на IIS 7 прозрачное проксирование запросов из интернета на другой web-сервер, расположенный во внутренней сети. По сути, нужно было настроить IIS 7 как обратный прокси-сервер (reverse proxy). Потом сделал то же самое на IIS 10.

Обратный прокси-сервер (reverse proxy) — тип прокси-сервера, который ретранслирует запросы клиентов из внешней сети на один или несколько серверов, логически расположенных во внутренней сети. При этом для клиента это выглядит так, будто запрашиваемые ресурсы находятся непосредственно на прокси-сервере.

Из коробки эта штука не заработала. Будем настраивать. Нам понадобится модуль для IIS 7 под названием URL Rewrite. У меня он установлен, но этого, как показала практика, недостаточно.

На IIS 10 всё поставилось таким же образом, только проблем было меньше.

Ссылки

ARR — Application Request Routing:

Читайте также:  airport admin utility настройка

Настраиваем reverse proxy

Итак, задача. Есть сайт http://setpizza.com, кстати, он продаётся. Сайт делегирован на наш web-сервер IIS 7. Нужно настроить обратное проксирование на другой сервер в локальной сети с IP адресом 192.168.1.11 на 81 порт. Не важно что там крутится, IIS, apache, nginx — мы не знаем. Допустим, мы решили проблемы с доступами и прорубили дырку по 81 порту на этот сервер с нашего IIS.

Открываем IIS там, где будем настраивать проксирование, создаём там пустую директорию, C:\redirect_setpizza.com. Создаём сайт redirect_setpizza.com, который привязан к этой директории. Выбираем сайт мышкой.

Находим URL Rewrite — тыкаем.

Добавляем правило — Add Rule(s).

Выбираем правило Reverse Proxy. OK.

Первая проблема. О как, хочешь пирожок? А нету! Для Reverse Proxy требуется фича для IIS под названием Application Request Routing (ARR). Тыкаем OK. Открывается сайт:

Install this extension. Качаем ARRv3_0.exe.

Начинается запуск инсталлятора Microsoft Web Platform Installer 5.1.

Читаем описание того, что мы ставим. На самом деле ARR позволяет не только делать обратное проксирование на один сервер. С помощью ARR можно настраивать фермы веб-серверов и выступать в качестве балансировщика, но в моей задаче всё проще. Install.

Нам говорят, что надо скачать файлы на 8,54 мегабайт. I Accept.

ARR состоит из нескольких модулей, в него входит External Cache 1.1, URL Rewrite 2.1, сам ARR 3.0.

Вторая проблема. URL Rewrite 2.1 не установился — установка прервалась. Говорят. что URL Rewrite уже установлен более старой версии. Требуется сначала его удалить вручную.

Тысяча чертей! Находим установленный старый URL Rewrite Module 2 и удаляем его. Он с 2011 года тут болтается.

Запускаем инсталлятор ARR заново.

Теперь URL Rewrite 2.1 устанавливается.

За ним ставится Application Request Routing 3.0.

ARR установлен. Возвращаемся к нашему IIS. Добавляем правило — Add Rule(s). Выбираем правило Reverse Proxy. OK.

На этот раз правило создаётся. Пишем. «192.168.1.11:81». Ставим галку Enable SSL Offloading — терминируем SSL на этом прокси-сервере. OK.

источник