Thursday, October 18th, 2018

Публикация нескольких не SSL Web сайтов с использованием одного IP адреса с помощью брандмауэра ISA

Published on Февраль 9, 2009 by   ·   Комментариев нет

Одна из самых классных вещей, которые вы можете делать при помощи брандмауэра ISA – это опубликовать несколько Web сайтов, используя один IP адрес во внешнем интерфейсе. Вы можете использовать один IP адрес для внешнего интерфейса брандмауэра ISA, чтобы опубликовать несколько сайтов, или вы можете иметь сотню адресов во внешнем интерфейсе. Компонент фильтр Web прокси брандмауэра ISA делает все это возможным.

Кроме простой проверки пакетов, перенаправление портов и реверсирования NAT, которое выполняют обычные брандмауэры, брандмауэр ISA дополняет свой механизм проверки пакетов с помощью фильтра Web прокси, который общается со службами брандмауэра ISA. Фильтр Web прокси брандмауэра ISA расширяет возможности по инспектированию, добавляя инспектирование уровней приложения. Инспектирование уровней приложения фильтра Web прокси – это то, что позволяет вам публиковать несколько Web сайтов, используя один IP адрес.

В этой статье мы сделаем следующее:

  • Изучим различия между обыкновенными брандмауэрами и брандмауэрами с расширенной проверкой уровней приложения (таких как ISA), позволяющие публиковать несколько сайтов
    Обыкновенный брандмауэр и устройства NAT не могут выполнять дополнительную проверку заголовков протокола HTTP. Здесь вы изучите различия и увидите, почему брандмауэр не твердо стоит на ногах
  • Опишем пример публикации среды, использованной в этой статье
    Здесь, я дам вам подробный обзор лабораторной работы и предоставлю вам таблицу с деталями.
  • Опубликуем два Web сайта, используя правила публикации Web (Web Publishing Rules)
    Это изюминка статьи. Здесь, вы создадите два правила публикации Web, которые позволят вам опубликовать несколько Web сайтов с помощью одного IP адреса во внешнем интерфейсе брандмауэра ISA

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

Nat прокси и брандмауэров

Рисунок 1: Таблица для этой статьи

Сравнение Web Publishing у простых устройств проверки пакетов и брандмауэров с расширенной проверкой приложений (ISA)

Рисунок ниже показывает, что случится, если вы попробуете предоставить удаленный доступ для Web сайтов, используя простой брандмауэр для проверки пакетов или устройство NAT.

  1. Внешний клиент вводит название сайта в Web браузер, и таким образом генерирует DNS запрос ко внешнему серверу DNS. К примеру, внешний клиент посылает запрос к компьютеру (A), набрав www.msfirewall.org. DNS возвращает адрес 192.168.1.71.
  2. Внешний клиент посылает запрос GET на 192.168.1.71 и включает в Host Header (заголовок компьютера) уровня приложения название www.msfirewall.org. Запрос на соединение приходит во внешний интерфейс устройства для анализа пакетов. У устройства есть правило, которое говорит перенаправлять все соединения, входящие на 192.168.1.71 TCP 80 на адрес 10.0.0.11 TCP 80. Вот так. Обыкновенное устройство для анализа пакетов не имеет возможность проверять информацию уровня приложения и полностью игнорирует Host Header.
  3. Запрос на соединение перенаправляется на Web сервер во внутренней сети, который находится по адресу 10.0.0.11 TCP 80.

    Несколько ssl на одном IP

    Рисунок 2: Простое устройство для анализа пакетов не в состоянии делать интеллектуальные решения, основанные на информации заголовка уровня приложения

Пока все выглядит и работает достаточно хорошо с одним простым устройством для проверки пакетов. Но что случится если у вас только одни IP адрес во внешнем интерфейсе устройства для проверки пакетов, а вы хотите опубликовать второй Web сайт во внутренней сети? Этот вариант не будет работать, потому что первый сокет (комбинация транспортного протокола, IP адреса и порта) занят первым правилом.

В заголовке уровня 3 (или ниже) нет информации, которая позволяет простому устройству проверки пакетов выяснить, с каким Web сайтом необходимо соединиться, все, что оно знает, это что оно должно переслать соединение на определенный IP адрес по определенному протоколу и порту, затем оно должно последовать правилу, которое говорит на какой именно IP адрес порт и по какому протоколу необходимо это сделать.

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

Существует несколько проблем при таком подходе, включая тот факт, что не все Web сервера поддерживают host headers, которые позволяют размещать несколько сайтов по одному IP адресу, когда требуется SSL, и когда все эти сайты размещены на одном физическом Web сервер. Если Host Headers не работает, то другой вариант – это назначить каждый из сайтов на разные порты. Однако, это может быть проблематично, потому что внешним пользователям необходимо будет помнить, какой из портов использовать, и если вы используете различные компьютеры в локальный сети, то таким же пользователям в локальной сети необходимо будет запомнить, какой из портов использовать для доступа к ресурсам.

Противоположностью простым устройствам для проверки пакет является брандмауэр ISA. Брандмауэр ISA – это брандмауэр для проверки пакетов, а также много другого. Брандмауэр ISA обеспечивает проверку пакетного уровня, а также уровня приложения. Фильтр Web прокси брандмауэра ISA способен работать с механизмом проверки пакетов брандмауэра ISA и получать информацию о соединении, после того, как информация была очищена при помощи компонентов брандмауэра. Фильтр Web прокси выполняет проверку уровня приложения, после того, как завершается проверка пакетного уровня.

Рисунок ниже показывает, как все работает, если вы используете интеллектуальный брандмауэр ISA для проверки уровня приложения:

  1. Внешний пользователь вводит http://www.msfirewall.org/ в браузер, и DNS запрос посылается на внешний DNS сервер для этого названия. DNS сервер возвращает адрес 192.168.1.71.
  2. Затем, внешний клиент посылает запрос GET по адресу 192.168.1.71 TCP 80 с HTTP Host Header http://www.msfirewall.org/, включенным в запрос. Брандмауэр ISA выполняет проверку пакетов при соединении, и после того, как информация очищена, она перенаправляется на фильтр Web прокси. Фильтр Web проверяет информацию уровня приложения. В этом случае, уровень приложения содержит в Host Header. Фильтр Web proxy на брандмауэре ISA определяет, что запрашивается http://www.msfirewall.org/.
  3. Правило Web Publishing Rule на брандмауэре ISA сконфигурировано так, чтобы перенаправить запросы для http://www.msfirewall.org/ на http://www.msfirewall.org/ во внутренней сети. Запрос перенаправляется на Web сайт, который слушает по адресу 10.0.0.11, что соответствует http://www.msfirewall.org/ во внутренней сети.
  4. Во втором сценарии, на шаге 1, Web браузер делает запрос для www2.msfirewall.org, а DNS запрашивает DNS сервер, который преобразует запрос в IP адрес 192.168.1.71. Web браузер посылает запрос GET на IP адрес 192.168.1.71 с заголовком Host Header www2.msfirewall.org, содержащимся в запросе.
  5. Брандмауэр ISA настроен с помощью правила Web Publishing Rule так, что направляет HTTP запрос для www2.msfirewall.org на Web сайт во внутренней сети, который соответствует www2.msfirewall.org, если использовать внутренний DNS сервер. В этом примере, www2.msfirewall.org во внутренней сети соответствует IP адресу 10.0.0.12.

    Asa публикация нескольких web

    Рисунок 3: Брандмауэр с проверкой уровня приложения (как ISA) может проверять HTTP уровень приложения и делать интеллектуальные решения, основанные на этой информации

Заметьте, что в примерах, брандмауэр ISA использует частный адрес для внешнего интерфейса. Я сделал это потому, что мы будем использовать эти адреса в пошаговом примере, который приведен в этой статье. В реальной жизни, публичный DNS сервер, не будет иметь публичную запись DNS с использованием частного IP адреса. Вместо этого, записи публичного DNS сервера указывают на публичный адрес, используемый для доступа опубликованного Web сайта. Публичный адрес может быть связан с внешним интерфейсом брандмауэра ISA, или с внешним интерфейсом устройства NAT.

Сетевая среда, используемая в этой статье

В этой статье мы публикуем два Web сайта, которые размещены на одном IIS 6.0 Web сервере. Необходимая информация о Web сайтах приведена в таблице ниже.

Таблица 1: Названия и IP адреса Web сайтов

Оба сайта доступны по одному IP адресу, что демонстрирует, как публиковать несколько сайтов с использованием одного IP адреса. В этом примере я использовал лучшие упражнения брандмауэра ISA, установив разделенную DNS инфраструктуру и использовав одно имя домен для внутренних и внешних ресурсов.

Разделенная DNS инфраструктура позволяет вам обеспечить доступ к Web ресурсам для внутренних и внешних клиентов, используя одинаковые названия. Разделенная DNS инфраструктура предоставляет вам стратегические выгоды благодаря:

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

Когда используется разделенная DNS инфраструктура, брандмауэр ISA согласует полностью определенное название опубликованного Web сервера с IP адресом Web сайта во внутренней сети. Брандмауэр ISA никогда не должен согласовывать названия опубликованных Web сайтов с внешним адресом во внешней сети брандмауэра ISA, который используется внешними пользователями для доступа к сайту.

Хотя мы используем одинаковое название домена второго уровня для двух Web сайтов, ну существует ограничений в этой области. Я мог опубликовать два сайта, как http://www.msfirewall.org/ и http://www.isafirewall.org/ используя один IP адрес с помощью методов, которые мы использовали для публикации двух сайтов, представленных в таблице. Эти процедуры одинаковы.

Заметьте, что все немного сложнее, если вы планируете публиковать SSL сайты. Причина этого заключается в том, что общие названия сертификатов, связанных с Web listener (слушателями Web) и действительными Web сайтами имеют большое влияние на то, что вы можете и не можете делать при публикации нескольких Web сайтов. Я обсужу, как опубликовать несколько SSL сайтов с использованием одного IP адреса в другой статье.

Предупреждение:
Последнее замечание. Эта статья не обеспечивает подробного описания того, что такое Web Publishing Rules, и как они работают. Существуют конфигурации безопасности и нюансы, которые не затрагиваются Web Publishing Rule Wizard (помощник для создания правил для публикаций). О детальном описании Web Publishing Rules, и как использовать большинство из них, читайте в нашей книге Configuring ISA Server 2004 (настройка сервера ISA).

Публикация Web сайтов с использованием правил публикации Web брандмауэра ISA

Я предположу, что вы уже установили программное обеспечение брандмауэра ISA, но еще не создали никаких Web Publishing Rules или Web listeners.

Первый шаг – это создание слушателя Web (Web listener). Вы можете создать Web listener на лету, при создании Web Publishing Rule. Но мне иногда нравится делать одни и те же вещи по-разному. Поэтому давайте сначала создадим слушателя Web.

Создание Web Listener

Для создания Web listener выполните следующую последовательность шагов:

Название сайта/Возможности Web сайт 1 Web сайт 2
Public Name http://www.msfirewall.org/ www2.msfirewall.org
Public IP address 192.168.1.71 192.168.1.71
Private Name http://www.msfirewall.org/ www2.msfirewall.org
Private IP address 0.0.11 0.0.12
  • В консоли брандмауэра ISA раскройте название сервера в левом окне консоли и нажмите на узле Firewall Policy. Нажмите на закладку Toolbox, а затем, нажмите на заголовке Network Object. Выберите в меню New, а затем нажмите Web Listener.
  • На странице Welcome to the new Web Listener Wizard введите название слушателя в поле Web listener name. В этом примере мы назовем слушателя именем HTTP Listener. Нажмите Next.
  • На странице IP Addresses поставьте галочку в поле External и нажмите Next.

    На одном IP два web устройства

    Рисунок 4
  • На странице Port Specification подтвердите, что стоит галочка в поле Enable HTTP, и что HTTP port равен 80. Убедитесь, что не стоит галочка в поле Enable SSL. Мы не хотим, чтобы этот слушатель обслуживал SSL запросы. Я покажу вам, как публиковать несколько SSL Web сайтов в другой статье. Нажмите Next.
  • Нажмите Finish на странице Completing the New Web Listener Wizard.
    Создание Web Publishing Rule для http://www.msfirewall.org/

    Теперь, когда у нас есть Web listener, мы можем создать первое правило Web Publishing Rule. Для создания Web Publishing Rule для http://www.msfirewall.org/ Web сайта, который слушает по адресу 10.0.0.11 во внутренней сети, выполните следующие шаги:

  • В консоли брандмауэра ISA раскройте название сервера и нажмите на узле Firewall Policy. В окне Task, нажмите на закладке Tasks, а затем нажмите на ссылку Publish a Web Server.
  • На странице Welcome to the New Web Publishing Rule Wizard введите название правила Web Publishing Rule в поле Web Publishing Rule name. В этом примере мы назвали правило WWW Site. Нажмите на кнопку Next.
  • Нажмите Allow на странице Select Rule Action.
  • На странице Define to Website to Publish введите название Web сайта во внутренней сети в поле Computer name or IP address. Обратите внимание, что это название должно соответствовать IP адресу, по которому слушает внутренний Web сайт. В этом примере, http://www.msfirewall.org/ слушает по адресу 10.0.0.11 и существует DNS запись на внутреннем сервере DNS, которая сопоставляет это название с этим IP адресом. Мы хотим разрешить доступ ко всем файлам и папкам на Web сайте, поэтому мы введем /* в поле Path. Нажмите Next.

    Публикация в нескольких соцсетях

    Рисунок 5
  • На странице Public Name Details выберите This domain name (type below) настройку в выпадающем списке Accept requests for. В поле Public name введите http://www.msfirewall.org/. Это название, которое будут использовать внешние пользователи для доступа к сайте, и это название должно добавлено в заголовок Host Header в запросе. К примеру, пользователи должны иметь доступ к сайту используя http://www.msfirewall.org/. Они не могут использовать http://192.168.1.71, т.к. в результате такого запроса название http://www.msfirewall.org/ не попадет в заголовок Host Header. Нажмите Next.
  • На странице Select Web Listener, выберите пункт HTTP Listener из выпадающего списка Web listener и нажмите Next.
  • Нажмите Next на странице User Sets.
  • Нажмите Finish на странице Completing the New Web Publishing Rule Wizard.
    Создание правила Web Publishing Rule для www2.msfirewall.org

    Теперь давайте создадим правило Web Publishing Rule для www2.msfirewall.org:

  • В консоли брандмауэра ISA firewall раскройте название сервера и нажмите на узле Firewall Policy. В окне Task выберите закладку Tasks и нажмите ссылку Publish a Web Server.
  • На странице Welcome to the New Web Publishing Rule Wizard введите название правила Web Publishing Rule в поле Web Publishing Rule name. В этом примере мы назвали правило WWW2 Site. Нажмите Next.
  • Нажмите Allow на странице Select Rule Action.
  • На странице Define to Website to Publish введите название Web сайта во внутренней сети в поле Computer name or IP address. Заметьте, что это название должно соответствовать IP адресу, по которому слушает внутренний Web сайт. В нашем примере www2.msfirewall.org слушает по адресу 10.0.0.12 и существует DNS на внутреннем сервере DNS, которая сопоставляет это название с этому IP адресу. Мы хотим разрешить доступ ко всем файлам и папкам на Web сайте, поэтому мы введем /* в поле Path. Нажмите Next.

    Адреса web сайтов

    Рисунок 6

  • На странице Public Name Details выберите настройку This domain name (type below) в выпадающем списке Accept requests for. В поле Public name введите www2.msfirewall.org. Это название внешние пользователи будут использовать для доступа к сайту, и это самое название будет включено в заголовок запроса. Пользователи должны вводить http://www2.msfirewall.org/. Они не могут ввести http://192.168.1.71, т.к. в результате этого www2.msfirewall.org не попадет в заголовок Host Header. Нажмите Next.
  • На странице Select Web Listener выберите пункт HTTP Listener из выпадающего списка Web listener и нажмите Next.
  • Нажмите Next на странице User Sets.
  • Нажмите Finish на странице Completing the New Web Publishing Rule Wizard.

Тестирование решения

Теперь давайте протестируем решение. На машине внешнего клиента, введем http://www.msfirewall.org/ в поле адреса Internet Explorer. Вы должны увидеть страницу по умолчанию для этого сайта.

Выполните аналогичное действие с www2.msfirewall.org. Вы должны увидеть страницу по умолчанию для этого сайта.

OK, это было все не очень восхитительно, но вы узнали, что можете опубликовать два Web сайта, используя всего один IP адрес во внешнем интерфейсе брандмауэра ISA. Обратите внимание, что этот тест работает лишь в случае, когда вы правильно настроили DNS сервер, Web Listener и Web Publishing Rules, которые вы создали.

Резюме

В этой статье мы изучили различия между обыкновенными брандмауэрами для проверки пакетов и брандмауэрами с расширенной проверкой уровня приложения, таким, как брандмауэр ISA. Затем мы перешли в лабораторию и проверили наши предположения на практике. Правила Web Publishing Rules были использованы для того, чтобы получить доступ к двум различным Web сайтам, размещенным по одному IP адресу внешнего интерфейса брандмауэра ISA. Мы завершили статью проверкой доступа к обоим сайтам, опубликованных на сервере.

www.isaserver.org








Смотрите также:

Tags: , , , , ,

Readers Comments (Комментариев нет)




Да человек я, человек! =)

Exchange 2007

Проведение мониторинга Exchange 2007 с помощью диспетчера System Center Operations Manager 2007 (часть 3)

Если вы хотите прочитать предыдущие части этой серии статей, перейдите по ссылкам: Проведение мониторинга Exchange 2007 с помощью диспетчера System ... [+]

Практическое рассмотрение перехода с Exchange 2003 на Exchange 2007 (часть 1)

Введение В этой статье из нескольких частей я хочу показать вам процесс, который недавно использовал для перехода с существующей среды Exchange 2003 ... [+]

Использование инструмента Exchange Server Remote Connectivity Analyzer Tool (часть 2)

Если вы пропустили первую часть этой серии, пожалуйста, прочтите ее по ссылке Использование инструмента Exchange Server Remote Connectivity Analyzer Tool (Часть ... [+]

Мониторинг Exchange 2007 с помощью диспетчера System Center Operations Manager 2007 (часть 2)

Если вы пропустили предыдущую часть этой серии статей, перейдите по ссылке Мониторинг Exchange 2007 с помощью диспетчера System Center Operations ... [+]

Подробное рассмотрение подготовки Active Directory для Exchange 2007 (часть 5)

Если вы пропустили предыдущие части этой серии статей, перейдите по ссылкам: Подробное рассмотрение подготовки Active Directory для Exchange 2007 (часть 1) ... [+]

Установка и настройка Exchange 2007 из командной строки (Часть 3)

If you missed the previous parts in this article series please read: Exchange 2007 Install and Configuration from the command line (Part ... [+]

Использование инструмента Exchange Server Remote Connectivity Analyzer Tool (часть 1)

Инструмент ExRCA Текущий выпуск инструмента предоставляется только в целях тестирования и оснащен 5 опциями: Тест подключения Outlook 2007 Autodiscover Тест подключения Outlook 2003 RPC ... [+]

Развертывание сервера Exchange 2007 Edge Transport (часть 5)

Если вы хотите прочитать предыдущие части этой серии статей, перейдите по ссылкам: Развертывание сервера Exchange 2007 Edge Transport (часть 1) Развертывание ... [+]

Установка и настройка Exchange 2007 из командной строки (часть 2)

Если вы пропустили первую статью данного цикла, пожалуйста, перейдите по ссылке: Exchange 2007 Install and Configuration from the command line (Part ... [+]

Использование интегрированных сценариев Using Exchange Server 2007 – часть 2: генерирование отчетов агента Transport AntiSpam Agent

Если вы пропустили предыдущую часть этой серии статей, перейдите по ссылке Использование интегрированных сценариев Using Exchange Server 2007 – часть ... [+]