Меню

Iis как настроить переадресацию

IIS как пограничный веб-сервер (теперь haproxy)

В этой статье я хочу описать не самый типичный сценарий, который, тем не менее, имеет право на жизнь.
Дело в том, что мы используем IIS как прокси для других веб-серверов компании. Я расскажу, как это реализовано и с какими трудностями пришлось столкнуться​.

Постановка задачи
Разберём на примере сервера YouTrack. Он представлен неприглядным srv-youtrack-01.local.domain и находится на веб-сервере внутри компании. Задача заключается в том, чтобы обеспечить доступ к нему из интернета по красивому имени yt.company.ru. При этом обязательно должен использоваться https.

Реализация
Для начала работы нам понадобится установить компонент URL Rewrite. Это можно сделать при помощи web platform installer, а также вручную. После его установки мы увидим в диспетчере служб IIS новый ярлык
переопределение URL-адресов».

При помощи этого инструмента можно создать правило переопределения адресов «обратный прокси-сервер».

При создании правила нужно указать URL сервера (без префикса http:// — его IIS добавит автоматически), на который будет происходить проксирование. В итоге мы получим правило, доступное для редактирования. Оно применяется не ко всем запросам, а только к тем, которые подходят под критерии, которые мы можем настраивать. Для начала проверяется URL на соответствие шаблону, после чего в ход идут проверки по другим критериям.

Сразу оговорюсь, что тут есть два пути: первый путь — создать набор правил с разными шаблонами URL-адресов для разных ресурсов на одном IIS-сайте; а второй — создать по сайту для каждого проксируемого ресурса и в каждом из них сделать по одному правилу. Понимая, что первый путь более джедайский, я все-таки избрал путь второй — пусть не такой красивый, зато я не рискую написав неправильное регулярное выражение для одного сайта сломать всю маршрутизацию. Поэтому шаблон URL-адреса у меня везде дефолтный «(.*)».

Итак, я создаю сайт yt.company.ru с биндингами на 80 и 443 порт и обязательным указанием имени узла, чтобы IIS знал, к какому сайту я обращаюсь. Про получение и установку сертификата для 443 позволю себе не упоминать. Обращу лишь внимание, что сам сервис настраивать на использование https не нужно — внутри сети шифроваться не от кого, а внешние запросы будут соединяться по ssl с пограничным сервером, который будет уже по незащищенному каналу проксировать запросы внутри сети.

Покуда обязательным требованием является использование https, будем проксировать только те запросы, которые приходят на 443 порт, для чего создадим простое условие. При его создании предлагается выпадающий список возможных вариантов.


Отлично, теперь все запросы yt.company.ru проксируются на внутренний сервер с неприглядным именем srv-youtrack-01.local.domain прозрачно для пользователя.

Однако, все запросы yt.company.ru отсекаются с ошибкой 403, что не очень красиво. Для решения этой проблемы можно либо создать index.html с редиректом, либо еще одно правило URL Rewrite, у которого в поле «действие» выберем постоянное перенаправление на нужный нам URL.

Следует обратить внимание, что правила для сайта применяются по порядку, поэтому сначала нужно расположить правило с условием, а потом правило без условий. При этом, так как второе правило применяется ко всем URL без исключения, для первого правила необходимо поставить (оставить поставленной) галочку «Остановить обработку последующих правил».

После манипуляций с графическим интерфейсом в корне нашего сайта создается web.config, который содержит все созданные правила. Поэтому если требуется проксировать еще какой-то сайт, то эти манипуляции повторять не нужно, можно просто скопировать web.config и изменить в нем требуемый URL или после копирования воспользоваться графическим интерфейсом для изменения правил. Более того, можно вообще не пользоваться интерфейсом, а писать сразу туда — кому как нравится.

Подводные камни
При переходе на вкладку «Agile boards» YouTrack генерит URL-адрес вида yt.company.ru/rest/agile/Overview-0/sprint/Iteration+24. Далее, при переключении между спринтами yt.company.ru/rest/agile/Overview-0/sprint/Iteration%252023?q=. При переходе на эти урлы IIS стал возвращать мне 404 ошибку. Это свидетельствовало о том, что запросы не проксируются. При этом переходы между сохраненными запросами вида yt.company.ru/issues/IT?q=%23+Assigned+to%3A+me+updated%3A+ вполне корректно отрабатывали.

Читайте также:  Как мультитроникс настроить часы

Эксперименты с добавлением знака вопроса в середину проблемного URL закончились тем, что я стал получать 404 ошибку уже от YouTrack-сервера, а не IIS. Это натолкнуло меня на мысль, что IIS по каким-то своим соображениям (привет, Microsoft) интерпретирует URL и это надо исправить.

Проблема со знаком «плюс» в середине адреса решилась добавлением параметра requestFiltering allowDoubleEscaping=«true»:

Но после этого все еще не работало переключение между спринтами. Выяснилось, что IIS считает такие запросы небезопасными. Эту проверку тоже пришлось отключить:

Вот какой web.config получился после всех манипуляций:

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

Таким образом у нас в организации проксируются абсолютно все веб-серверы, которым нужен доступ извне, среди которых есть и nginx, и apache, и svn, и gitlab, и exchange web access.

Основная проблема, которая заставляет меня находиться в поиске решения заключается в том, что через прокси не работает NTLM-авторизация, так нужная для многих сервисов компании Microsoft. Мёртвый продукт TMG использовать не хочется, поэтому сейчас пытаюсь разобраться с новой службой Windows Server 2012 R2 под названием Web Application Proxy параллельно поглядывая на nginx и apache, которые, кажется, тоже пока не умеют проксировать NTLM.

Ссылки

Большой update:
В комментариях мне посоветовали попробовать haproxy. Зайдя на сайт я сделал поиск по странице «ntlm» и нашел «full HTTP keep-alive for better support of NTLM and improved efficiency in static farms», что придало мне уверенности.
После нескольких дней активной возни в консоли я таки осилил этот замечательный инструмент и теперь IIS в качестве прокси-сервера мне больше не нужен. Отдельную статью про это, думаю, писать не стоит, поэтому решил обновить топик.

Работает всё это дело достаточно просто и из коробки:
1. Устанавливается из backports при помощи apt-get (предпочитаю debian)
2. Пишется конфиг. Слегка правятся настройки проксируемых приложений
3. Переключается iptables на новый прокси

На втором пункте остановлюсь подробнее.
В секцию defaults конфига дописал

Последний пункт нужен для того, чтобы бакенду передавалось имя хоста, остальные — «как у всех».

Далее создаются фронтенды для 80 и 443 портов, которые будут слушать и решать, на какой бакенд посылать запрос в зависимости от некоторых условий. А условие у меня только одно — пришедшее имя хоста.

С https несколько сложнее. На помощь пришёл соседний топик, в комментариях которого рекомендовали использовать SNI. Его и использовал

Это оказалось очень просто! Первым делом генерируются сертификаты для всех бакендов — именно они и будут отдаваться клиентам. Я использую PKI от Микрософта, поэтому пришлось немного повозиться с генерацией реквестов, выдачей и передачей на прокси этих сертификатов. Допускается, кстати, использование *.company.name, но я решил что это как-то не очень солидно, тем более при таком малом количестве бакендов. После того, как сертификаты готовы, нужно написать их тупо в строчку как на примере выше, а дальше написать правила для бакендов — сертификаты будут подсовываться по порядку.
Конструкция с использованием sni настолько простая, что даже объяснять не надо. Правда, вышло так, что большинство почтовых клиентов андроида не умеют (или не хотят) sni, и шлют запросы на 443 порт без указания имени хоста. Не беда! Для таких случаев есть

(я, кстати, не проверил, какой сертификат подсовывается в этом случае)

Ну а дальше описываются бакенды. С http всё тривиально:

Здесь it.company.name — это имя хоста, которое будет передано на srv-web-01. Мне это нужно по тому, что IIS на этом сервере использует идентификацию по имени хоста.

Для https вот такие конструкции

Тут можно разгрузить SSL, указав 80 порт — тогда шифроваться будет трафик между клиентом и проксей, а внутри сети не будет. А можно и дальше использовать https (verify none означает «не придираться к сертификату»). Стоит, однако, понимать, что клиент все-таки получает тот сертификат, который мы вписали при создании фронтенда. Если нужно подсовывать именно сертификат конечного сервера, то можнжо использовать способ, описанный в топике, который я указал выше.

Читайте также:  Как настроить тв приставку ростелеком по wifi

Ещё один момент: хочется красиво редиректить http на https для некоторых серверов. Для этого я создал специальные бакенды с постфиксом _r, которые аккуратно перекидывают ничего не подозревающего пользователя на https.

Закомментированную строку не стал убирать сознательно — изначально использовался такой вариант, но он перенаправлял меня в корень сайта, что очень неудобно, если пользователь нажал на длинную ссылку http ://site.company.name/lib/doc/Русские%20буквы%20в%20названии.docx, а его перекинуло на главную страницу без всякой надежды найти свой документ. Велика вероятность, что он закроет её и попробует пройти по ссылке снова, но опять ничего не получит и очень расстроится. Чтобы такого не произошло, нам помогает конструкция redirect scheme https, которая аккуратно перенаправляет пользователя, подставляя весь URL.

Подробно обо всех тонкостях конфигурирования на странице документации cbonte.github.io/haproxy-dconv/configuration-1.5.html#4.2

Спасибо за внимание. Надеюсь, кому-то мой опыт окажется полезным.

Источник

Искусcтво администрирования

301 редирект IIS7 (Настройка перенаправления HTTP в IIS 7)

Попросил знакомый помочь ему настроить пересылку (301 redirect) со старых страниц сайта на новые, так как он поменял структуру сайта, доставшийся ему в наследство вместе с Windows сервером, понятно, что на IIS.

Решение:

Убеждаемся, что роль перенаправления HTTP включена.

Если не установлено, добавляем службу ролей.

Запускаем Диспетчер служб IIS, переходим на вкладку Просмотр содержимого и выбираем требуемый файл или каталог.

Нажимаем правой кнопкой мыши, Переключится в режим просмотра возможностей, затем выбираем Перенаправление протокола HTTP

И заполняем требуемые поля, затем нажимаем Применить.

Так же можно решить другим способом, в каталоге где находится объект с которого требуется сделать редирект, редактируем файл web.config и приводим к виду:

В этом примере настроен редирект 301 двух файлов 1.html на http://i-rrv.ru/2.html и 3.html на http://i-rrv.ru/4.html

В общем все, пробуйте развлекайтесь.

This entry was posted on Четверг, 5 марта, 2015 at 14:38 and is filed under IIS. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

Источник



Iis как настроить переадресацию

Как настроить в iis перенаправление домена на другой домен-01

Всем привет сегодня хочу рассказать как настроить в iis перенаправление домена на другой домен. Под перенаправлением домена подразумевается вот такая ситуация: допустим у вас есть сайт test.ru и у него у вас уже есть своя аудитория, вы решили перейти на другой домен и не хотите терять тех людей кто помнит ваш старый сайт для таких вещей и делаю редирект или перенаправление, и придя на сайт test.ru, человека перекинет на pyatilistnik.org для примера. Сделать это можно штатными средствами IIS сервера как и в 7 так и в 8 версии.

Открываем Диспетчер служб IIS, у вас при установке IIS сервера, должен был быть установлен компонент Перенаправление протокола HTTP

Как настроить в iis перенаправление домена на другой домен-02

Если во время установки вы его не поставили, то это можно сделать из диспетчера серверов-выбрав iis роль и нажав Добавить службы ролей

Как настроить в iis перенаправление домена на другой домен-03

У вас Диспетчер служб IIS должен быть сайт с которого будет перенаправление домена на другой домен, я для примера покажу свои привязки сайта

Как настроить в iis перенаправление домена на другой домен-04

Видим у меня слушаются два адреса обратившиь на которые будет идти перенаправление туда куда мне нужно

Как настроить в iis перенаправление домена на другой домен-05

Читайте также:  Как настроить карбюратор своими руками ваз 2105

Теперь выбираете сайт и слева от него перенаправление протокола HTTP, тут и настраивается iis перенаправление. Ставим галку Запросы на перенаправление по следующему назначению и пишите куда нужно перенаправлять. Так же советую поставить галку Запросы на перенапр. содержимого этого каталога (без подкаталогов)

Как настроить в iis перенаправление домена на другой домен-06

Все вот так вот просто настроить в iis перенаправление домена на другой домен.

Источник

Перенаправление URL-адреса IIS7 из корневого каталога в подкаталог

Я использую Windows Server 2008 с IIS7. Мне нужно перенаправить пользователей, которые приходят в www.mysite.com to wwww.mysite.com/menu_1/MainScreen.aspx . Вот файловая структура, которую я имею для проектов:

Я буду очень признателен за любую помощь в этом.

4 ответов:

Он будет делать 301 постоянный редирект (URL будет изменен в браузере). Если вы хотите, чтобы такой «редирект» был невидимым (переписать, внутренний редирект), то используйте это правило (разница только в том, что «редирект» был заменен «переписать»):

Я думаю, это можно сделать без модуля перезаписи URL IIS. поддерживает подстановочные знаки, поэтому вы можете настроить его следующим образом:

обратите внимание, что вы должны иметь функцию «перенаправление HTTP» включена на IIS-см. HTTP перенаправляет

Я не мог получить эту работу с принятым ответом, главным образом потому, что я не знал, где ввести этот код. Я искал везде какое-то объяснение инструмента перезаписи URL, которое имело смысл, но не смог найти его. В итоге я использовал инструмент перенаправления HTTP в IIS.

  1. выбираете вашего сайта
  2. нажмите http Redirect в разделе IIS (убедитесь, что Служба ролей установлена)
  3. Проверьте » перенаправить запросы на это пункт назначения»
  4. введите, куда вы хотите перенаправить. В вашем случае «wwww.mysite.com/menu_1/MainScreen.aspx»
  5. в поведении перенаправления я обнаружил, что мне нужно проверить «только перенаправлять запросы на контент в этом каталоге (а не в подкаталогах), или он войдет в цикл. Посмотрите, что работает для вас.

надеюсь, что это помогает.

инструмент называется «Microsoft URL Rewrite Module 2.0 для IIS 7» и описывается следующим образом корпорацией Майкрософт: «Модуль перезаписи URL 2.0 предоставляет механизм перезаписи на основе правил для изменения запрошенных URL-адресов до их обработки веб-сервером и для изменения содержимого ответа до его передачи HTTP-клиентам»

Источник

Перенаправление с помощью IIS URL Rewrite

Задача: необходимо настроить перенаправление домена с префиксом www на домен без www или наоборот.

Среда:

Windows Server 2008, IIS 7.5, URL Rewrite 2.0

Решение:

Url Rewrite — расширение для IIS, с помощью которого можно создавать перенаправления и обрабатывать запросы по схожему принципу работы RewriteRules в Linux.

Скачать Url Rewrite можно, перейдя по этой ссылке .

Итак, для того, чтобы создать перенаправление с http://www.site.com на site.com Вам необходимо выполнить такие действия :

1) Откройте IIS Manager, выберите домен и перейдите в меню «URL Rewrite»

2) Нажмите «Add rules» -> Blank rule с панели.

3) Настройте перенаправление.

В появившемся меню необходимо назвать перенаправление, которое будет выделятся среди остальных. Например, url rewrite.

В выпадающем списке с названием «Using» можно выбрать тип перенаправления — wildcard (предпочтительно) или регулярное (regular).
В поле «»Pattern» (шаблон) необходимо указать *. Это обозначает применения перенаправления для всех определений.
Откройте меню “Conditions” и нажмите “Add”. В меню диалога укажите следующие параметры :

Condition input:
Check if input string: Matches the Pattern
Pattern:
Ignore case: Отмечено.

После вышеуказанных действий, нажмите «Ок». Выражения, которые будут обрабатываться, мы настроили. теперь необходимо указать действие, которое будет применяться для данных выражений. В меню «Action» укажите тип действия — Redirect (перенаправление).
Action Properties — укажите http://www.site.com/
— сохраняет правильность обработки ссылки с и без www префикса.

Пункт «Append query string» должен быть отмечен. Тип перенаправления (“Redirect Type”) должен быть 301 (Permanent).

Примените данное правило, нажав кнопку «Apply». Созданное правило должно работать корректно.

Источник