Опубликован: 04.07.2008 | Доступ: свободный | Студентов: 636 / 33 | Оценка: 4.83 / 5.00 | Длительность: 42:11:00
Лекция 5:

Прокси-серверы

< Лекция 4 || Лекция 5: 12345 || Лекция 6 >
Рассмотрение ограничителей URL-адресов для Domino

Большинство прокси-серверов имеет также возможность принятия во внимание ограничителей URL, которые сообщают прокси-серверу, что данное значение должно трактоваться как часть основного URL для преобразования адресов. Ограничители URL (именуемые в IBM WebSphere Edge Server как параметр SignificantUrlTerminator) должны быть созданы для Domino, так как большинство URL-адресов Domino содержат символ "?" и соответственно трактуются прокси-сервером как URL-адреса запросов для возможного кеширования.

Специфическими ограничителями URL, требуемыми для поддержки Domino, являются:

SignificantUrlTerminator ?OpenImageResource
SignificantUrlTerminator ?OpenElement
SignificantUrlTerminator /?OpenImageResource
SignificantUrlTerminator /?OpenElement
Обработка перенаправляющих ответов от Domino

Инструкция ReversePass (обратная пересылка) большинства прокси-серверов перехватывает стандартные перенаправляющие ответы 302 от Domino и переписывает их для нового места назначения. Это новое место назначения должно являться допустимым URL-именем с таким расчетом, что, когда конечный пользователь запросит обновленную страницу после перенаправления, она будет действительной:

ReversePass http://xxx.xxx.xxx.xxx/* http://proxy.formymailserver.web/*
Дополнительная информация

Дополнительную информацию о конфигурировании Domino для использования за обратным прокси-сервером можно найти в статье с домена Lotus Developer Domain (LLD) "Конфигурирование Web-доступа к iNotes при использовании обратного прокси-сервера WebSphere Edge". Эта статья может быть найдена на сайте LDD по адресу:

http://www-10.lotus.com/ldd/today.nsf/62f62847467a8f78052568a80055b380/ ff0e835068e03c3685256cda0054a213?OpenDocument&Highlight=0,reverse,proxy

5.5 Поддержка прокси в Lotus Sametime 3.1

В то время как другие технологии Lotus поддерживали использующие обратные прокси-серверы инфраструктуры самостоятельно, поддержка прокси в продукте Lotus Instant Messaging and Web Conferencing (Sametime) началась с версии 3.1. В этом разделе рассматриваются определенные проблемы относительно совместного использования прокси-серверов HTTP и сервера Sametime 3.1, так как эти проблемы являются более сложными и запутанными, чем у других рассмотренных нами до этого момента технологий Lotus.

Более детальную информацию о поддержке обратных прокси в Sametime 3.1 можно найти в руководстве администратора Sametime 3.1 Administrators Guide, которое является частью документации на продукт. Данная документация доступна в домене Lotus Developer Domain по адресу:

http://www.lotus.com/ldd

5.5.1 Обзор поддержки прокси в Sametime 3.1

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

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

5.5.2 Требования к обратным прокси-серверам

В этом разделе перечислены требования, которым должен соответствовать обратный прокси-сервер для совместного использования с Sametime 3.1.

Требование к спецификации URL (требование родственного id)

Совместно с Sametime могут быть использованы только те обратные прокси-серверы, которые поддерживают использование "идентификаторов схожести" ( affinity-id ) (или псевдонимов сервера) в тех URL-адресах, которые связаны с внутренними серверами. Если более точно, то обратный прокси-сервер должен поддерживать эту спецификацию URL для доступа к защищенным внутренним серверам:

http[s]://hostname:port/affinity-id/

В этом примере "hostname" представляет собой полное доменное имя машины ( FQDN ) (DNS-имя) обратного прокси-сервера, а "affinity-id" является псевдонимом внутреннего сервера, который защищен посредством обратного прокси-сервера. Точным примером URL такого формата является

http[s]://reverseproxy.ibm.com/st01/stcenter.nsf

В этом примере текстовая строка "st01" является идентификатором схожести ( affinity-id ). Родственный id является псевдонимом определенного сервера Sametime (такого, как sametime.ibm.com), который защищен посредством обратного прокси-сервера. Родственный id используется обратным прокси-сервером для направления входящих запросов на определенный внутренний сервер Sametime.

Среды со множеством обратных прокси-серверов

Если вы разместили в вашей сетевой среде множество обратных прокси-серверов и ожидаете, что пользователи будут осуществлять доступ к вашим серверам Sametime через это множество обратных прокси-серверов, то к вашей среде возникают некоторые особые требования:

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

    К примеру, если один из обратных прокси-серверов имеет имя reverseproxy.ibm.com, то и все другие обратные прокси-серверы должны иметь имя reverseproxy.ibm.com. Если обратные прокси-серверы имеют различные DNS-имена, то клиенты Sametime будут неспособны поддерживать связь с сервером Sametime, расположенным за обратными прокси-серверами. Для распределения соединений от Web-браузеров к множеству обратных прокси-серверов должно быть использовано устройство, управляющее распределением соединений (такое, как IBM WebSphere Edge Server).

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

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

< Лекция 4 || Лекция 5: 12345 || Лекция 6 >