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

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

< Лекция 4 || Лекция 5: 12345 || Лекция 6 >
Обратный прокси-сервер должен использовать для аутентификации cookies

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

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

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

5.5.3 Ограничения Sametime при использовании обратных прокси-серверов

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

Ограничения клиента и потребности в JVM

Не все клиенты Sametime могут взаимодействовать с серверами Sametime через обратный прокси-сервер. Поддерживаются следующие клиенты:

  • Клиенты Sametime Meeting Room и Sametime Broadcast.

    Клиент Sametime Meeting Room и клиент Sametime Broadcast могут взаимодействовать с сервером Sametime через обратный прокси-сервер в том случае, когда запущены следующие Web-браузеры и виртуальные Java-машины [Java Virtual Machines (JVM)]:

    • браузер IE 6 + MS VM или Sun Microsystems JVM 1.4.1 + Java Plug-In;
    • Netscape + Sun Microsystems JVM 1.4.1 (и связанный с нею Java Plug-In).
  • Клиент Sametime Connect для браузеров (Java-версия Sametime Connect) и приложения Sametime Links, скомпонованные с инструментариями разработчика Sametime.

    Клиент Sametime Connect для браузеров и приложения Sametime Links могут взаимодействовать с сервером Sametime через обратный прокси-сервер в том случае, когда запущены браузеры Explorer 6 или Netscape 7, которые работают с Sun Microsystems JVM 1.4.1.

    Клиент Sametime Connect для браузеров и приложения Sametime Links могут не функционировать соответствующим образом с другими виртуальными Java-машинами, включая предусмотренную для Internet Explorer собственную виртуальную машину Microsoft.

Ограничение. Sametime Connect для клиента рабочего стола (Microsoft Windows-версия Sametime Connect) не может использоваться с сервером Sametime, который размещен за обратным прокси-сервером.

Ограничения сервера

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

  • Недоступно аудио/видео. Аудио/видео-потоки не могут быть переданы к клиентам Sametime, которые осуществляют доступ к серверу Sametime через обратный прокси-сервер.
  • Недоступны базы данных TeamRoom и Discussion. Пользователь, который соединяется с сервером Sametime через обратный прокси-сервер, не может использовать на сервере Sametime базы данных TeamRoom и Discussion.
  • Невозможен доступ к Sametime Administration Tool. Пользователь, который соединяется с сервером Sametime через обратный прокси-сервер, не может получить доступ к инструменту Sametime Administration Tool. Для доступа к Sametime Administration Tool пользователь может открыть установленный на сервере Sametime Web-браузер. Для доступа к Sametime Administration Tool пользователь может также соединиться с сервером Sametime с рабочего места во внутренней сети, с которого не осуществляется маршрутизация HTTP-трафика через обратный прокси-сервер.
  • Ограничения для сервера Sametime Enterprise Meeting Server. Сервер Sametime 1.0 Enterprise Meeting Server, который работает с серверами Sametime 3.1, не может быть размещен за обратным прокси-сервером.
5.5.4 SSL, анализ и проблемы сертификации клиента

Для шифрования передаваемых между клиентами Sametime и обратным прокси-сервером данных может использоваться протокол защищенных сокетов [Secure Sockets Layer (SSL)]. Однако SSL не может использоваться для шифрования данных, передаваемых между серверами Sametime и обратным прокси-сервером. Соответственно соединение между обратным прокси и сервером Sametime должно быть безопасным.

Совет. Если для шифрования передаваемых между Web-браузерами и обратным прокси-сервером данных используется SSL, на сервере Sametime администратор должен осуществить конфигурацию преобразования адресов, необходимую для преобразования получаемых от Web-браузера данных HTTPS в требуемые сервером Sametime данные HTTP.

Когда SSL используется в среде обратного прокси с Sametime, многие из выполняемых Sametime функций будут запускаться в плагине Java Plug-in Web-браузера (клиент соединения, клиент совещаний и т. д.). Этот Java Plug-in должен распознавать используемые обратным прокси-сертификаты SSL, исходя из чего он сможет взаимодействовать через SSL.

Сертификатами, которые, возможно, потребуется распознавать Java Plug-in, являются следующие.

Сертификаты подписчика

Когда обратный прокси-сервер сконфигурирован на поддержку SSL, во время подтверждения установления SSL-соединения ("рукопожатия" – handshake) он отправляет Web-браузеру сертификат SSL сервера. Используемый Web-браузером Java 1.4.1 Plug-in должен иметь доступ к сертификату подписчика (Signer certificate), который подписан тем же источником сертификации (Certificate Authority (CA)), что и высланный обратным прокси сертификат сервера.

По умолчанию Java Plug-in имеет доступ к нескольким различным сертификатам подписчика, которые могут быть использованы для этой цели. Для просмотра доступных модулю Java Plug-in 1.4.1 сертификатов подписчика используйте панель управления Java Plug-in следующим образом:

  1. С рабочего стола Windows откройте панель управления [Start (Пуск) – Settings (Настройка) – Control Panel (Панель управления)].
  2. Щелкните два раза мышью на иконке Java Plug-in 1.4.1 для открытия панели управления Java Plug-in.
  3. Щелкните мышью на закладке Certificates (Сертификаты).
  4. Выберите переключатель Signer CA (Источник сертификации подписчика).

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

Проблемы аутентификации сертификата клиента

Если конфигурация обратного прокси-сервера требует аутентификации сертификата клиента, то этот сертификат для отдельного пользователя должен быть импортирован в панель управления Java Plug-in 1.4.1 на машине данного пользователя. Для импортирования сертификата клиента в хранилище ключей Java Plug-in вы можете использовать закладку Certificates (Сертификаты) панели управления Java Plug-in.

К примеру:

  1. С рабочего стола Windows машины пользователя откройте панель управления[Start (Пуск) – Settings (Настройка) – Control Panel (Панель управления)].
  2. Щелкните два раза мышью на иконке Java Plug-in 1.4.1 для открытия панели управления Java Plug-in.
  3. Щелкните мышью на закладке Certificates (Сертификаты).
  4. В графе Certificates (Сертификаты) выберите Secure Site (Безопасный сайт).
  5. Щелкните мышью на кнопке Import (Импорт) для импортирования сертификата клиента.
5.5.5 Правила преобразования адресов на обратном прокси-сервере в целях поддержки Sametime

Когда сервер Sametime расположен за обратным прокси-сервером, администратор должен сконфигурировать на обратном прокси-сервере правила преобразования адресов.

Эти правила преобразования адресов позволяют прокси-серверу преобразовывать (или переписывать) URL-адреса, связанные с обратным прокси-сервером, в URL-адреса внутреннего сервера Sametime.

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

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

В этом разделе предусмотрены некоторые рекомендации на тему того, как на обратном прокси-сервере сконфигурировать правила преобразования адресов для выполнения преобразования (или переписывания) URL-адресов в случае совместной работы обратного прокси и Sametime.

Рассмотрение псевдонима и множество серверов

Любой обратный прокси-сервер, который работает с сервером Sametime, должен поддерживать в URL-адресах идентификатор схожести ( affinity-i d) (или псевдоним сервера).

К примеру, если входящим URL-адресом от Web-сервера является

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

то правила преобразования адресов обратного прокси-сервера преобразуют родственный id "st01" в сервер Sametime, именуемый "sametime.ibm.com", а родственный id обеспечивает переписывание обратным прокси-сервером входящего URL-адреса в адрес следующего вида:

http[s]://sametime.ibm.com/stcenter.nsf

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

http[s]://sametime2.ibm.com/* /st02/*
http[s]://sametime1.ibm.com/* /st01/*
Использование шаблонов для упрощения преобразования адресов пользовательского интерфейса Sametime

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

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

http[s]://reverseproxy.ibm.com/st01/*

будет преобразовываться в такой URL-адрес сервера Sametime:

http[s]://sametime.ibm.com/*

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

Четыре типа преобразования адресов, требуемые для трех серверов с Java-апплетами

При создании правил преобразования URL-адресов с целью разрешения клиентам Java-апплетов Sametime работать в Web-браузере пользователя должна быть обеспечена поддержка соединения со службами Community Services, Meeting Services, Broadcast Services на сервере Sametime. Фактически для этих трех служб требуется четыре правила преобразования адресов: два для Community Services, одно для Meeting Services и одно для Broadcast Services.

Пример преобразования адресов для служб Community Services

Этот пример отображает конфигурацию преобразования адресов, которая позволит клиенту Java-апплета соединяться со службами Community Services.

Если входящими URL-адресами от Java-апплета являются

http[s]://proxy.ibm.com/st01/communityCBR/
http[s]://proxy.ibm.com/st01/CommunityCBR/

то правила преобразования адресов на обратном прокси должны преобразовать эти URL-адреса в следующий вид:

http://sametime.ibm.com:8082/communityCBR
http://sametime.ibm.com:8082/CommunityCBR

Совет. Конфигурация преобразования адресов для соединений со службами Community Services должна содержать два чувствительных к регистру правила, как было отображено выше. Некоторые фрагменты Java-кода в "communityCBR" содержат "с" нижнего регистра, в других фрагментах Java-кода в "CommunityCBR" используется "С" верхнего регистра. Если прокси является чувствительным к регистру, это различие может препятствовать установлению соединений.

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