Site hosted by Angelfire.com: Build your free website today!
Перевод В.Тюльпа

logo.gif (1853 bytes)

Статья предполагает, что вы знакомы с: HTTP, WinSock, IIS

Преодолеваем ограничения Прокси сервера с Catapult
David Cook

Catapult обеспечивает прокси-обслуживание от локальной сети - не только для общих протоколов но и для любого чувствительного к WinSock приложения.


Многим в корпоративной среде нужен легкий доступ к Internet от их рабочих компьютеров, и эта свобода часто означает растущее беспокойство о безопасности для сетевых администраторов корпораций. Балансируя угрозу несанкционированного проникновения в дорогостоящую сеть с потребностью выполнять общие требования для доступа к Интернета, администратор сети оказался один на один с поистине сложной проблемой. Microsoft® Internet Proxy Server, так называемый Catapult (также упомянутый в этой статье как IPS), решает эту дилемму. Обеспечивая программно-аппаратные средства сетевой защиты для соединений HTTP, FTP, и Gopher между частной сетью и внешним миром, Catapult обеспечивает легкий внешний доступ при поддержании безопасной изоляции между внутренней корпоративной сетью и Internet. Входящие запросы приходяит на информационный сервер Internet(IIS), который имеет собственное управление безопасностью.

Основные принципы прокси-сервера

      Прокси-сервер обращается с запросами обслуживания к одному приложению от имени другого. Типично, прокси-серверы действуют как агенты для доступа к Internet из защищенной корпоративной сети. Приложение, подобное Web - броузеру, работает внутри корпоративной сети, может выдать запрос к прокси-серверу, который имеет прямой доступ в Internet. Прокси-сервер передает этот запрос в Internet, получает сообщения, возвращенные от узла назначения, и передает их обратно Web - броузеру на внутреннюю корпоративную сеть. Прокси-сервер таким образом обеспечивает однонаправленный доступ в Internet из корпорации, в то время как предотвращается доступ к корпоративной сети от Internet (см. Рисунок 1).

catapultfig01.gif (11671 bytes)
Рисунок 1: Архитектура Microsoft Internet Proxy Server
      Прокси-сервер реализует тип схемы управления защитой Internet, известный как программно-аппаратные средства защиты, который защищает одну сеть от другой недоверенной сети. Существующий метод использован, чтобы широко осуществлять программно-аппаратные средства защиты, но можно подумать, что это как пара механизмов: один блокирует движение, а другой разрешает движение.
      Программно-аппаратные средства защиты представляются в двух общих типах: фильтры пакетного уровня и шлюзы уровня приложения. Программно-аппаратные средства фильтрации пакетного уровня контролируют каждый сетевой пакет, проверяют адреса и номера портов, чтобы гарантировать, что поток обмена информацией санкционирован, и потом пропускают эти пакеты. Шлюз уровня приложения, в свою очередь, действует как прокси-машина для всех узлов в сети для всех входящих и исходящих информационных потоков Internet. Через ограничение и контроль доступа, можно управлять трафиком для всех основанных на TCP/IP приложений Internet, включая FTP, Gopher, и HTTP.
      Прокси-серверы часто путают с шлюзами. Однако, есть важная отличительная особенность. Шлюз, вообще говоря, является прозрачным к приложениям, все же исполняет некоторые обслуживающие функции от их имени. Сетевой маршрутизатор является простым примером шлюза, направляя пакеты данных между подсетями, которые во всех отношениях изолированы друг от друга. Хотя шлюзы могут быть вовлечены в выбор маршрута данного пакета TCP/IP от одного пункта к другому, приложение ничего не знает о роли шлюза. Прокси-сервер действует как шлюз уровня приложения, который обеспечивает маршрутизацию на уровне приложения лучше чем на уровне пакета. Иными словами, шлюз уровня пакета направляет пакеты TCP/IP на сеть, тогда как шлюз уровня приложения направляет поток HTTP, FTP, и Gopher от одной подсети к другой.
      Microsoft Internet Proxy Server обеспечивает обслуживание CERN-совместимого посреднического шлюза для большинства протоколов Internet, включая HTTP, FTP, Gopher, Telnet, SMTP, NNTP, и RealAudio, без модификации ваших приложений, и поддерживает TCP/IP и IPX/SPX от внутренней сети к внешним узлам. Обеспечивает также санкционированный доступ на уровне приложения, фильтрацию доменов, кэширование информации, и отслеживание действий пользователей. Internet Proxy Server интегрирован со средствами администрирования Windows NT® Server, безопасности и контроля и включает средства удаленного администрирования для централизованного управления всеми системами информационного сервера Internet и прокси-сервера.
      Лаборатория физики частиц в Европейской организации ядерных исследований в Швейцарии написал первые библиотеки кодов для поддержки приложений клиента HTTP и сервера. Скоро стало очевидно, что ориентированная на приложения прокси-технология необходима чтобы обеспечить неограниченный доступ к Internet из частной, защищенной сети. CERN добавил такую поддержку в свои библиотеки. Теперь, С расширением возможностей для увеличения производительности и добавлением таких функций как опознавание клиента и зашифрованные данные, прокси-протокол CERN стал общепринятым стандартом промышленности, поддерживаемым большинством HTTP броузеров, включая Microsoft Internet Explorer 2.0 и 3.0.
      В типичном запросе HTTP, клиент (Web-броузер) подтверждает запрос к серверу HTTP, говоря
http://www.microsoft.com/goodies.html
который потом ищет требуемый URL и передает данные обратно клиенту. Web-броузер в действительности выполняет эту задачу за несколько шагов. Во-первых, он выделяет часть хоста сервера из URL (www.microsoft.com). Во-вторых, отмечает, что это запрос HTTP (http://) и создает соединение TCP/IP с хостом через назначенный для этого протокола порт (порт 80 в случае HTTP если в URL конкретно не указано). Наконец, передает оставшуюся часть URL серверу хоста в следующем виде:
GET /goodies.html HTTP/1.0
Сервер www.microsoft.com понимает, что клиент запросил документ, названный goodies.html и передает его обратно как HTML файл.
      Запрос прокси-сервера очень простой, но Web броузер должен быть конфигурирован на использование прокси-сервера вместо того, чтобы создавать запрос непосредственно к назначенному серверу HTTP. Рисунок 2 иллюстрирует конфигурацию прокси для Microsoft Internet Explorer 3.0 (IE 3.0). Вы можете получить доступ к странице конфигурации двойным щелчком на иконе Internet панели управления Windows® 95, затем выбрав дополнительно таблицу свойств. В этом примере, я выбрал DavePC2 , чтобы установить мой прокси-сервер на TCP на порт 80.
catapultfig02.gif (14400 bytes)
Рисунок 2: Прокси-конфигурация IE 3.0
      Когда я делаю запрос "http://www.microsoft.com/goodies.html" из броузера, вместо того, чтобы разбивать этот URL и посылать это непосредственно к серверу HTTP www.microsoft.com, броузер устанавливает связь с прокси-сервером, который я указал, и посылает полный URL (включая протокол и сервер хоста) как запрос HTTP.
GET http://www.microsoft.com/goodies.html HTTP/1.0
Прокси-сервер, получив запрос, ведет себя как если бы это был клиент HTTP. Прокси-сервер выделяет долю хоста из URL (www.microsoft.com), определяет, что это запрос HTTP (http://), устанавливает связь с www.microsoft.com, и выдает запрос HTTP "GET /goodies.html HTTP/1.0". Сервер отсылает этот документ обратно на прокси-сервер, который уже играет другую роль - становится опять сервером HTTP и передает документ обратно броузеру.
      Microsoft Internet Proxy Server работает под Windows NT Server 3.51 и 4.0 на компьютере как минимум с двумя сетевыми адаптерами: один для защищенной сети и один для Internet (см. рисунок 1). Карта соединенная с защищенной сетью использует как минимум один транспортный протокол, как например TCP/IP, IPX/SPX, или NetBEUI. Карта, соединенная с Internet использует только TCP/IP.
      Более тщательное изучение проекта IPS показывает, что он осуществлен через Internet Server API (ISAPI). Детали ISAPI выходят за рамки этой статьи, но я опишу достаточно, чтобы объяснить как работает IPS.
      Есть два типа компонент ISAPI: фильтры приложений и расширения риложений. Обе компоненты выполняются под IIS и представляют собой DLL, которые IIS загружает и выполняет по мере необходимости. Фильтр приложения вызывается всякий раз, когда IIS сделан запрос на обслуживание. После начала этого запроса в составные части для удобной манипуляции, но перед фактическим действием по запросу, IIS обращается к всем фильтрам приложений, которые зарегистрировали интерес в этом специфическом типе запроса (см. Рисунок 3). Тогда каждый фильтр имеет возможность обработать запрос, разрешить или отклонить запрос, или даже модифицировать запрос перед передачей его обратно IIS.
catapultfig03.gif (7594 bytes)
Рисунок 3: IPS как приложение ISAPI
      после того как зарегистрированные фильтры приложений обработают запрос на обслуживание, IIS определяет, какое расширение приложения должно обрабатывать запрос. Если это прокси-запросt, IPS-расширение приложения переадресовывает запрос Internet. Если все идет хорошо, расширение вскоре получает результаты запроса и передает их обратно IIS, который потом отправляет эти результаты инициатору на защищенную сеть.

Запросы фильтрации

      Ряд фильтров ISAPI вовлечен в начальную обработку запроса. Figure 4 показывает строение фильтров, которые могут быть предоставлены или добавлены на прокси-сервер. Фильтры проверки прав доступа и домена обеспечивают средства регулирования доступа к Internet от пользователя или сайта. Проверка прав доступа на уровне пользователя, включая проверку прав доступа "Вызов/ответ" Windows NT, - единственный способ ограничить доступ в Internet. Как только пользователю предоставлен доступ к Internet, фильтрация домена ограничивает доступные участки сети. Например, как администратор сервера, вы можете одобрить свободный доступ к www.microsoft.com, но очень маловероятно, что каждому в корпорации нужен доступ к www.playboy.com. (И не дурачьте старой репликой: "я только читаю это для конкурентого анализа".)
      Чтобы использовать ресурсы эффективно и улучшить для клиента эффективность доступа к Internet, программно-аппаратные средства защиты сервера могут сохранять часто используемые страницы Internet на диске. Кэширование уменьшает траффик Internet и позволяет получить более быстрый ответ для часто используемой информации. Если пользователь требует страницу HTML, которая уже в кэше, она получается оттуда. Кэширование помогает, если у вас более медленный доступ к Internet или если вы выбираете некоторые ресурсы Internet повторно.
      Фильтр регистрации собирает информацию, например, к каким сайтам Internet происходят наиболее частые обращения, для учетных целей. Вывод регистрации может быть записан в простой log файл или в базу данных SQL или ODBC. Вывод информационного протокола в базу данных позволяет администраторам воспользоваться преимуществом генератора отчетов, который обычно является доступным как часть СУБД. Наконец, прокси-фильтр определяет должно ли вызываться расширение прокси-приложения IIS. Прокси-фильтр перенаправляет запросы клиента прокси-расширению, которое потом обращается с запросом от имени клиента

Поддержка удаленных узлов

      До настоящего времени я обсуждал функции, которые являются более или менее стандартными в прокси-сервере. Microsoft добавила другую функцию, Remotable Windows Sockets (RWS), расширение к WinSock API которая делает возможными соединения удаленных узлов через шлюз с Internet. Как часть IPS оно служит дополнением к совместимой со стандартом CERN-proxy поддержке протоколов HTTP, FTP и Gopher, обеспечивая поддержку шлюза для других протоколов Internet, например IRC и NNTP и для таких запатентованных протоколов как RealAudio. RWS это тонкий уровень между приложением, основанным на WinSock и WinSock DLL.Оно перехватывает все вызовы WinSock API и, в зависимости от протокола и связанного с ним адреса назначения, передает вызов к удаленному RWS-прокси или просто переадресовывает вызов на локальный WinSock DLL (см. Рисунок 5). Так как вы заинтересованы только тем, что является новым и захватывающим относительно RWS, остальная часть моего обсуждения будет основана на том, что вы используете удаленный режим через RWS, не делая локальные соединения через родной WinSock DLL.

catapultfig05.gif (8754 bytes)
Figure 5: Remotable Windows Sockets operation

      RWS прокси-сервер требует два связующих звена для приложения—одно для передачи запросов WinSock  и другое для управления соединением прокси-сервера с Internet. Управляемое соединение с RWS -прокси установлено по начальному запросу WinSock. RWS прокси-сервер предоставляет соединение с Internet, основанное на ID пользователя и разрешении на доступ, установленном администратором RWS через экран настройки. Впоследствии, все вызовы WinSock API, сделанные приложением, ведут себя прозрачно, как если бы они эксплуатировались на локальной WinSock DLL. Прокси-сервер становится, в этом сценарии, шлюзом WinSock, обеспечивая прозрачный доступ через WinSock к Интернету, как если бы RWS прокси-сревер не был представлен вообще.
      Имеется множество других особенностей, запланированных для расширений RWS к IPS, но когда это писалось, полный набор функций не был завершен. Достаточно сказать, что когда IPS будет выпущен официально, RWS будет обеспечивать дополнительные преимущества, просто действуя как шлюз WinSock между частной сетью и Internet. Среди тех функций может быть доступ, управляемый аутентификацией уровня пользователя и фильтрацией домена, протокол преобразования данных (как например используется IP с IPX в локальной сети), локализация адреса подсети (позволяющая внутренним сетям использовать произвольные IP адреса), и кэширование данных. RWS обеспечит для существующих приложений, основанных на WinSock легкий способ получить доступ к Internet при поддержании защиты локальной сети.
      В настоящее время есть Beta-версия IPS, которую можно найти на http://www.microsoft.com/infoserv/catapult. In producing the proxy server, which is integrated into the architecture of Internet Information Server, Microsoft все же снова показала свою ловкость в соблюдении стандартов при добавлении функциональных возможностей вне тех самых стандартов.
ending.gif (244 bytes)


From the September 1996 issue of Microsoft Interactive Developer.


Send feedback on this article.  Find support options.

© 2000 Microsoft Corporation. All rights reserved. Terms of use.