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 означает «не придираться к сертификату»). Стоит, однако, понимать, что клиент все-таки получает тот сертификат, который мы вписали при создании фронтенда. Если нужно подсовывать именно сертификат конечного сервера, то можнжо использовать способ, описанный в топике, который я указал выше.

Ещё один момент: хочется красиво редиректить 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

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

Источник

Как перенаправить URL-путь в IIS?

в IIS 6.0 есть простой способ перенаправить запросы в папку в другую папку, сохраняя при этом остальную часть пути.

Если я переместил содержимое:
мистит.орг.uk / stuff
к
вещи.мистит.орг.uk/

могу ли я автоматически перенаправлять запросы на определенные страницы как
mysite.org.uk/stuff/countrybriefing/tanzania/travel.html
к
stuff.mysite.org.uk/countrybriefing/tanzania/travel.html

4 ответов

перенаправление веб-сайтов в IIS версии 6.0 (IIS 6.0)

когда браузер запрашивает страницу или программу на вашем веб-сайте, Веб-сервер находит страницу, указанную URL-адресом, и возвращает ее в браузер. При перемещении страницы на веб-сайте не всегда можно исправить все ссылки, ссылающиеся на старый URL-адрес страницы. Чтобы убедиться, что браузеры могут найти страницу по новому адресу, вы можете веб-сервер, чтобы перенаправить на новый URL-адрес.

вы можете перенаправлять запросы на файлы в одном каталоге в другой каталог, на другой веб-сайт или в другой файл в другом каталоге. Когда браузер запрашивает файл по исходному URL-адресу, веб-сервер указывает браузеру запросить страницу с помощью нового URL-адреса.

вы должны быть членом группы администраторов локальном компьютере выполнить следующие процедуры. В целях безопасности рекомендуется войти в систему с помощью учетной записи, не входящей в группу «Администраторы», а затем с помощью команды runas запустить Диспетчер IIS от имени администратора. В командной строке введите runas /user:Administrative_AccountName «mmc %systemroot%\system32\inetsrv\iis.магистр.»

процедуры

перенаправлять запросы на другой веб-сайт или каталог

в Диспетчере IIS разверните локальный компьютер, щелкните правой кнопкой мыши веб-узел или каталог, который требуется перенаправить, и выберите Свойства.

перейдите на вкладку домашний каталог, виртуальный каталог или каталог.

по материалам этого источника выберите перенаправление на URL-адрес.

в поле перенаправление на введите URL-адрес целевого каталога или веб-страницы сайт. Например, чтобы перенаправить все запросы на файлы в каталоге каталога в каталог NewCatalog, введите /NewCatalog.

перенаправить все запросы в один файл

в Диспетчере IIS разверните локальный компьютер, щелкните правой кнопкой мыши веб-узел или каталог, который требуется перенаправить, и выберите Свойства.

щелкните домашний каталог, виртуальный каталог или каталог табуляция.

по материалам этого источника выберите перенаправление на URL-адрес.

в поле перенаправление на введите URL-адрес файла назначения.

установите флажок точный URL-адрес, указанный выше, чтобы запретить веб-серверу добавлять исходное имя файла к целевому URL-адресу.

вы можете использовать подстановочные знаки и перенаправлять переменные в URL-адресе назначения, чтобы точно контролировать, как исходный URL-адрес переводится в целевой URL-адрес.

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

перенаправлять запросы в программу

в Диспетчере IIS разверните локальный компьютер, щелкните правой кнопкой мыши веб-узел или каталог вы хотите перенаправить и нажмите «Свойства».

перейдите на вкладку домашний каталог, виртуальный каталог или каталог.

по материалам этого источника выберите перенаправление на URL-адрес.

установите флажок точный URL-адрес, указанный выше, чтобы запретить веб-серверу добавлять исходное имя файла к целевому URL-адресу.

отформатируйте URL перенаправления следующим образом:

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

Он также позволяет вам сопоставлять шаблоны на основе выражений reg ex и т. д. Я использовал, где мне пришлось перенаправить 100 страниц, и это сэкономило много времени.

вот конфигурация для ISAPI_Rewrite 3:

перезаписать % ^mysite.орг.uk$ [NC]

Источник

HTTP Redirects

The element configures settings for Internet Information Services (IIS) 7 that redirect client requests to a new location.

There are several reasons why you might want to redirect clients to a new location. For example, if your company is migrating to a new Web site, you could redirect all requests from the old Web site to the new Web site. Likewise, if you have deployed a new application on a Web server, you could redirect all requests for the old application’s URL namespace (for example, http://www.contoso.com/app_v1.0/ ) to the new applications location (for example, http://www.contoso.com/app_v2.0/ ).

In the simplest configuration, you need only set the enabled and destination attributes of the element in order to redirect clients to a new location. However, additional elements like the exactDestination and httpResponseStatus attributes allow you to configure the end-user experience of the redirection by respectively specifying whether IIS 7 will return the destination URL exactly as entered and which HTTP response code to return to the Web client.

Compatibility

Setup

HTTP Redirection is not available on the default installation of IIS 7 and later. To install it, use the following steps.

Windows Server 2012 or Windows Server 2012 R2

Windows 8 or Windows 8.1

Windows Server 2008 or Windows Server 2008 R2

Windows Vista or Windows 7

How To

There is no user interface for adding wildcard HTTP redirects for IIS 7. For examples of how to add elements to the element programmatically, see the Code Samples section of this document.

How to add an HTTP redirect rule to a Web site or application

Open Internet Information Services (IIS) Manager:

If you are using Windows Server 2012 or Windows Server 2012 R2:

If you are using Windows 8 or Windows 8.1:

If you are using Windows Server 2008 or Windows Server 2008 R2:

If you are using Windows Vista or Windows 7:

In the Connections pane, expand the server name, expand Sites, and then navigate to the Web site or application that you want to configure custom error pages for.

In the Home pane, double-click HTTP Redirect.

In the HTTP Redirect pane, check the box to redirect requests and enter the destination URL.

You can optionally specify any of the following options:

Configure the redirection destination to be the exact destination as entered.

Configure the redirection destination to be limited to the destination URL’s root folder, not subfolders.

Configure the HTTP status code, which can be one of these three options:

IIS 7 will respectively return the following actual HTTP response statuses for each of the above options:

When you have finished all the above changes, click Apply in the Tasks pane.

Configuration

Attributes

Specifies a URL or virtual path to which to redirect the client.enabledOptional Boolean attribute.

Specifies whether redirection is enabled (true) or disabled (false).

Specifies that the destination value should be considered an absolute target location, not a relative location.

Specifies type of redirection.

Child Elements

Adds a wildcard redirection rule to the collection of redirection rules.clearOptional element.

Removes all references to wildcard redirection rules from the collection of redirection rules.removeOptional element.

Removes a reference to a wildcard redirection rule from the collection of redirection rules.

Configuration Sample

The following default element is configured in the root ApplicationHost.config file in IIS 7 when the HTTP Redirection role service is installed. This configuration section inherits the default configuration settings unless you use the element.

The following configuration sample enables redirection and configures the destination URL to which clients are redirected.

The following configuration sample adds a wildcard redirection entry that redirects all requests for PHP files to the home page of your Web site.

This example is useful if you have removed all ASP-based applications from your Web site and you wanted client requests for the old applications to be redirected to the root of your Web site rather than receiving an HTTP 404 Not Found response.

Sample Code

The following code samples configure the Default Web Site to redirect all requests to http://www.contoso.com using an HTTP 302 status code.

AppCmd.exe

VB.NET

JavaScript

VBScript

The following code samples adds a wildcard redirection entry that redirects all requests for ASP files to the home page of your Web site.

This example is useful if you have removed all ASP-based applications from your Web site and you wanted client requests for the old applications to be redirected to the root of your Web site rather than receiving an HTTP 404 Not Found response.

Источник

🌐 Как перенаправить HTTP на HTTPS в IIS

Это руководство поможет вам настроить IIS для перенаправления любого URL-адреса с HTTP на HTTPS.

Это хорошая практика, чтобы рабочие URL-адреса всегда были на безопасной странице.

После завершения этого руководства все незащищенные (HTTP) запросы к вашим веб-сайтам будут перенаправлены на защищенные (HTTPS) в IIS в Windows.

Прежде чем мы начнем

Мы предполагаем, что вы уже установили SSL-сертификат в IIS.

Также добавлена привязка SSL к вашим сайтам с портом 443 и установленным сертификатом.

Шаг 1 – Установите модуль URL-Rewrite

Мы будем использовать модуль URL Rewrite на IIS для перенаправления трафика с HTTP на HTTPS.

Прежде всего, вам необходимо скачать и установить этот модуль отсюда:

Шаг 2. Настройка редиректа трафика с HTTP на HTTPS

Шаг 2. Настройка перенаправления HTTP на HTTPS

После завершения установки выполните следующие шаги для завершения перенаправления HTTPS в IIS.

1. Запустите IIS Manager и выберите веб-сайт в разделе подключений слева.

2. Вы увидите все параметры конфигурации в среднем окне. Просто дважды щелкните по значку URL Rewrite.

Проверка

Для проверки откройте ваш URL в браузере через http, и он должен автоматически перенаправить вас на https.

День добрый.
Хорошо когда все срабатывает.
Хуже когда нет. И всю голову раскурочил – не работает и всё тут.
Уже каждый раз чищу всю историю с кукисами – ничего не помогает. Не перенаправляет, зараза, и всё тут.
Куда копать – не понимаю.

Добрый день, а сам сайт работает на 443 порту? С сертификатом все ок?

Тоже ничего не получалось. Создал привязку для сайта по 80 порту (в дополнение к уже созданной по 443) и все заработало.

Anything in here will be replaced on browsers that support the canvas element

Источник