- Как пользоваться списком CyberNOT List
- Функция Log Rule Hit
- Что хранится в кэше?
- Технология второго поколения
- Туннелирование сквозь "вражескую" территорию
- Главный и подчиненный
- Экстренная верификация
- Сохранение информации на подчиненном сервере
- Тс-с! Это секрет
Конфигурирование Web-браузеров
Просматривая рекламные материалы компании, клиенты ожидают увидеть не только ее телефонный номер, но и адрес ее Web-узла. Стремясь оправдать эти ожидания, организации всеми силами стремятся подключить свои корпоративные сети и интрасети к Internet - даже несмотря на то, что при этом они получают немало дополнительных забот и серьезных оснований для беспокойства. Это, прежде всего, вызвано фундаментальными отличиями корпоративных сетей и интрасетей от Internet. Если корпоративные сети являются защищенными, управляемыми и надежными, то Internet, наоборот - незащищенная, неуправляемая и весьма ненадежная сеть. Это несоответствие и становится источником многих проблем (особенно в области безопасности, управления и производительности), возникающих на границе сети - в том месте, где корпоративная сеть или интрасеть стыкуется с Internet.
Большинство существующих "пограничных" систем решают только одну из указанных проблем. Например, брандмауэры обеспечивают защиту, но неспособны повысить производительность Internet-соединения. Аналогично, высокоскоростные маршрутизаторы повышают производительность, но не на многое способны в отношении сетевой безопасности; они обеспечивают функции фильтрации пакетов, которые трудно правильно настроить. В случае их неточной настройки ваша интрасеть может стать еще более уязвимой, чем ранее. Еще хуже то, что каждое "пограничное" решение имеет свое собственное управляющее ПО, поэтому управление ими довольно утомительно и отнимает много времени. Короче говоря, для того чтобы обеспечить полноценное "пограничное" решение, вы должны приобретать, устанавливать и администрировать несколько самостоятельных продуктов.
Компания Novell решила упростить решение этой задачи, выпустив собственное пограничное решение в виде программного пакета, объединившего в себе возможности нескольких продуктов и получившего название BorderManager. Он состоит из ряда загружаемых модулей NetWare (NLM), которые решают проблемы защиты, производительности и управления соединением с Internet на границе корпоративной сети. И поскольку BorderManager полностью интегрирован со службой каталога Novell Directory Services (NDS), вы способны управлять всеми его функциями с помощью одной утилиты: в состав продукта входит подключаемый (snap-in) модуль для графической утилиты NetWare Administrator (NWADMIN) - стандартного средства администрирования сетей IntranetWare и NetWare 4.1x. Благодаря этому модулю утилиту NWADMIN можно использовать для конфигурирования правил, по которым "пограничный" сервер будет фильтровать трафик между вашей интрасетью и Internet на основе IP-адресов источника и адресата, номеров портов источника и адресата, адресов URL и времени суток. Утилита NWADMIN также позволяет просматривать журнальные файлы контроля доступа, конфигурировать иерархическую систему кэширования, повышающую скорость доступа к информации World Wide Web (WWW), а также создавать виртуальные частные сети (virtual private network - VPN). Таким образом, для решения многих проблем, возникающих на границе сети, достаточно приобрести и установить всего один продукт - BorderManager компании Novell.
Когда компания решается подключить свою корпоративную сеть к Internet, наибольшее беспокойство у нее обычно вызывают вопросы защиты данных. Как же обезопасить свою сеть? Чаще всего для решения этой задачи весь трафик, пересекающий границу сети, направляется через единую точку, в которой он "просеивается" путем фильтрации пакетов и слежения за протоколами квитирования связи - от сетевого до прикладного уровня модели OSI (Open Systems Interconnection - взаимодействие открытых систем). Чем выше уровень, на котором осуществляется фильтрация пакетов, тем выше уровень защиты, обеспечиваемый системой.
BorderManager позволяет создать единую точку на границе сети, через которую проходит весь трафик. Он также дает возможность фильтровать пакеты от сетевого уровня модели OSI (для всех входящих и исходящих пакетов, независимо от используемого протокола) до прикладного уровня (только для пакетов HTTP). Для фильтрации трафика, поступающего из Internet и в нее, BorderManager использует следующие компоненты:
NetWare MPR
Являясь программным маршрутизатором с возможностями фильтрации пакетов, NetWare MPR выступает в качестве первой линии обороны вашей сети. С помощью FILTCFG.NLM (DOS-утилиты, работающей в режиме командной строки) можно сконфигурировать NetWare MPR для фильтрации входящих и исходящих пакетов на основе IP-адресов источника и получателя пакета, номеров портов источника и получателя пакета, используемого протокола. NetWare MPR извлекает эту информацию из заголовка TCP/IP каждого пакета и на основе заданных вами правил фильтрации решает, пропускать данный пакет или нет.
NetWare MPR конфигурируется для фильтрации пакетов вплоть до прикладного уровня модели OSI, однако чем выше уровень, тем сложнее должны быть соответствующие правила фильтрации, а соответственно, сложнее процесс конфигурирования NetWare MPR. К счастью, в состав BorderManager входят шлюзы сеансового уровня и посредник HTTP, которые способны фильтровать трафик на более высоких уровнях модели OSI. Для конфигурирования этих компонентов пограничных служб Novell можно использовать хорошо знакомую сетевым администраторам утилиту NWADMIN.
Шлюзы сеансового уровня
Если вы сконфигурируете Web-браузеры на клиентских машинах для доступа к серверу пограничных служб, то сможете задать правила фильтрации для управления доступом пользователей в Internet через шлюз IP/IP или IPX/IP (процесс настройки браузеров для работы с сервером пограничных служб кратко описан во врезке "Конфигурирование Web-браузеров"). Шлюз IPX/IP осуществляет преобразование протоколов для IPX-клиентов, которое обеспечивает им доступ в Internet и исключает необходимость в установке стека протоколов TCP/IP на клиентских машинах и серверов интрасети, работающих по протоколу TCP/IP. Для того чтобы применять шлюз IPX/IP, IPX-клиенты должны также использовать новую версию библиотеки WINSOCK.DLL, специально усовершенствованную для работы с пограничными службами.
В дополнение к преобразованию протоколов шлюз IPX/IP устанавливает соединение с Internet от имени пользователя, обеспечивая отсутствие прямого контакта между хостом в Internet и клиентом. Шлюз IP/IP выполняет аналогичные функции для IP-клиентов. Поскольку соединение с Internet устанавливает шлюз, а не клиент, все проходящие через него пакеты выглядят для внешнего мира так, как будто они исходят от шлюза, а не от клиента, что защищает клиентов внутренней сети от внешних хостов (BorderManager также включает в себя компоненты, которые обеспечивают преобразование IP-адресов. Читайте об этом во врезке "Прячься!").
Скрытие реальных IP-адресов клиентов является весьма полезной, но не главной функцией, выполняемой шлюзами. Их главная цель - дать вам возможность управлять доступом пользователей к TCP/IP-хостам интрасети или Internet. Шлюзы IP/IP и IPX/IP принимают запрос клиента на установление соединения с хостом интрасети или Internet, проверяют, разрешено ли пользователю устанавливать запрашиваемое соединение, и (если разрешено) устанавливает его. Шлюзы выполняют проверку разрешенности соединения на основе той информации, которую вы задаете с помощью утилиты NWADMIN.
Чтобы настроить правила исходящего доступа для шлюзов (и посредника HTTP), надо выполнить следующие простые операции.
1 Запустить утилиту NWADMIN и дважды щелкнуть мышью на объекте Border Server в дереве NDS.
2 В окне Border Services Setup ("Настройка пограничных служб") щелкнуть по кнопке Outgoing Rules ("Правила исходящего доступа").
3 В окне Outgoing Rules отображается список правил, которые уже заданы. Чтобы добавить новое правило, щелкните по кнопке Add ("Добавить") в левой части поля Rules ("Правила").
4 В окне Rule Definition ("Задание правил") можно создать новое правило, заполнив все или некоторые поля.
Настройка правил управления доступом
В противоположность настройке правил фильтрации пакетов для маршрутизаторов, настройка правил для шлюзов сеансового уровня компании Novell является относительно простой процедурой. Предположим, что вы хотите задать правило, по которому пользователи, входящие в группу Everyone, не смогут получить доступ к узлам FTP с 8 утра до 6 вечера с понедельника по пятницу. Чтобы создать это правило, необходимо вызвать окно Rule Definition ("Задание правила") в утилите NWADMIN и выбрать опцию Deny ("Запретить") в поле Action ("Действие").
Затем в поле Source ("Источник") нужно выбрать опцию Specified ("Заданный") и щелкнуть мышью по кнопке "...". Кроме других функций, эта кнопка позволяет задать IP-адрес источника, выбирая в дереве NDS объекты типа User (пользователь) или Group (группа). Потом вы должны с помощью мыши выделить нужный временной интервал (с 8 утра до 6 вечера с понедельника по пятницу) в поле Time Constraint ("Ограничение по времени"). И наконец, выбрав пункт Protocol в поле Access Specification, нужно выбрать FTP. Выполнив эти простые операции, вы создадите новое правило.
Как отрабатываются правила
Когда Фред (член группы Everyone) в следующий раз подключится к сети и попытается установить соединение с FTP-сервером в интервале с 8 утра до 6 вечера, произойдут следующие события. Фред вводит в своем Web-браузере адрес URL, включающий в себя имя хоста, к которому он хочет получить доступ. Браузер осуществляет запрос к усовершенствованному файлу WINSOCK.DLL, находящемуся на компьютере Фреда, чтобы определить IP-адрес запрашиваемого FTP-сервера. Файл WINSOCK.DLL передает запрос браузера шлюзу IPX/IP, работающему на сервере пограничных служб, который по имени хоста определяет IP-адрес (например, 130.57.2.6) и возвращает его клиентской системе Фреда. Полученный IP-адрес передается браузеру, который запрашивает у WINSOCK.DLL установление соединения через FTP-порт по адресу 130.57.2.6. После этого WINSOCK.DLL обращается к серверу пограничных служб, на котором работает шлюз IPX/IP, и просит шлюз установить соединение по адресу 130.57.2.6. Шлюз обращается к NDS, чтобы проверить, авторизован ли Фред на установление такого соединения. Поскольку Фред является членом группы Everyone, а следовательно, ему запрещен доступ к FTP-узлам с 8:00 до 18:00 с понедельника по пятницу, шлюз игнорирует запрос Фреда.
Шлюзы сеансового уровня применяют заданные правила ограничения доступа в момент передачи запроса на установление соединения, однако когда соединение установлено, шлюзы не выполняют никакой фильтрации пакетов. Например, если Фред подождет до 18:05 и запросит соединение с FTP-узлом, шлюз установит соединение, после чего Фред будет беспрепятственно загружать с этого узла любые файлы. Шлюзы не ограничивают возможностей загрузки файлов. Данную функцию можно реализовать с помощью посредника HTTP.
Посредник HTTP
Посредник HTTP позволяет задавать правила фильтрации пакетов, которые начинают действовать после того, как шлюз сеансового уровня установил соединение между клиентом и хостом интрасети или Internet. Посредник HTTP проверяет адрес URL, который вводит пользователь, и на основе правил, настроенных с помощью утилиты NWADMIN, разрешает или запрещает доступ к хосту, ассоциированному с данным URL. Для принятия решения о том, разрешать или запрещать прохождение пакетов, шлюзы сеансового уровня и посредник HTTP "консультируются" у NDS.
Предположим, что требуется создать правило, аналогичное использованному в предыдущем примере: вы хотите ограничить доступ ко всем Web-узлам, содержащим порнографические материалы, с 8 утра до 6 вечера с понедельника по пятницу. Чтобы создать такое правило, нужно выполнить примерно те же операции, что и в первом примере. Исключением является необходимость выбора опции URL в поле Access Specification на экране Rule Definition. Эта опция позволяет задавать полные адреса URL, имена доменов внутри этих URL или категории URL, к которым вы хотите ограничить доступ. В данном случае вы должны выбрать категории адресов URL из списка CyberNOT List компании Microsystems.
Как пользоваться списком CyberNOT List
В списке CyberNOT List Web-узлы классифицированы в соответствии с типом содержащихся в них материалов - многие руководители не хотят, чтобы их сотрудники имели в рабочее время доступ к определенной информации, например расистского или милитаристского характера.
При установке BorderManager в NDS загружается файл, содержащий сокращенную версию списка CyberNOT List, составленного компанией Microsystems. Во время установки вы также можете запустить программу, позволяющую зарегистрировать вашу копию списка в Microsystems. В этом случае компания Microsystems предоставит вам ключ, который откроет доступ к полной версии данного списка и даст возможность серверу пограничных служб периодически обращаться к исходной базе данных компании Microsystems, автоматически обновляя вашу копию.
Чтобы задать правило, ограничивающее доступ пользователей к Web-узлам, содержащим порнографические материалы, нужно выбрать соответствующие категории в списке CyberNOT List. После этого посредник HTTP будет сравнивать введенный пользователем адрес URL с адресами из списка CyberNOT List. Если обнаружится, что полный адрес URL или его часть соответствует шаблону, содержащемуся в базе данных CyberNOT, посредник HTTP пошлет сообщение Web-браузеру пользователя, указывающее, что доступ к данному URL запрещен. Создав правило, вы должны нажать кнопку OK. На экране вновь появится окно Outgoing Rules, отображающее все заданные вами правила исходящего доступа.
Функция Log Rule Hit
В дополнение к настройке правил в окне Rule Definition утилиты NWADMIN вы можете активизировать функцию Log Rule Hit. Она позволяет просматривать журнал регистрации доступа, в котором фиксируется весь трафик, обработанный шлюзами сеансового уровня и посредником HTTP за указанный вами интервал времени. В журнале регистрации доступа отображается информация о каждом переданном пакете: дата и время его прохождения через шлюз или посредник, был ли пакет принят или отвергнут, IP-адрес сети или пользователя интрасети, адрес URL, заданный этим пользователем, и протокол, который применялся при передаче пакета. Если выделить соответствующий элемент в журнале регистрации, то будет также отображаться правило, использованное шлюзом или посредником для принятия решения о том, можно ли пропускать данный пакет.
Что хранится в кэше?
Посредник HTTP не только увеличивает степень защищенности сети, но и повышает производительность, кэшируя Web-файлы, к которым часто обращаются пользователи. Когда вновь запрашивается один из кэшированных файлов, посредник HTTP передает Web-браузеру пользователя файл из своего кэша, не обращаясь на тот Web-узел, с которого изначально был получен данный файл. Утилита NWADMIN позволяет сконфигурировать посредник HTTP таким образом, чтобы он выполнял один или оба возможных вида кэширования:
Пассивное кэширование. Если Web-браузер пользователя был настроен для применения посредника HTTP, то пассивное кэширование ускоряет доступ пользователей к файлам на Web-серверах (см. врезку "Конфигурирование Web-браузеров"). При таком кэшировании браузер не взаимодействует с Web-сервером напрямую, вместо этого он посылает запросы пользователя посреднику HTTP. Посредник, в свою очередь, связывается с соответствующим сервером HTTP, FTP или Gopher, извлекает оттуда запрошенный файл (если его нет в кэше), сохраняет его копию в своем кэше (предполагается, что файл допускает кэширование) и передает его Web-браузеру. (Во врезке "Предпочитаете кэш?" описано, как посредник HTTP решает, какие файлы можно кэшировать.)
Чтобы включить функцию пассивного кэширования, нужно выполнить следующие простые операции.
1 Запустить программу NWADMIN и дважды щелкнуть мышью на объекте Border Server в дереве NDS.
2 В окне Border Services Setup выбрать опцию Proxy Cache Services, а затем нажать на кнопку Web Proxy Cache.
3 В окне Web Proxy Cache выбрать опцию Enable HTTP Proxy и ввести номер порта (обычно 8080), который сервер пограничных служб использует для пакетов HTTP, исходящих из интрасети.
После этого посредник HTTP начинает выполнять пассивное кэширование, выступая в качестве сервера по отношению к Web-браузеру пользователя и в качестве клиента - по отношению к удаленному Web-серверу. Если браузер пользователя настроен на применение посредника HTTP, то каждый раз, когда запрашивается файл с удаленного Web-сервера, возникает следующая цепочка событий.
Посредник HTTP принимает запрос на передачу файла и проверяет его наличие в своем кэше. Если файл хранится в кэше, посредник передает его браузеру - не занимая полосы пропускания интрасети или Internet-соединения для извлечения файла с Web-сервера, на котором он хранится. Если же запрошенный файл отсутствует в кэше, посредник HTTP может запросить его у других кэш-серверов интрасети (при условии, что посредник был настроен на выполнение этой функции).
Можно сконфигурировать кэш-посредник таким образом, чтобы он являлся частью иерархической системы кэширования. Выбрав опцию Advanced в окне Web Proxy Cache утилиты NWADMIN, вы способны связать данный кэш-посредник с кэш-посредником других локальных серверов. Если запрошенный файл хранится в кэше одного из этих локальных серверов, посредник HTTP извлекает его и пересылает браузеру. Когда запрошенный файл хранится в кэшах сразу нескольких серверов, посредник извлекает его из кэша ближайшего локального сервера (находящегося на расстоянии наименьшего количества "пролетов" интрасети) и пересылает браузеру. Если запрошенный файл отсутствует в кэшах всех локальных серверов, посредник HTTP извлекает его с базового удаленного сервера, сохраняет копию файла в кэше и передает его браузеру. Таким образом, посредник уменьшает количество запросов к Web-серверам, передаваемых по каналам интрасети или Internet-соединения, снижая нагрузку на них и повышая скорость доступа пользователей к Web-файлам.
При обратном кэшировании посредник HTTP сохраняет в кэше копии файлов, находящихся на локальных Web-серверах. Когда браузер пользователя, подключенного к интрасети через Internet, запрашивает файл, хранящийся на одном из таких серверов, посредник извлекает этот файл из своего кэша. Таким образом посредник защищает ваши локальные Web-серверы от Internet и сберегает полосу пропускания интрасети, уменьшая количество передаваемых через нее запросов.
Чтобы включить функцию обратного кэширования, нужно выполнить следующие действия.
1 Запустить программу NWADMIN и дважды щелкнуть мышью на объекте Border Server в дереве NDS.
2 Выбрать опцию Proxy Cache Services в окне Border Services Setup, а затем нажать на кнопку Web Proxy Cache.
3 В окне Web Proxy Cache выбрать опцию Enable HTTP Accelerator.
Если включена функция ускорения HTTP, посредник HTTP выступает в качестве клиента по отношению к локальному Web-серверу и в качестве сервера - по отношению к Web-браузеру в Internet. Когда браузер пользователя, подключенного к интрасети через Internet, запрашивает файл, хранящийся на одном из локальных Web-серверов, происходят такие события: получив запрос на передачу файла, посредник HTTP проверяет его наличие в кэше; если файл находится в кэше, посредник передает его браузеру без обращения к локальному Web-серверу; если же файл отсутствует, он извлекается из локального Web-сервера и лишь затем передается браузеру.
Технология второго поколения
Хотя BorderManager является новым продуктом компании Novell, его кэш-посредник основан на проверенной технологии - архитектуре Harvest Web Proxy Cache, совместно разработанной университетами шт. Колорадо и Южная Каролина, а затем переименованной Национальной лабораторией передовых сетевых исследований (National Laboratory for Advanced Network Research) в Squid. Это технология второго поколения, превосходящая по своим возможностям технологию первого поколения CERN (разработана Европейской лабораторией ядерной физики), на которой базируется Squid. Отделы компьютерных исследований университетов шт. Колорадо и Южная Каролина сообщают, что благодаря Squid скорость доступа к данным в Internet увеличивается в 4-10 раз (по сравнению со скоростью прямого доступа из браузера). Кэш-посредник компании Novell является реализацией UNIX-технологии Squid на платформе IntranetWare и обеспечивает такое же повышение производительности.
Пограничные коммуникации
Кроме обеспечения защиты и повышения производительности BorderManager позволяет решать коммуникационные задачи. Как уже было сказано, с помощью NetWare MPR сеть на базе IPX подключается к основанной на IP сети Internet. Кроме того, BorderManager включает в себя NetWare Connect, служащий серверной коммуникационной платформой. NetWare Connect дает возможность удаленным пользователям подключаться и получать доступ к интрасети из Internet, а локальным пользователям - подключаться к Internet через модемный пул.
Туннелирование сквозь "вражескую" территорию
BorderManager разрешает и более сложные коммуникационные проблемы. Это ПО включает в себя средства организации виртуальных частных сетей (virtual private network - VPN). Все передаваемые по такой сети данные шифруются, что обеспечивает защищенное и экономичное подключение филиалов компании к ее центральному офису. VPN - это секретный туннель, проложенный сквозь "вражескую" территорию. Проходящая по нему информация остается невидимой для всех пользователей, кроме авторизованных.
Как работает VPN, созданная с помощью ПО BorderManager? Предположим, вы хотите создать VPN, работающую через Internet, которая соединит расположенный в Калифорнии центральный офис компании с ее филиалом в Айове. Прежде всего, нужно зарегистрироваться у провайдера услуг Internet и сконфигурировать серверы BorderManager в Калифорнии (CA-MC) и Айове (IA-MC) для подключения к Internet. После того как вы соединили офисы, CA-MC и IA-MC должны получить друг от друга информацию, необходимую им для обмена данными через туннель VPN. Они должны знать "публичные" адреса друг друга и общий секретный ключ, или "секрет", который будет описан ниже.
Главный и подчиненный
CA-MC и IA-MC собирают нужную им информацию во время процесса конфигурирования VPN. Он начинается с того, что вы должны решить, какой сервер BorderManager будет являться главным участником (master member) вашей VPN, а какой - подчиненным (slave member). В принципе, эти серверы мало чем различаются, но главный участник отвечает за выполнение ряда ключевых функций, например за синхронизацию участников VPN и выбор параметров, которые будут использоваться для формирования общего "секрета". В частности, главный сервер задает параметры алгоритма Диффи-Хельмана (Diffie-Hellman), используемого для генерации открытых (public) и частных (private) ключей Диффи-Хельмана, из которых создается общий "секрет". (Diffie-Hellman - алгоритм шифрования с открытым ключом, названный в честь предложивших его Витфильда Диффи и Мартина Хельмана). Функцию главного участника VPN, как правило, выполняет сервер пограничных служб, расположенный в центральном офисе.
Выбрав главный сервер, можно приступать к конфигурированию VPN. В данном случае процесс конфигурирования начинается с запуска программы VPNCFG.NLM на сервере CA-MC. В процессе конфигурирования CA-MC собирает или генерирует следующую информацию:
IP-адрес. VPNCFG.NLM попросит вас задать "публичный" IP-адрес сервера CA-MC, по которому любой пользователь Internet сможет связаться с сервером пограничных служб (только официально зарегистрированный IP-адрес). Вам также придется ввести IP-адрес, ассоциированный с туннелем VPN. Это не обязательно должен быть зарегистрированный IP-адрес; можно назначить произвольный IP-адрес и использовать одинаковый номер подсети (subnet) для всех участников VPN. Например, применяя номер подсети 130.57.1.x, вы можете в качестве IP-адресов туннеля VPN назначить серверу CA-MC адрес 130.57.1.1, а серверу IA-MC - 130.57.1.2.
Пара ключей RSA. CA-MC должен создать цифровую сигнатуру и подписывать ею все данные, пересылаемые в IA-MC. IA-MC будет проверять сигнатуру, чтобы убедиться в том, что данные поступили от сервера CA-MC и не были модифицированы в процессе передачи. Для этой цели CA-MC генерирует пару ключей RSA (открытый и частный) и экстренным образом передает открытый ключ серверу IA-MC (экстренная передача описана в следующем разделе.). Теперь IA-MC будет применять открытый ключ RSA, сгенерированный сервером CA-MC, для аутентификации информации, получаемой от CA-MC.
Параметры и ключи Диффи-Хельмана. Сервер CA-MC генерирует параметры, которые затем будут им использоваться для генерации открытого и частного ключей Диффи-Хельмана, необходимых для создания общего "секрета". CA-MC сохраняет частный ключ Диффи-Хельмана, а открытый ключ и параметры Диффи-Хельмана передает на сервер IA-MC.
Экстренная верификация
Итак, администратор сервера IA-MC получил по электронной почте или на дискете (переданной, например, обычной почтой) следующую информацию:
Чтобы обеспечить безопасную передачу этой информации администратору сервера IA-MC, CA-MC генерирует дайджест, или резюме, сообщения. Дайджест представляет собой строку шестнадцатиричных чисел длиной 16 байт, которая содержит сводку информации, сгенерированной главным сервером в процессе конфигурирования. Дайджест сообщения используется для экстренной верификации администратором подчиненного сервера, который получает сообщение электронной почты или дискету от администратора главного сервера.
В нашем примере администратор сервера IA-MC, получив дискету, запускает утилиту VPNCFG.NLM и в ответ на ее запрос идентифицирует IA-MC как подчиненный сервер. Затем эта утилита просит администратора IA-MC проверить достоверность полученной дискеты. Чтобы убедиться в том, что дискета поступила действительно от CA-MC и ее содержимое не было модифицировано по дороге, администратор IA-MC звонит администратору CA-MC и зачитывает вслух дайджест сообщения. Если дайджест полученного сообщения соответствует тому, который был отправлен, дискета является достоверной и администратор IA-MC может продолжить процесс конфигурирования.
Сохранение информации на подчиненном сервере
Чтобы продолжить процесс конфигурирования, IA-MC сохраняет полученный от CA-MC открытый ключ RSA и в дальнейшем использует его для проверки подлинности цифровой сигнатуры CA-MC. IA-MC применяет полученные от CA-MC параметры Диффи-Хельмана и для генерации своих собственных открытого и частного ключей Диффи-Хельмана. Затем IA-MC сохраняет собственный частный ключ Диффи-Хельмана и записывает свой открытый ключ Диффи-Хельмана вместе с "публичным" IP-адресом сервера IA-MC на дискету, которую ее администратор посылает администратору сервера CA-MC. Чтобы обеспечить безопасную доставку этой дискеты, IA-MC также генерирует дайджест сообщения.
Когда вы, как администратор CA-MC, получаете эту дискету, то запускаете утилиту NWADMIN и выбираете объект Border Server в дереве NDS. Затем нажимаете на кнопку VPN, чтобы вызвать окно VPN Member ("Участник VPN"), в котором определяете IA-MC как участника VPN. Утилита NWADMIN первым делом попросит вас проверить достоверность полученной дискеты. Чтобы убедиться в том, что дискета получена действительно от IA-MC и что ее содержимое не было модифицировано, вы звоните администратору IA-MC и зачитываете вслух дайджест сообщения. Если полученный вами дайджест сообщения соответствует отправленному, то дискета является достоверной и вы можете продолжить процесс конфигурирования.
Затем CA-MC сохраняет публичный IP-адрес сервера IA-MC и его открытый ключ Диффи-Хельмана в главной конфигурационной таблице (master configuration table). После этого вы должны активизировать команду Resynchronize (ресинхронизация) в утилите NWADMIN, чтобы послать главную конфигурационную таблицу (подписанную цифровой сигнатурой сервера CA-MC) всем участникам VPN (в данном случае - только серверу IA-MC). Оба сервера - CA-MC и IA-MC - хранят свои собственные частные ключи Диффи-Хельмана и имеют доступ к "публичным" IP-адресам друг друга и открытым ключам Диффи-Хельмана через главную конфигурационную таблицу.
Тс-с! Это секрет
В конце концов участники VPN получили информацию, необходимую им для создания общего "секрета": CA-MC использует для этого свой частный ключ Диффи-Хельмана и открытый ключ Диффи-Хельмана сервера IA-MC, а IA-MC - свой частный ключ Диффи-Хельмана и открытый ключ Диффи-Хельмана сервера CA-MC. Сформировав общий "секрет", CA-MC и IA-MC могут обмениваться данными по туннелю VPN. Когда сервер CA-MC собирается посылать данные, он случайным образом генерирует ключ и шифрует эти данные с его помощью. Для шифрования используется алгоритм RC2 с 128-битным ключом для ПО, поставляемого в США, или 40-битным ключом для ПО, продаваемого за пределами США. (Правительство США не разрешает экспортировать системы шифрования RC2 с длиной ключа более 40 бит.) Затем CA-MC шифрует сгенерированный произвольным образом ключ, используя общий "секрет". Получив данные, IA-MC использует общий "секрет" для дешифрования ключа, произвольно сгенерированного и зашифрованного сервером CA-MC, а затем с его помощью дешифрирует сами данные. И наконец, IA-MC посылает дешифрованные данные соответствующему узлу своей сети. В результате пакеты, исходящие из VPN, выглядят как обычные пакеты, передаваемые по сети.
* * *
Защищенная экономичная связь между центральным офисом компании и филиалами, кэширование часто используемых Web-файлов для повышения производительности, а также фильтрация пакетов на сетевом, сеансовом и прикладном уровнях модели OSI - все это обеспечивает ПО BorderManager компании Novell. Его компоненты (среди которых - NetWare MPR, шлюзы сеансового уровня, посредник HTTP, NetWare Connect и средство организации VPN) позволяют решить основные проблемы компаний, желающих подключить свою корпоративную сеть к Internet.
Кроме того, управление всеми компонентами BorderManager осуществляется с помощью единой стандартной утилиты NWADMIN. В отличие от других решений BorderManager имеет модульную архитектуру, которая обеспечивает возможность постепенного наращивания его возможностей. "В последующих версиях продукта, - говорит Кевин Роуз, менеджер по продуктам для Internet компании Novell, - вы увидите еще большее количество служб, работающих на границе сети".
Дополнительную информацию о продукте BorderManager можно получить на Web-сервере московского представительства Novell по адресу http://www.novell.ru или на центральном Web-узле компании по адресу http://www.novell.com/ear/products/newprods/border.html.
Статья подготовлена научным редактором журнала "Сети" Игорем Ковалерчиком по материалам журнала NetWare Connection (май/август 1997)
Конфигурирование Web-браузеров
Вы можете сконфигурировать клиентские Web-браузеры для доступа к узлам HTTP, FTP и Gopher через сервер BorderManager. Необходимые для этого операции зависят от применяемого браузера, однако в любом случае нужно задать адрес URL и номер порта (обычно 8080), которые браузер должен использовать для доступа к посреднику HTTP, являющемуся компонентом ПО BorderManager. Поясним, как осуществляется конфигурирование Web-браузеров, на конкретных примерах.
Конфигурирование браузера Netscape Navigator
1 Запустите Netscape Navigator и выберите в меню Options пункт Network. Затем выберите пункт Proxies.
2 Нажмите на кнопку View и заполните поля HTTP Proxy, FTP Proxy и Gopher Proxy, вводя URL-адрес посредника HTTP без префикса http://. Например, если полный адрес посредника http://wwwcache.company.com, то вы должны ввести в каждом из этих полей wwwcache.company.com.
3 В поле Port введите номер порта, который Web-браузер должен использовать для доступа к посреднику HTTP.
Конфигурирование браузера Microsoft Internet Explorer
1 Выделите пиктограмму Internet на рабочем столе Windows 95, нажмите правую кнопку и в появившемся меню выберите пункт Properties (в русской версии Windows 95 - "Свойства").
2 Выберите вкладку Connection ("Соединение"), а затем - опцию, соответствующую подключению через сервер-посредник.
3 Нажмите кнопку Settings ("Настройка") и заполните поля HTTP, FTP и Gopher, введя URL-адрес посредника без префикса http://. Затем вставьте двоеточие и за ним введите номер порта, который браузер должен использовать для доступа к посреднику HTTP. Например, если URL-адрес посредника http://wwwcache.company.com, а номер порта 8080, вы должны ввести в каждом из этих полей wwwcache.company.com:8080.
Прячься!
Если вы назначили клиентам вашей интрасети незарегистрированные IP-адреса, то при ее подключении к Internet у вас возникнут проблемы: работать в Internet могут только клиенты с зарегистрированными IP-адресами. Одно из возможных, хотя и очень болезненных, решений этой проблемы состоит в том, чтобы заменить IP-адреса всех клиентов на зарегистрированные, т.е. выделенные вам провайдером Internet. Значительно более удобным решением является использование преобразователя сетевых адресов (IP Network Address Translator - IP NAT), входящего в состав BorderManager.
IP NAT отображает все IP-адреса клиентов сети на один зарегистрированный IP-адрес. При этом можно не только подключать к Internet клиентов с незарегистрированными IP-адресами, но и "прятать" их от Internet: все пакеты, независимо от реальных IP-адресов их источников, выглядят для пользователей Internet так, словно они исходят из одного зарегистрированного IP-адреса. Шлюз IPX Address Mapping Gateway, который также входит в состав BorderManager, обеспечивает аналогичную возможность для IPX-клиентов: он отображает IPX-адреса клиентов внутренней сети на один зарегистрированный IPX-адрес. Это позволяет подключаться к глобальным сетям IPX, таким как AT&T WorldNet Intranet Connect Service (которая ранее называлась AT&T NetWare Connect Services), не назначая каждому клиенту нового IPX-адреса.
Предпочитаете кэш?
Посредник HTTP не выполняет кэширования файлов в одном из следующих случаев:
Задание некэшируемых файлов с помощью утилиты NWADMIN
1 Запустить утилиту NWADMIN и дважды щелкнуть мышью на объекте Border Server в дереве NDS.
2 В окне Border Services Setup выбрать опцию Proxy Cache Services и щелкнуть по кнопке Web Proxy Cache.
3 В окне Web Proxy Cache щелкнуть по кнопке Advanced и задать точные URL-адреса, подстроки в URL-адресах или IP-адреса доменов, ассоциированных с теми файлами, которые не должны храниться в кэше.
Можно задать как некэшируемые все файлы, ассоциированные с URL-адресами, которые связаны с программами, генерирующими динамические документы. Например, в качестве некэшируемых файлов заданы программы CGI (Common Gateway Interface), которые обычно идентифицируются в URL-адресе подстрокой "cgi-bin". Если пользователь введет в своем Web-браузере адрес http://www.xyz.com/cgi-bin, посредник HTTP не будет проверять кэш на наличие этого файла, а извлечет его непосредственно с базового Web-сервера.
Команды кэширования в HTTP 1.1
Кроме того, посредник HTTP не кэширует файлы, которые содержат специальную команду в заголовке HTTP, указывающую, что файл является некэшируемым. Каждый HTTP-запрос от браузера и каждый ответ от сервера состоит из начальной строки, одного или нескольких заголовков HTTP, пустой строки, обозначающей конец заголовков, и сообщения, содержащего основную информацию файла. Среди сотен возможных заголовков HTTP существуют специальные команды управления кэшированием, сообщающие кэш-посреднику, можно ли кэшировать сообщение (или его отдельные части). Команда запрещения кэширования указывает, что сообщение (либо его часть) не должно сохраняться в кэше.
Тэги TTL
Посредник HTTP также распознает заголовки HTTP, указывающие возраст файла. Эти заголовки позволяют определить, являются ли хранящиеся в кэше файлы актуальными. Например, файл может включать в себя заголовок Expires, задающий дату истечения срока действия данного файла. Если в заголовке Expires хранящегося в кэше файла указана дата 15.05.97, а пользователь запрашивает его 16.05.97, то посредник откажется от этого файла, извлечет его последнюю версию с базового Web-сервера и сохранит ее в кэше.
Некоторые заголовки HTTP содержат только дату последней модификации файла. В этом случае посредник присваивает файлу тэг TTL на основе информации, заданной вами с помощью утилиты NWADMIN. Например, вы можете сконфигурировать посредник таким образом, чтобы он назначал тэги TTL, прибавляя к дате извлечения файла половину времени, прошедшего с момента его последней модификации. Предположим, в соответствии с HTTP-заголовком файла последние изменения были внесены в него 1.05.97, а вы задали с помощью утилиты NWADMIN, что посредник HTTP должен назначать тэг TTL, прибавляя к дате извлечения файла половину времени, прошедшего с момента его последней модификации. Если посредник извлек файл 5.05.97 (т.е. с момента его модификации прошло четыре дня), он присвоит тэг TTL с датой 7.05.97, добавив к дате 5.05.97 два дня.
Посредник HTTP также назначает тэги TTL (на основе информации, которую вы задали в утилите NWADMIN) файлам, содержащим заголовки HTTP, в которых не указаны ни дата истечения срока действия, ни дата последней модификации. Кроме того, он присваивает тэги TTL файлам FTP и Gopher, для которых отсутствуют средства назначения этих параметров.