Главная > Reverse Proxy > Reverse Proxy на базе IIS (перепост)

Reverse Proxy на базе IIS (перепост)

(Перепост статьи «Reverse Proxy на базе IIS», обещанный Александром Станкевичем и любезно предоставленный Станиславом Булдаковым. Оригинал статьи — http://www.buldakov.ru/?p=1912)

Данный пост появился в результате демонстрации, проведённой для меня Александром Станкевичем. О возможности организовать 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».

Станислав Булдаков

Реклама
Рубрики:Reverse Proxy
  1. Сергей
    28.03.2012 в 19:55

    Как можно вебсерверу за проксёй получить ip-адрес клиента?

    • Stanky
      18.04.2012 в 15:29

      По умолчанию, адрес клиента сохраняется в заголовке с именем «X-Forwarded-For». Если же вы хотите это на уровне IP сделать, то IIS, в отличии от TMG, этого не умеет 😉 .

  2. Roman
    23.05.2012 в 16:57

    А не подскажете возможно ли реверс прокси на базе IIS поднять на Edge, если веб-сайт для него повесить на отдельный ip? У меня не получилось. То сайт не стартует, то службы edge из-за конфликта портов, хотя везде проверял и в топологии тоже адреса разные для edge и для web componetns.

    • Stanky
      24.05.2012 в 12:43

      Можно. И в моей тестовой среде я именно так и сделал. Причём, скажу вам, по секрету, сайт работает на том же IP-адресе, что и сам Edge 😉 .
      У вас, просто, проблема возникает из-за того, что IIS забирает под себя 443-й порт на всех сетевых интерфейсах, независимо от того, что вы для самих сайтов назначаете. Поэтому, вам нужно, либо ограничить его аппетиты, либо изменить порты самого Edge’а.
      Чтоб ограничить аппетиты, нужно выполнить команду «netsh http add iplisten ipaddress=Ваш IP-адрес», результат которой сохраняется в параметре «ListenOnlyList» ветки «HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\HTTP\Parameters».
      Для изменения порта Edge’а на внутреннем интерфейсе нужно выполнить команду «Set-CsEdgeServer -Identity Edge.domain.ru -MediaRelayInternalTurnTcpPort 442». Порт, понятное дело, не обязательно должен быть 442. Порты на внешнем интерфейсе меняются в топологии.
      Лично я предпочитаю второй вариант 🙂 .

      • 21.12.2015 в 00:11

        В случае совмещения Lync\Skype Edge и Reverse Proxy на базе IIS ARR порт MediaRelayInternalTurnTcpPort для Edge нужно менять в любом случае, ибо IP на Internal интерфейсе сервера у IIS-а «отнимать» нельзя (т.е. в случае ограничения IIS-а IP-адресами нельзя исключать из списка IP-адрес внутреннего сетевого интерфейса), т.к. в результате сломается механизм репликации конфигурации Edge.
        Выражаться это будет в недоступности веб-сервиса https://skype-edge.domain.local:4443/ReplicationWebService , который реализуется механизмами W3SVC.

  3. Михаил
    17.10.2012 в 16:34

    Подскажите как в ARR ограничить количество одновременных запросов, отправляемых на каждый из серверов фермы.
    У нас в качестве серверов используются специальные web-службы с количеством одновременных подключений = 8. Соответсвенно, требуется, чтоб ARR отдавал большую очередь запросов серверам постепенно.

  4. Михаил
    17.10.2012 в 16:47

    Михаил :
    Подскажите как в ARR ограничить количество одновременных запросов, отправляемых на каждый из серверов фермы.
    У нас в качестве серверов используются специальные web-службы с количеством одновременных подключений = 8. Соответсвенно, требуется, чтоб ARR отдавал большую очередь запросов серверам постепенно.

    Failed request возвращают статус 502.3.

    Если ограничить невозможно, подскажите как заставить ARR автоматически повторять невыполненный запрос на другом сервере фермы?

    • 19.09.2013 в 19:55

      Такого ARR делать не умеет, да и смысла в этом я совершенно не вижу — это уже задача клиента повторить запрос, если его отшили.

      Количество запросов на сервер ограничить тоже нельзя, но если у вас много серверов в ферме, можете настроить распределение нагрузки в «Load Balance» по типу «Least current request», либо вовсе серьёзно заморочиться с «Health Test», чтоб определённый сервер исключался из фермы.

  5. 19.09.2013 в 09:58

    Подскажите пожалуйста, адрес FQDN сервера для фермы нужно вводить внутренний или внешний?

    • 19.09.2013 в 19:32

      Кратко — внутренний.

      • 20.09.2013 в 11:03

        Спасибо, все заработало! Остался один не до конца понятный момент:) Для сервера реверс-прокси достаточно одного сертификата для имени extweb.sip domain? При этом можно будет опубликовать аналогичным образом meet.sip domain и dialin.sip domain?

      • 22.09.2013 в 18:57

        Сколько имён хотите опубликовать, столько имён и должно быть в сертификате — IIS’у, в этом плане, всё равно, а вот клиент будет выдавать ошибку 😉 .

  6. 09.10.2013 в 13:04

    Помогите пожалуйста. После некоторого времени выяснился один непонятный нюанс: на клиентах Lync Mobility 2013 адресная книга работает, а на клиентах Lync Mobility 2010. Front End — Lync 2013. Reverse Proxy сделан на ISS, по вашему руководству. Сертификат на Reverse Proxy установлен публичный WildCard вида *.domain.ru

  7. 09.10.2013 в 13:07

    На клиентах Lync Mobility 2010 адресная книга не работает, а на клиентах Lync Mobility 2013 работает.

  8. 11.10.2013 в 10:09

    У кого есть похожая проблема, то помогла статья по настройке ARR на IIS http://technet.microsoft.com/en-us/library/gg429712.aspx

    • 15.10.2013 в 02:26

      А чем именно вам помогла данная статья? Я не увидел там чего-то особенного о чём мы бы не говорили.

      • 15.10.2013 в 11:40

        Помогли пункты: 1) Click the name of the server farm that you have just created. Under Server Farm in IIS Manager Features View, you double-click Caching. Deselect Enable disk cache. Click Apply on the right-hand side.
        2) Click the name of the server farm. Under Server Farm in IIS Manager Features View, you double-click Routing Rules. On the Routing Rules dialog under Routing, clear the checkbox next to Enable SSL offloading. If the ability to clear the checkbox is not available, select the checkbox for Use URL Rewrite to inspect incoming requests. Click Apply to save your changes. Там написан нотис: SSL Offloading by the reverse proxy is not supported.
        3) Click the name of the server farm. Under Server Farm in IIS Manager Features View, you double-click Proxy. On the Proxy settings page change the value for Time-out (seconds) to 200. Click Apply to save the change. После установки данного тайм-аута, сессии мобильных клиентов перестали разрываться, видеосеансы тоже длились без разрыва. Вроде больше не появляются сообщения на мобильных клиентах Lync 2013 — «Your server configuration has changed. Please restart Lync».

        Также, на мобильных клиентах Lync 2010 пропали сообщения об ошиках подключения к серверу Exchange.

      • 15.10.2013 в 17:27

        Как я понимаю, в вашем случае помог именно Time-out?
        Видимо, об этом в докладе явно не говорилось, но я проверил свою настройку и у меня там стоит аж 7200 в соответствии с рекомендацией TCP idle-timeout value greater than or equal to the minimum REGISTER refresh or SIP Keep-Alive interval (typically 30 minutes).

      • 16.10.2013 в 10:18

        При просмотре логов IIS, можно было увидеть, что запросы MCX не работали, а клиенты UCWA успешно получали списки адресов. На мобильных клиентах Lync 2013 адресная книга работала всегда и без этих настроек. Подозреваю, что работала она потому, что они работают по своей технологии UCWA, а не MCX, как Lync 2010 Mobility. В вашем видео описан порядок настройки IIS как reverse proxy для «бедных», именно поэтому там показано, что на запрос lyncdiscover должно выполниться action — route to server farm в http. Но в нашем случае, мы имеем нормальные публичные сертифкаты, и такой вариант нас не устраивает. Я исправил action — route to server farm в https. После выполнения пунктов 1) и 2) , как указано в моем предыдущем посте, адресная книга заработала и на клиентах Lync 2010 Mobility. На ISS в URL Rewrite появилось новое правило ARR_lync_loadbalance_SSL в котором было одно единственное conditions HTTPS — ON. После проделанных действий исчесли провблемы с адресной книгой на всех мобильных клиентах, а на мобильных клиентах Lync 2010 больше не появлялось периодическое сообщение об ошибках подключения к серверу Exchange.
        Теперь на счет таймаута. С самого начала, после развертывания системы Lync, мы заметили, что мобильные клиенты постоянно и часто переподключаются, а на мобильных клиентах Lync 2013 периодически появляется сообщение “Your server configuration has changed. Please restart Lync”. При тестовых видеозвонках на Lync Mobility 2013 сенас разрывался примерно после 30 секунд. Это то самое время, которое установленое по-умолчанию в настройках Proxy в ISS Manager. Установка таймаута, как у казано в статье http://technet.microsoft.com/en-us/library/gg429712.aspx
        в 200, исправило эти проблемы. P.S. без вашего видео, наверное еще долго бы мучались, так как на Майкрософт очень много непонятных моментов. Спасибо большое за материал:)

      • 16.10.2013 в 19:03

        Понятно — надо будет как-нибудь ещё раз поиграться…

        P. S. Пожалуйста и вам тоже спасибо 🙂 .

  9. RS
    06.08.2015 в 18:04

    Здравствуйте!

    «Важно помнить, что «URL Rewrite» доступен как на уровне всего сервера, так и на уровне отдельных сайтов и приложений, расположенных в этих сайтах.»

    Т.е. получается можно на имеющемся сервере с IIS, на котором есть уже сайт типа a1.domain.com (default site), посредством ARR добавить перенаправление запросов еще и на другие web серверы, находящиеся в локальной сети организации и работающими под другими внешними доменными именами b1.domain.com, c1.domain.com?

    • 06.08.2015 в 18:33

      Если я правильно понял, что именно вы имели в виду, то всё верно — можно. Правда, я бы назвал это Proxy’рованием, а не перенаправлением. Перенаправление — это когда клиент сам напрямую обращается по новому имени и для реализации этого сценария у IIS’а есть штатный модуль. С другой стороны, даже для целей перенаправления, ARR гораздо более гибок и функционален.

  1. No trackbacks yet.

Добавить комментарий

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

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s

%d такие блоггеры, как: