ISA - Изучаем ISA Server | icuwa, web сервер, proxy сервер

Правила публикации Web-сервера позволяют публиковать многочисленные Webсайты, используя один IP-адрес во внешнем интерфейсе брандмауэра ISA. Это возможно благодаря способности брандмауэра ISA выполнять на уровне приложений проверку, отслеживающую соединения. Частью механизма такой проверки служит способность брандмауэра ISA анализировать заголовок хоста во входящем запросе и принимать решение об обработке входящего запроса на основе информации заголовка хоста. Предположим, что имеется единственный IP-адрес во внешнем интерфейсе брандмауэра ISA. Необходимо опубликовать два Web-сервера в сети, защищенной брандмауэром ISA. Пользователи будут обращаться к Web-сайтам с помощью URL-адресов www.msfirewall.org и www.tacteam.net. Все, что потребуется, — создать два правила публикации Web-сервера. Одно из них будет ожидать (прослушивать) входящие соединен i ия к сайту www.msfirewall.org и передавать эти запросы на сервер msfirewall.org в сети, защищенной брандмауэром ISA, а другое правило публикации Web-сервера будет ожидать запросы к сайту www.tacteam.net и пересылать их Web-сайту в сети, защищенной брандмауэром ISA, ответственному за Web-сайт www.tacteam.net. Главное при решении этой задачи (мы будем обсуждать ее чуть позже в этой главе) быть уверенным в том, что общедоступный DNS-сервер преобразует (разрешает) полностью определенные имена доменов (fully-qualified domain names) в IP-адрес во внешнем интерфейсе брандмауэра ISA. Как только первый DNS-результат получен, опубликовать два или двести Web-сайтов очень просто, используя правила публикации Web-сервера. Возможность с помощью Link Translator брандмауэра ISA перезаписывать URL-адреса, возвращаемые опубликованным Web-сайтом Транслятор ссылок брандмауэра ISA может перезаписывать ответы, которые опубликованные Web-серверы посылают пользователям, сделавшим запрос. Транслятор ссылок полезен при публикации Web-сайтов, включающих в свои ответы жестко закодированные URL-адреса, недоступные с удаленных компьютеров. Предположим, что публикуется Web-сайт, жестко кодирующий URL-адреса в своих ответах, и эти адреса включают частные имена (private names) серверов в защищенной сети. Такие URL-адреса будут иметь форму http://server l /documents или http:/ /webserver2/users. Поскольку это не полностью определенные имена доменов, доступные из Интернета, запрос на соединение завершится неудачей. Это обычная проблема для Web-сайтов SharePoint Portal Server (система управления и совместного использования документов). Транслятор ссылок решает эту проблему, перезаписывая ответы, возвращаемые обратившемуся к Web-сайту пользователю. Ссылки http://serverl /documents и http:// webserver2/users перезаписываются как http://www.msfirewall.org/documents и http:// www. tacteam.net/users, каждая из которых доступна из Интернета. Трансляция ссылок также полезна в некоторых SSL-сценариях. Например, если не используется протокол SSL (Secure Sockets Layer, протокол защищенных сокетов) при соединении брандмауэра ISA с Web-сервером, но применяется SSL в соединении Web-клиента из Интернета с брандмауэром ISA, транслятор ссылок может изменить HTTP-ответ, возвращаемый Web-сервером, на SSL-ответ в ссылках, предоставляемых пользователю. Это избавляет пользователей от обнаружения испорченных ссылок на опубликованной Web-странице. Мы обсудим применение и настройку параметров транслятора ссылок в этой главе и более подробно в главе 1при описании фильтрации прикладного уровня.