Кэширующий прокси-сервер Squid для операционных систем семейства Linux
Параметры для работы с соседними кэш-серверами
Параметры размера локального кэша
Аутентификация пользователей сервера
Анализатор логов прокси-сервера Squid — LightSquid
Прокси-серверы (proxy server) появились на заре эпохи Интернета, когда пользователей этой сети становилось все больше и больше, а внешние IP-адреса стоили немалых денег. Тогда основным назначением proxy-серверов являлась организация доступа в Интернет локальных пользователей без добавления их компьютеров к Глобальной сети, то есть без назначения внешних IP-адресов компьютерам, а выход в Интернет осуществлялся только с одного внешнего IP-адреса. Слово proxy в переводе с английского означает «доверенное лицо» или «представитель». Условно говоря, прокси-сервер действует от лица клиента в Интернете, и для других пользователей Сети виден только сам сервер (его IP-адрес), а не клиент (IP-адрес компьютера пользователя скрыт от посторонних глаз). Таким образом, кроме общего доступа в Интернет локальных пользователей, которые не имеют прямого выхода в Сеть, такие серверы позволяют соблюсти приватность работы в Интернете. Вследствие того что компьютеры обычных пользователей не размещены непосредственно в Сети, снижается угроза хакерских атак, поскольку прямого доступа к компьютерам локальной сети нет.
Обычные, широко применяемые сейчас маршрутизаторы по сути являются одним из видов прокси-серверов — NAT proxy. Они тоже позволяют организовать доступ в Интернет локально подключенных к маршрутизатору компьютеров путем подмены исходящего IP-адреса в IP-пакетах. Но маршрутизатор, поддерживающий технологию NAT (Network Address Translation), имеет некоторые минусы по сравнению с обычным программным прокси-сервером. Маршрутизатор никак не анализирует проходящий через него трафик и типы протоколов, через которые пользователи работают с Интернетом, поэтому администрировать (в данном случае ограничивать пользователей по конкретным параметрам при доступе в Сеть) такие устройства практически невозможно. Прокси-сервер может находиться в любой точке Интернета и, если правила доступа разрешают, позволяет работать с любым клиентом независимо от его местонахождения. Для работы NAT, как правило, необходимо физическое подключение локального компьютера к маршрутизатору (например, через локальную сеть), поскольку маршрутизатор работает через жестко установленные маршруты пакетов. Также стоит отметить, что обычный маршрутизатор не позволяет кэшировать часто используемые объекты для более быстрого обращения к ним пользователей, поскольку он только перенаправляет пакеты от одного узла Сети к другому.
Типы прокси-серверов
Существует несколько типов прокси-серверов, каждый из которых имеет узкую специализацию, то есть поддерживает работу только с одним или несколькими протоколами. Самыми распространенными на данный момент являются http-, Socks- и NAT-прокси. Последние входят в стандартные компоненты современных операционных систем, таких как Linux и Windows. По своим характеристикам программные прокси-серверы NAT практически не отличаются от аппаратных (маршрутизаторов) и существенно уступают в администрировании узкоспециализированным прокси-серверам. Рассмотрим наиболее популярные типы прокси-серверов.
HTTP прокси-сервер — один из самых распространенных типов прокси-серверов в мире. Как видно из названия, он предназначен для работы с HTTP-протоколом и позволяет работать браузерам и другим подобным программам. Браузер запрашивает страницу у прокси-сервера, который, в свою очередь, запрашивает ее из собственного кэша. Если страница не найдена в кэше или имеет параметры, которые запрещают ее кэширование, прокси-сервер запрашивает ее у соседнего прокси-сервера или напрямую обращается к сайту и после успешной загрузки страницы выдает ее пользовательскому приложению. Поскольку далее в статье будет рассматриваться один из HTTP прокси-серверов — Squid, перечислим основные возможности этого типа прокси-серверов:
- позволяют кэшировать часто используемые данные (веб-страницы), благодаря чему сокращается внешний трафик и ускоряется загрузка страниц конечным пользователем. Однако Интернет становится все более динамичным, и зачастую многие веб-серверы запрещают прокси-серверам кэшировать данные или налагают ограничение на определенные страницы, поэтому прирост в экономии трафика не очень существен и может составлять до 15%. Если вопрос о трафике стоит остро, то многие HTTP прокси-серверы поддерживают игнорирование заголовков META в страницах, тем самым позволяя кэшировать динамичные данные;
- ограничивают доступ не только к определенным сайтам, но и к конкретным разделам сайта, за счет чего достигается большая гибкость в администрировании пользователей. Кроме того, доступ к сайтам определенной группы можно разрешать лишь после дополнительной аутентификации;
- некоторые HTTP прокси-серверы позволяют ограничивать скорость загрузки информации, расставляя приоритеты по типам файлов. Благодаря этому можно блокировать высокую скорость загрузки, например видеофайлов или музыкальных композиций;
- поддерживают резку рекламных блоков (баннеров) путем замещения исходной картинки или аплета своим кодом, что сокращает дополнительный трафик;
- возможно разделение конкретных сайтов на работу через те или иные дополнительные прокси-серверы или интернет-каналы, что позволяет более экономно управлять трафиком и выбирать оптимальные каналы связи;
- одна из важных особенностей HTTP прокси-сервера — возможность ведения подробной статистики по каждому пользователю. Это позволяет анализировать использование трафика отдельными пользователями, а также выявлять наиболее часто применяемые веб-серверы;
- позволяют работать не только с протоколом HTTP, но и с другим подобным протоколом — FTP, а в случае необходимости — блокировать его.
HTTPS прокси-сервер — по сути дела, это точно такой же HTTP прокси-сервер, как и описанный выше. Основным отличием данного типа прокси-серверов является возможность шифрования передаваемых между клиентом, прокси-сервером и конечным сервером данных, о чем и сообщает буква «s» в его названии. Прокси-сервер, работающий по протоколу HTTPS, лишь организует канал передачи между клиентом и сервером и не позволяет анализировать проходящую по нему информацию. Соответственно возможности HTTPS, по сравнению с HTTP, существенно уже. В то же время этот прокси-сервер может быть использован в качестве прокси-сервера для иных, отличных от HTTPS протоколов — pop, smtp, imap и ряда других. В любом случае прокси-сервер такого типа значительно повышает безопасность конфиденциальной информации, хотя и имеет некоторые недостатки. Обычно HTPPS прокси-сервер совмещают с HTTP прокси-сервером, что делает его более универсальным и гибким при настройке клиентов.
FTP прокси-сервер — этот тип прокси-сервера предназначен для работы с протоколом FTP. Клиент обращается к прокси-серверу, а он передает запрос FTP-серверу. Существует два варианта работы клиента FTP через прокси-сервер. Первый вариант, когда запросы к FTP-серверу передаются через HTTP прокси-сервер, поддерживает большинство HTTP прокси-серверов, поскольку он удобен для браузеров, но при этом некоторые функции работы с FTP-сервером будут недоступны. Вторым вариантом как раз является работа через отдельный FTP прокси-сервер, и в этом случае поддерживаются все опции этого протокола — такого соединения требует большинство специализированных FTP-клиентов. Отметим, что прокси-серверы данного типа применяются редко, поскольку обычный HTTP прокси-сервер в большинстве случаев удовлетворяет потребности обычных пользователей, которые лишь загружают информацию с FTP-серверов, при этом не используя все доступные FTP-протоколу функции.
SOCKS прокси-сервер — работает на основе специально разработанного протокола SOCKS (сокращенно от SOCKetS). В настоящий момент последней версией протокола является SOCKS 5. Она позволяет производить аутентификацию пользователей на серверной стороне, что повышает гибкость настройки подобных систем. Прокси-серверы SOCKS являются универсальными и позволяют пользователю работать через любой другой протокол с практически любым видом сервисов в Интернете. Одна из особенностей прокси-серверов этого типа — возможность работы от внешних клиентов с внутресетевыми серверами, расположенными за межсетевыми экранами. Такой подход позволяет широко использовать этот вид прокси для обеспечения доступа клиентов как из локальной сети, так и в обратном направлении. Поскольку этот протокол является одним из самых популярных на данный момент, созданы специальные программы, например FreeCap (www.freecap.ru), предоставляющие возможность пропускать клиентское программное обеспечение в Интернет через этот протокол даже при отсутствии поддержки его этим программным обеспечением.
Кроме вышеперечисленных основных типов прокси-серверов, которые охватывают большинство распространенных протоколов передачи данных, существуют узкоспециализированные серверы, обеспечивающие корректную работу с теми или иными приложениями. В добавление ко всему вышеизложенному отметим, что прокси-серверы, к которым может получить доступ любой пользователь Интернета, называются открытыми. Таких серверов довольно много по всему миру, и ориентированы они в первую очередь на тех пользователей, которые хотят сохранить посещение страниц или серверов в тайне от провайдера или от сетевого администратора. Однако зачастую эти серверы могут прослушиваться, поскольку любой прокси-сервер (его трафик) без поддержки шифрования передаваемых данных может быть прослушан на любом из устройств, которые находятся на пути от клиента к серверу.
Прокси-сервер Squid
Проект прокси-сервера Squid (www.squid-cache.org) в свое время отделился от ныне платного проекта Harvest и разрабатывается несколькими энтузиастами во главе с Duane Wessels из Национальной лаборатории по исследованию сетей (National Laboratory for Applied Network Research). Сервер Squid — это высокопроизводительный кэширующий прокси, ориентированный прежде всего на работу с пользователями, которые занимаются активным серфингом в Интернете. Squid поддерживает работу пользователей с такими протоколами, как FTP, HTTP, HTTPS и GOPHER. В отличие от других подобных проектов, прокси-сервер Squid обладает интересной особенностью — выполнение запросов пользователей реализовано в нем как один большой неблокируемый процесс ввода-вывода, что обеспечивает более высокую производительность сервера в целом. Поскольку сервер Squid является кэширующим прокси, он поддерживает широкие возможности по построению иерархической структуры связи кэш-серверов на основе протоколов ICP/UDP (Internet Cache Protocol), HTCP/TCP и multicast. Такая система позволяет получить высокую производительность и оптимизировать пропускную способность канала в Интернет. Кэш сервера разделяется на виртуальный, который находится в оперативной памяти компьютера, и обычный, который хранится на жестком диске. Наиболее часто используемые объекты хранятся в оперативной памяти, что ускоряет процесс их отсылки клиентам. Также в виртуальной памяти хранится большая часть запросов DNS. Squid в полной мере поддерживает SSL (HTTPS), что обеспечивает конфиденциальность передаваемой пользователями информации и приватность их работы в Интернете. Также нельзя обойти вниманием широкие возможности по аутентификации пользователей на основе различных методик: NCSA, LDAP, MSNT, NTLM, PAM, SMB, SASL и др. Все дополнительные программы для аутентификации пользователей идут в комплекте с основным ядром программы. Как видно из перечисленных методик, Squid поддерживает авторизацию пользователей средствами сервисов не только на Linux-, но и на Windows-платформе (MSNT и NTLMv1). В будущем ожидается поддержка сервиса NTLMv2, который используется в операционных системах Windows 2003 Server и Vista.
Установка сервера
Прокси-сервер Squid поставляется практически во всех дистрибутивах операционных систем семейства Linux. Если его нет в комплекте операционной системы, то его можно загрузить с сайта разработчика — www.squid-cache.org. На момент написания этой статьи уже появилась официальная версия 3.0STABLE1 — это означает, что почти четырехлетняя работа над новой версией 3.0 успешно завершена. Однако пока ее можно установить только для тестирования, так как она еще сырая и не обкатана администраторами. Поэтому мы рассмотрим одну из старых версий Squid — 2.6STABLE12. На данный момент последней версией серии 2.6 является 2.6STABLE18 от 10 января 2008 года.
Если дистрибутив прокси-сервера Squid загружен с сайта команды разработчиков, для его установки необходимо следовать прилагаемой инструкции. По умолчанию сервер будет сконфигурирован с большинством дополнительных параметров, которые необходимы для развертывания полноценного прокси-сервера в крупной организации. При необходимости многие модули можно отключить при установке, поскольку далеко не все сервисы необходимы для минимальной работы сервера.
Установку прокси-сервера Squid также можно осуществить через программные пакеты типа yum или apt-get, которые автоматически установят пакет Squid и сконфигурируют его без участия пользователя. Пример команды установки:
yum install Squid
или, если Squid уже установлен, но требует обновления:
yum update squid
После установки прокси-сервер Squid можно запускать из командной строки через команду squid или, что более правильно, service squid start, при необходимости можно добавить этот сервис в скрипт (/etc/rc.d) автозагрузки при старте системы.
Запустив сервис в первый раз с настройками по умолчанию, пользователь должен увидеть следующую картину по команде ps axf | grep squid:
29311 ? Ss 0:00 squid -D
29313 ? S 2:03 \_ (squid) -D
29315 ? Ss 0:01 \_ (unlinkd)
Это свидетельствует о том, что сервис squid запущен и ожидает входящих соединений. Дополнительная программа unlinkd, для которой родительским процессом является squid, отвечает за очистку кэша. Если возникли проблемы с запуском сервиса, процесс повис или вообще не запустился, следует посмотреть log-файл, который генерируется автоматически и размещен в папке /var/log/squid/, — это даст представление об ошибке, из-за которой сервис работает некорректно.
Перед тем как запускать сервер, необходимо отредактировать конфигурационный файл squid.conf, который по умолчанию располагается в папке /etc/squid/. По умолчанию ни один из пользователей не сможет воспользоваться прокси-сервером без редактирования конфигурационного файла.
Рассмотрим наиболее важные параметры конфигурационного файла, без которого сервер работать не сможет. Все параметры и значения довольно подробно объяснены на английском языке в закомментированных строках.
Параметры соединений клиент-сервер и сервер-сервер
Параметр http_port
Данный параметр может быть записан несколькими способами, например:
Порт
Имя хоста : порт
IP адрес: порт
Порт указывает на порядковый номер порта, на котором прокси-сервер будет прослушивать входящие соединения от клиентов. По умолчанию большинством HTTP прокси-серверов используется порт 3128. Имя хоста или IP-адрес явно указывает, на каком из интерфейсов будет работать прокси-сервер. Если в вашей системе несколько интерфейсов, а доступ дать необходимо только двум сетям из трех, то надо перечислить их в этом параметре в виде:
http_port 10.0.0.1:3128
http_port 192.168.0.1:3128
Параметр https_port
По своим функциям этот параметр схож с http_port, но предназначен для задания строгих опций работы по протоколу SSL (HTTPS).
Синтаксис данной опции выглядит так:
https_port ip:port cert=certificate.pem key=key.pem version=sslversion options=option,
где certificate.pem — сертификат шифрования; key.pem — ключ шифрования; options и version указывают на параметры SSL. Version может принимать значения 1, 2, 3 или 4, где 1 — это автоматический режим; значения 2 и 3 строго указывают на применяемую при работе версию SSL (вторая или третья); 4 — на TSLv1. Options работает по принципу от противного, то есть исключает неиспользуемые версии SSL. По умолчанию параметр https_port закомментирован, и применяются стандартные значения. В основном он используется в том случае, когда прокси-сервер работает в режиме акселератора сервера apache.
Параметр icp_port
Данный параметр задает порт, который будет прослушиваться Squid для обмена информацией с другими кэш-серверами по протоколу ICP (Internet Cache Protocol). По умолчанию он имеет значение 3130. Если сервер не предполагается использовать в связке с дополнительными кэш-серверами, то эту опцию следует отключить для оптимизации работы сервера. Отключение данного параметра осуществляется путем добавления (раскомментирования) строки icp_port и выставления значения 0. Также отключения этой опции можно добиться, добавив опцию -u в командной строке при запуске сервиса Squid.
Параметр htcp_port
Параметр htcp_port отвечает за порт, который будет использоваться прокси-сервером Squid для обмена пакетами между соседними кэш-серверами по протоколу HTCP. Стандартный порт для этого протокола — 4827. Однако стоит отметить, что по умолчанию при установке Squid через yum этот протокол отключен.
Параметр mcast_groups и параметры UPD для Multicast
Опция mcast_gropus задает параметры соединения через Multicast по UDP. По умолчанию в конфигурационном файле нет указаний ни на одну из групп. Перед тем как использовать данную функцию, необходимо вникнуть в систему мультикаст передачи данных. Если группа задана явно, нужно ввести дополнительные параметры:
- udp_incoming_address — отвечает за входящие соединения;
- udp_outgoing_address — отвечает за исходящие соединения.
По умолчанию данные параметры закомментированы и отключены.
Параметры для работы с соседними кэш-серверами
Параметр cache_peer
Данная опция четко задает, какой из соседних кэш-серверов необходимо использовать и какие параметры соединения требуются для работы с ним. Синтаксис параметра выглядит следующим образом:
cache_peer hostname type proxyport icpport options,
где hostname — DNS-имя кэш-сервера, с которым будет работать squid; proxyport — порт, на котором работает Squid (указывается в параметре http_port на соседнем кэш-сервере); icpport — порт, через который происходит обмен служебной информацией с соседним кэш-сервером (должен быть указан тот порт, который приводится в параметре icp_port на соседнем кэш-сервере); type — тип соединения (может принимать значения parent, multicast и sibling); options — различные параметры соединения, в основном используется параметр proxy-only.
Соответственно для каждого из дополнительных кэш-серверов параметры указываются отдельной строкой.
Параметр cache_peer_domain
Данный парметр позволяет строго задать, какой из доменов (объекты этого домена) обслуживается конкретным кэш-сервером. Синтаксис команды выглядит следующим образом:
cache_peer_domain cachehost domain !domain…,
где cachehost — имя соседнего кэш-сервера; domain — обслуживаемый домен (например, .ru или .net).
Восклицательный знак означает обратное действие: не обслуживать данный домен с помощью этого кэш-сервера.
Параметры таймаутов соединения с соседними серверами
Параметр icp_query_timeout или maximum_icp_query_timeout задает значение времени ожидания ответа от удаленного сервера в миллисекундах по протоколу ICP.
Параметр mcast_icp_query_timeout — то же самое, но для multicast.
Параметр dead_peer_timeout задает время в секундах, после чего хост, который не отвечает, считается отключенным и запросы к нему не посылаются.
Параметр hierarchy_stoplist
Данная опция позволяет указать строку. Если строка будет найдена в URL, этот объект не будет запрашиваться у кэш-серверов и не будет там размещаться. По умолчанию данный параметр блокирует сохранение запросов cgi-bin на удаленных кэш-серверах для обеспечения безопасности.
Параметр no_cache
Как видно из названия, данный параметр блокирует загрузку в кэш объекта. Объект определяется через формулировку acl, о которой будет рассказано чуть ниже. По умолчанию этот параметр блокирует любое сохранение объектов, в URL которых встречается строка cgi-bin. Синтаксис блокировки cgi-bin выглядит следующим образом:
acl QUERY urlpath_regex cgi-bin /?
no_cache deny QUERY
Параметры размера локального кэша
Параметр cache_mem
Один из главных параметров, определяющий объем оперативной памяти, которая будет применяться Squid для хранения часто используемых объектов. Объекты, в свою очередь, разбиваются на блоки по 4 Кбайт (размер блока определяется параметром maximum_object_size_in_memory), что значительно повышает скорость обработки и передачи информации конечному пользователю. По умолчанию этот параметр равен 8 Мбайт, однако, если вы обладаете избыточным количеством оперативной памяти, значение этого параметра можно увеличить, что повысит производительность сервера.
Параметры cache_swap_low и cache_swap_high
Данные параметры указывают на максимальное (в процентах) применение дискового пространства, отведенного под хранение кэша. Как только нижний порог будет достигнут (cache_swap_low), Squid будет заменять неиспользуемый кэш другим, более новым контентом. Если же пройден верхний порог, сервер будет более агрессивно удалять неиспользуемые файлы. Таким образом, достигается ротация и обновление кэша. По умолчанию для нижнего порога установлено значение 90%, а для верхнего — 95% от размера, отведенного под кэш.
Параметры maximum_object_size и minimum_object_size
Значения этих параметров указывают серверу на объем файлов, которые будут сохранятся в кэше. По умолчанию значение нижнего порога равно нулю, а верхнего — 4 Мбайт, то есть файлы с размером от 0 до 4 Мбайт могут быть сохранены в кэше, файлы большего объема игнорируются и не записываются в кэш.
Параметры cache_replacement_policy и memory_replacement_policy
Данные параметры позволяют задать алгоритм, по которому будет выполняться замена файлов в кэше (в зависимости от названия — в оперативной памяти (memory_replacement_policy) или на диске (cache_replacement_policy)). По умолчанию применяется алгоритм lru, который хранит в кэше наиболее часто используемые объекты. Алгоритм GDSF задает параметры кэша таким образом, чтобы хранить часто применяемые объекты с очень маленьким размером. По правилу LFUDA кэш хранит часто используемые объекты большого размера, пренебрегая при этом малыми объектами.
Параметр cache_dir
Еще один из основных параметров прокси-сервера. Синтаксис выглядит следующим образом:
cache_dir type dir mbytes L1 L2 options,
где type — тип сохранения, по умолчанию Squid сохраняет и работает с кэшем в режиме ufs, существуют также режимы aufs и diskd (внешняя программа, поставляемая с прокси-сервером); dir — указание директории, где будут храниться файлы с кэшем; mbytes — максимальный размер этой директории; L1 — количество поддиректории в корневом каталоге кэша; L2 — количество поддиректорий в директориях первого уровня (L1).
Стандартные настройки кэша имеют следующий вид:
cache_dir ufs /var/spool/squid 100 16 256
Остальные параметры кэша и внешних модулей можно опустить, поскольку в большинстве случаев они используются по умолчанию.
Аутентификация пользователей сервера
Режим аутентификации пользователя задается параметром auth_param. Он предусматривает выбор из нескольких способов авторизации конечного пользователя, которые могут быть скомбинированы между собой в зависимости от необходимости и применяемых приложений (браузеров клиентов и т.п.). Описание каждого из методов займет не одну страницу, поэтому рассмотрим наиболее простой пример, когда пользователи определяются в зависимости от IP-адреса их компьютера. По умолчанию Squid настроен именно на такую систему аутентификации и необходимые строчки параметров раскомментированы. Однако для работы пользователей внутренней сети нужно внести некоторые коррективы в другие параметры, которые и будут рассмотрены далее.
Параметр acl
Данный параметр называется access list и отвечает за доступ к серверу клиентов в соответствии с их IP-адресами или другими параметрами, заданными опцией string. Синтаксис этого параметра вполне обычен для Linux-платформ:
acl aclname acltype string,
где aclname — название аккаунта, которое будет использовано в других параметрах с применением acess list; acltype — тип, по которому определяется возможность доступа компьютера пользователя к серверу; string — значение, зависящее от указанного типа.
Опция acltype может быть задана следующими значениями:
- dst — если сайт, на который идет запрос от клиента, соответствует опции string, то этот пользователь имеет к нему доступ;
- src — диапазон или единичный IP-адрес клиента;
- mac — MAC-адрес клиента;
- srcdomain — клиент конкретного домена;
- dstdomain — доступ к домену;
- time — время доступа (daydayday… h1-h2);
- port — доступ к определенному порту или диапазону портов;
- proto — доступ по определенному протоколу;
- browser — доступ определенного браузера.
По умолчанию в конфигурационном файле создан access list, который включает всех возможных клиентов, поскольку определяет диапазон всех возможных IP-адресов:
acl all src 0.0.0.0/0.0.0.0.
Однако доступ к этому access list закрыт для работы через прокси-сервер с помощью команды:
http_access deny all
Таким образом, если нужно создать открытый для всех пользователей Интернета прокси-сервер, достаточно заменить deny на allow — и все должно заработать. Однако в некоторых случаях это не срабатывает. Необходимо разрешить еще одну опцию — http_reply_access allow all, которая по умолчанию должна быть равна этому значению, однако так происходит далеко не всегда. Мы рассмотрим пример обеспечения доступа компьютеров с определенными IP-адресами. Для этого создадим два access list, которые будут определять пользователей с конкретных сетей:
acl corbina src 10.156.0.0/255.255.0.0
acl local src 192.168.192.0/24
Затем им необходимо разрешить доступ, добавив строчки:
http_access allow corbina
http_access allow local
И заключительный этап:
http_reply_access allowcorbina
http_reply_access allow local
Чтобы запретить доступ к серверу для клиентов, которые находятся вне описанных сетей, добавляем на всякий случай строки:
http_reply_access deny all
http_access deny all
После установки таких параметров можно смело запускать прокси-сервер и в зависимости от прописанных настроек сконфигурировать браузеры конечных клиентов.
Если все прописано правильно и никаких ошибок нет, пользователи из этого диапазона адресов будут получать доступ в Интернет через прокси-сервер. Но тут возникает резонный вопрос: как анализировать проходящий трафик и получать хоть какую-нибудь информацию о том, кто пользуется Интернетом и на какие сайты заходит? Чтение логов в текстовом редакторе не даст никакой существенной информации, поэтому необходимо найти анализатор логов, который предоставит подобную информацию.
Анализатор логов прокси-сервера Squid — LightSquid
Безусловно, существует множество различных лог-анализаторов — как универсальных, так и узкоспециализированных. Для прокси-сервера Squid есть несколько проектов, один из которых — LightSquid. Это простой в установке и в то же время информативный демон, который позволяет извлечь большую часть информации о проходящем через прокси-сервер трафике и его клиентах. На сайте разработчика (lightsquid.sourceforge.net) можно скачать последнюю версию данной программы.
Установка версии LightSquid 1.7.1 предполагает распаковку архива с дистрибутивом и размещение файлов на web-сервере. После переноса файлов (например, в каталог /var/www/html/lightsquid) необходимо дать права доступа на исполнение файлов *.cgi и *.pl от лица web-сервера (в большинстве случае это пользователь apache и группа apache):
chmod +x *.cgi
chmod +x *.pl
chown -R apache:apache *
Затем в конфигурационном файле apache надо добавить возможность запуска скриптов cgi в этой директории:
<Directory «/var/www/html/lightsquid»>
AddHandler cgi-script .cgi
AllowOverride All
</Directory>
После добавления этих строк в конфигурационный файл нужно перезапустить apache:
service httpd restart
Вслед за этими командами необходимо отредактировать основной конфигурационный файл lightsquid.cfg. В данном случае требуется изменить переменную $lang и выставить ей значение ru вместо eng, чтобы статистика отображалась на русском языке. А также, если путь к lightsquid нестандартный, подправить пути к скриптам. По умолчанию в конфигурационном файле разрешена работа с изображениями, то есть на основании данных lightsquid строит простые графики. Библиотека Perl-GD не всегда устанавливается вместе с базовым пакетом Perl, поэтому необходимо установить ее, выполнив команду:
yum install Perl-GD.
После этого, если все параметры введены правильно, можно запустить так называемый парсер (обработчик лог-файлов) — lightparser.pl. Если статистика по пользователям уже накопилась, она будет отображена на web-сервере при вызове папки lightsquid (см. рисунок).
Заключение
Конечно, дешевые маршрутизаторы, быстрые и широкие каналы доступа в Интернет, а также доступность внешнего IP-адреса существенно уменьшили масштабы использования прокси-серверов во всем мире. Однако необходимо понимать, что применение правильно сконфигурированного прокси-сервера в большой компании в совокупности с NAT-прокси более надежно, чем использование только NAT-прокси, поскольку последние не дают возможности гибко устанавливать правила для конкретных сервисов и не позволяют ограничивать трафик для конкретных пользователей или сервисов (ведь для организации он до сих пор остается дорогим удовольствием).
 |
|
