Прокси-серверы прикладного уровня и уровня соединений

↑

▷ Содержание

⇐ ПредыдущаяСтр 163 из 167Следующая ⇒

▷ Похожие статьи

Прокси-серверы могут выполнять свою посредническую миссию на разных уровнях.

ПРИМЕР-АНАЛОГИЯ

Рассмотрим пример, иллюстрирующий идею посредничества разного уровня. Для покупки акций инвестор (в нашем случае аналог клиентской части приложения) может прибегнуть к посредническим услугам брокера или трейдера. Брокер, точно следуя указаниям инвестора, покупает для него опреде­ленное количество акций определенного типа по определенной цене. Трейдер — это посредник более высокого уровня, которому инвестор поручает самостоятельно принимать решения о необходимых покупках, учитывая различные факторы, например состояние рынка.

Различают прокси-серверы прикладного уровня и уровня соединений.

Прокси-сервер прикладного уровня, как это следует из его названия, умеет «вклинивать­ся» в процедуру взаимодействия клиента и сервера по одному из прикладных протоколов, например тому же HTTP, HTTPS, SMTP/POP, FTP или telnet. Чтобы выступать в роли посредника на прикладном уровне, прокси-сервер должен «понимать» смысл команд, «знать» форматы и последовательность сообщений, которыми обмениваются клиент и сер­вер соответствующей службы. Это дает возможность прокси-серверу проводить анализ содержимого сообщений, делать заключения о подозрительном характере того или иного сеанса.

Прокси-сервер уровня соединений выполняет свою посредническую миссию на транс­портном уровне, контролируя TCP-соединение. Очевидно, что работая на более низком уровне, прокси-сервер обладает гораздо меньшим «интеллектом» и имеет меньше возмож­ностей для выявления и предупреждения атак. Однако он обладает одним очень важным преимуществом перед прокси-сервером прикладного уровня — универсальностью, то есть он может быть использован любыми приложениями, работающими по протоколу TCP (а в некоторых случаях и UDP).

Примером прокси-сервера данного типа является разработанный достаточно давно, но все еще широко применяемый сервер SOCKS (от SOCKetS).

В простейшей версии протокола SOCKS V4^[78] клиент обменивается с прокси-сервером SOCKS двумя сообщениями: запросом клиента SOCKS-серверу и ответом SOCKS-сервера клиенту.

§ Запрос клиента SOCKS-серверу:

o поле 1 — номер версии SOCKS, 1 байт (для этой версии — 4);

o поле 2 — код команды, 1 байт (для установки соединения TCP/IP код равен 1);

o поле 3 — номер порта, 2 байта (TCP-порт запрашиваемого пользователем ресурсного сервера, например, для 21 для FTP);

o поле 4 — IP-адрес, 4 байта (IP-адрес ресурсного сервера);

o поле 5 — идентификатор пользователя (строка переменной длины, завершаемая байтом null).

SOCKS-сервер анализирует все полученные данные и на основании сконфигурирован­ных для него правил определяет, предоставить или нет данному пользователю доступ к данному серверу. Результат SOCKS-сервер сообщает клиенту в виде ответа.

§ Ответ SOCKS-сервера клиенту:

o поле 1 — байт null;

o поле 2 — код ответа, 1 байт (применяются коды для следующих вариантов ответа: запрос разрешен, запрос отклонен или ошибочен, запрос не удался из-за проблем с идентификацией пользователя);

o несколько байтов, игнорируемых клиентом.

Если прокси-сервер сообщил в ответе, что запрос разрешен, то SOCKS-сервер начинает работать промежуточном звеном между клиентом и сервером (например, FTP), контро­лируя поток квитанции, которыми они обмениваются.

«Проксификация» приложений

Заметим, что не каждое приложение, построенное в архитектуре клиент-сервер, непре­менно должно работать через прокси-сервер, а также не каждое из них имеет возможность работать через прокси-сервер.

Список приложений (точнее их клиентских частей), которые должны передавать свои запросы во внешнюю сеть исключительно через прокси-сервер, определяется администра­тором. А чтобы эти приложения имели возможности для такого режима выполнения, их программы должны быть соответствующим образом написаны.

Точнее приложения должны быть оснащены средствами, которые распознавали бы запросы к внешним серверам и перед отправкой преобразовывали эти запросы так, чтобы все они попадали на соответствующий прокси-сервер, а не передавались в соответствии со стан­дартным протоколом прямо на сервер-адресат. Эти средства должны также поддерживать протокол обмена сообщениями приложения-клиента с прокси-сервером. В последние годы в большинстве приложений, ориентированных на работу через Интернет, предусмотрена встроенная поддержка прокси-сервера. Такой поддержкой, например, оснащены все веб­браузеры и все клиенты электронной почты, которыми мы сейчас пользуемся.

«Проксификация» приложения, изначально не рассчитанного на работу через проки- сервер, требует изменения исходного кода с последующей перекомпиляцией — очевидно, что такая работа не представляет сложностей для разработчиков данного приложения, но не всегда под силу обслуживающему персоналу сети. Задача последних заключается в при­обретении готовых приложений, совместимых с используемым в сети прокси-сервером. Однако даже приобретение готового «проксифицированного» клиента не делает его гото­вым к работе — необходимо еще конфигурирование, в частности нужно сообщить клиенту адрес узла сети, на котором установлен соответствующий прокси-сервер.

Как можно было бы предположить, процедура «проксификации» значительно упрощается для прокси-сервера уровня соединений, в частности SOCKS-сервера. Для «проксифика­ции» приложения в этом случае достаточно внести простейшие исправления в исходный текст, а затем выполнить его перекомпиляцию и связывание с библиотекой процедур SOCKS. Исправления сводятся к замене всех стандартных вызовов сетевых функций версиями этих функций из библиотеки SOCKS, в частности стандартный вызов listen () заменяется вызовом rlisten(), вызов bind() — вызовом rbind(), вызов ассерt() — вы­зовом raccept().

Имеется еще один подход к «проксификации» — встраивание поддержки прокси-сервера в операционную систему, В этом случае приложения могут оставаться в полном «неведении» о существовании в сети прокси-сервера, за них все необходимые действия выполнит ОС. Помимо основных функций, многие прокси-серверы способны обнаруживать вирусы еще до того, как они попали во внутреннюю сеть. К другим полезным (для администрации и службы безопасности) вспомогательным функциям прокси-сервера относится сбор статистических данных о доступе пользователей в Интернет: когда и какие сайты посещал тот или иной пользователь, сколько времени продолжалось каждое посещение.

Познавательные статьи:



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

Приготовление дезинфицирующих растворов различной концентрации

Занятость населения и рынок труда

Социальный статус семьи и её типология