15.3. Настройка SQUID Сервер SQUID использует файл конфигурации squid.conf, который обычно располагается в каталоге /etc/squid (или /usr/local/squid/etc - более ранние версии). Откройте его в любом текстовом редакторе, например, joe/usr/local/squid/etc/squid.conf. Далее выполните следующую последовательность

15.4. Запуск SQUID Теперь, когда вы выполнили базовую настройку SQUID, его нужно запустить: /usr/local/squid/bin/squid –zПараметр –z необходим для создания (обнуления) каталога, содержащего кэш. Обычно этот параметр нужен только при первом запуске. Некоторые другие полезные параметры SQUID

15.5. Формат файла squid.conf В файле squid.conf задаются всевозможные параметры конфигурации прокси-сервера. Давайте рассмотрим их все по

17.1.5. Настройка Squid Установите пакет squid. Осталось настроить и запустить его. Для этого нужно отредактировать файл конфигурации /etc/squid/squid.conf. Сначала укажите адрес прокси провайдера: cach_peer proxy.your_isp.comЗадайте объем ОЗУ, который будет использовать прокси-сервером: cache_memВ том

Глава 18. Прокси-серверы SQUID и SOCKS 18.1. Что такое прокси-сервер? Прокси-сервер (сервер-посредник) - это программа, которая выполняет HTTP/FTP-запросы от имени клиентов. Применение прокси-сервера дает возможность использовать фиктивные IP-адреса во внутренней сети (IP-маскарадинг),

18.2. Установка SQUID Я использую версию squid 2.5. Пакет squid входит в состав современных дистрибутивов, а если его у вас почему-то нет, то скачать можно с www.squid-cache.org.При сборке SQUID из исходных кодов первым шагом должна быть команда# ./configure --prefix=/usr/local/squidSQUID будет установлен в каталог,

18.3. Настройка SQUID Сервер SQUID использует файл конфигурации squid.conf, который обычно располагается в каталоге /etc/squid (или /usr/local/squid/etc - более ранние версии). Подробнее на отдельных настройках мы остановимся чуть позже. А сейчас просто по шагам произведем настройку SQUID.

18.4. Запуск SQUID Первый раз squid нужно запускать с ключом -z, чтобы создать и очистить каталог кэша:# /usr/local/squid/bin/squid -zЕще несколько полезных ключей, с которыми можно запускать squid, перечислены в таблице 18.2.Ключи запуска squid Таблица 18.2 Ключ Назначение -а порт Задает

18.5. Расширенные настройки SQUID. Конфигурационный файл squid.conf 18.5.1. Параметры сети В файле squid.conf могут быть заданы следующие параметры сети:? http_port - порт для запросов клиентов. С этого порта прокси-сервер будет ожидать и обрабатывать запросы клиентов. Значение по умолчанию

18.8. Разделение канала с помощью SQUID Допустим, вам нужно настроить прокси-сервер таким образом, чтобы одна группа компьютеров работала в Интернете с одной скоростью, а другая - с другой. Это может потребоваться, например, для разграничения пользователей, которые

9.3. squid Как я уже сказал, самым распространенным прокси-сервером является squid. Этот сервер имеет достаточно длинную историю, и за время его существования в нем реализовано много возможностей. Еще не было ничего такого, что я не смог бы получить с помощью squid.Основной

9.4. Права доступа к squid Это самая больная тема для любого администратора. Да, и в squid тоже есть права доступа, и они также описываются в конфигурационном файле /etc/squid/squid.conf. Но мы рассматриваем права отдельно, потому что основной упор делаем на безопасность. Именно поэтому

9.5. Замечания по работе squid Сейчас нам предстоит немного поговорить о некоторых вопросах безопасности сервиса squid и дополнительных возможностях, которые могут ускорить работу в

12.5.4. Журнал прокси-сервера squid Основным журналом прокси-сервера squid является /var/log/squid/access.log. Это текстовый файл, в котором каждая строка состоит из следующих полей:? время начала соединения или события;? продолжительность сессии;? IP-адрес клиента;? результат обработки

Доброго времени, уважаемые читатели и гости! С данной статьи я начну описание работы кэширующего прокси-сервера SQUID . Эта статья в большинстве своем будет вводная теоретическая.

Что такое proxy-сервер и что такое squid

Начну с основ. squid является кэширующим прокси сервером для HTTP, FTP и др. протоколов. Прокси сервер для HTTP - это программа, выполняющая HTTP-запросы от имени клиентской программы (будь то браузер или другой софт). Proxy может быть кэширующим или не кэширующим . Кэширующий, соответственно, сохраняет все запросы в какое-либо хранилище для более быстрой отдачи клиентам, а не кэширующий - просто транслирует HTTP, ftp или другие запросы. Ранее, кэширование трафика позволяло добиться довольно значительной экономии трафика, но в настроящее время с ростом скоростей интернета это немного утеряло актуальность. Прокси серверА можно выстраивать в иерархии для обработки запросов. При этом, прокси серверА взаимодействуют между собой по протоколу ICP .

Squid разработан и может работать на большинстве операционных систем (как unix, так и windows). Лицензируется под лицензией GNU GPL. Способен обрабатывать и кэшировать HTTP, FTP, gopher, SSL и WAIS (убрано в 2.6) запросы, а так же DNS. Наиболее частые запросы хранит в оперативной памяти. На текущий момент существуют 2 стабильные версии squid : 2.7 и 3.1 . С отличиями можно ознакомиться в ссылках в конце статьи. Все зависимости при установке из пакетов у них одинаковые. Конфигурационный файл версии 2 совместим с версией 3, но в 3 версии добавлены новые параметры. В статье я буду рассматривать версию squid3 . Стоит так же заметить, что если устанавливать squid3 , то он свои конфигурационные файлы будет держать в /etc/squid3 , а так же логи по умолчанию в squid3 лежат в каталоге /var/log/squid3/ , а не /var/log/squid/ , как "любят считать" многие анализаторы логов.

Кучу раз упомянуто слово "кэширование ". А что же это, собственно, такое - кэширование ? Это способ хранения запрошенных из Интернет объектов на сервере, находящемся ближе к запрашивающему компьютеру нежели исходный. Интернет-объект это файл, документ или ответ на обращение к какому-либо сервису предоставляемому в Интернет (например, FTP, HTTP, или gopher). Клиент запрашивает интернет-объект из кеша прокси-сервера; если объект ещё не кеширован, то прокси-сервер получает объект (либо от узла сети указанного по запрошенному адресу URL, либо от родительского или соседнего кеша) и доставляет его клиенту.

Режимы работы прокси-сервера Squid

Прокси-сервер Squid может работать в следующих трех основных режимах:

Прозрачный режим

В этом режиме HTTP соединение осуществляемое клиентами перенаправляется на прокси-сервер без их ведома или явной конфигурации. В этом режиме не требуется настройка клиентов. Недостатки данного способа : необходима конфигурация NAT и перенаправления трафика, аутентификация клиентов не работает, не перенаправляются FTP и HTTPS запросы.

Аутентифицирующий режим

Для работы в этом режиме клиенты должны быть настроены для работы с прокси-сервером (в настройках соединения должен быть прописан адрес прокси-сервера). Может выполняться аутентификация и авторизация клиентов через Kerberos, Ldap, NTLM, IP и Radius. Возможно построение взаимодействия с серверами Microsoft Active Directory путем аутентификации клиентов – членов домена, используя протокол Kerberos, и последующей авторизации членов групп домена используя LDAP в прозрачном режиме (пользователь вводит свой пароль только при регистрации в домене). Для авторизированных групп возможно применение различных настроек контроля доступа и QoS (delay pools).

Обратный прокси-сервер

Прокси-сервер кэширует исходящие данные. Обратный прокси-сервер Squid получает данные у HTTP сервера от имени клиента и передает их обратно клиенту (например, в Интернет). Этот режим позволяет осуществить:

• Использование кэширования, которое снижает нагрузку на HTTP сервера;
• Распределение нагрузки между HTTP серверами;
• Маскировку HTTP серверов и их характеристик;
• Предотвращение web атак на сервера.

Схемы режимов работы SQUID

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

Установка SQUID

Перед установкой и настройкой squid необходимо и убедиться, что машина, на которой будет работать squid имеет доступ во внешнюю сеть и клиенты, которые будут использовать данный прокси имеют доступ к данной машине. Установка прокси-сервера squid как и другого ПО в Linux возможна различными способами, описанными в статье . Я затрону способ установки из репозитория в Debian. Итак, для установки squid необходимо установить пакет squid3, для этого выполнить вот такую команду:

Gw ~ # aptitude install squid3 Следующие НОВЫЕ пакеты будут установлены: libltdl7{a} squid-langpack{a} squid3 squid3-common{a} 0 пакетов обновлено, 4 установлено новых, 0 пакетов отмечено для удаления, и 0 пакетов не обновлено. Необходимо получить 2 157 kB архивов. После распаковки 10,3 MB будет занято. Хотите продолжить? y Получить:1 http://ftp.ru.debian.org/debian/ squeeze/main libltdl7 i386 2.2.6b-2 Получить:2 http://ftp.ru.debian.org/debian/ squeeze/main squid-langpack all 20100628-1 Получить:3 http://ftp.ru.debian.org/debian/ squeeze/main squid3-common all 3.1.6-1.2+squeeze2 Получить:4 http://ftp.ru.debian.org/debian/ squeeze/main squid3 i386 3.1.6-1.2+squeeze2 Получено 2 157 kБ в 9с (238 kБ/с) Выбор ранее не выбранного пакета libltdl7. (Чтение базы данных... на данный момент установлено 41133 файла и каталога.) Распаковывается пакет libltdl7 (из файла.../libltdl7_2.2.6b-2_i386.deb)... Выбор ранее не выбранного пакета squid-langpack. Распаковывается пакет squid-langpack (из файла.../squid-langpack_20100628-1_all.deb)... Выбор ранее не выбранного пакета squid3-common. Распаковывается пакет squid3-common (из файла.../squid3-common_3.1.6-1.2+squeeze2_all.deb)... Выбор ранее не выбранного пакета squid3. Распаковывается пакет squid3 (из файла.../squid3_3.1.6-1.2+squeeze2_i386.deb)... Обрабатываются триггеры для man-db ... Настраивается пакет libltdl7 (2.2.6b-2) ... Настраивается пакет squid-langpack (20100628-1) ... Настраивается пакет squid3-common (3.1.6-1.2+squeeze2) ... Настраивается пакет squid3 (3.1.6-1.2+squeeze2) ... Creating Squid HTTP proxy 3.x spool directory structure 2012/02/15 21:29:41| Creating Swap Directories Restarting Squid HTTP Proxy 3.x: squid3Creating Squid HTTP Proxy 3.x cache structure ... (warning). 2012/02/15 21:29:43| Creating Swap Directories .

Как видно, при установке пакета, была попытка создания каталога кэша , но т.к. он не настроен, то вывалилось предупреждение. Так же, squid добавлен в автозагрузку, запущен и принимает подключения на всех интерфейсах . Но т.к. он не настроен, доступ к интернет-страницам через сервер ограничен. Конфиг сквида расположен в /etc/squid3/squid.conf и состоит из более чем 5,5 тысяч строк и синтаксис его практически не отличается от конфига любого другого сервиса. Бросаться менять какие-то настройки срезу - не стоит. Потом не разгребете. Давайте рассмотрим конфиг, который нам предлагается по умолчанию без комментариев и пустых строк:

Gw ~ # grep -v ^# /etc/squid3/squid.conf | grep -v ^$ acl manager proto cache_object acl localhost src 127.0.0.1/32::1 acl to_localhost dst 127.0.0.0/8 0.0.0.0/32::1 acl SSL_ports port 443 acl Safe_ports port 80 # http acl Safe_ports port 21 # ftp acl Safe_ports port 443 # https acl Safe_ports port 70 # gopher acl Safe_ports port 210 # wais acl Safe_ports port 1025-65535 # unregistered ports acl Safe_ports port 280 # http-mgmt acl Safe_ports port 488 # gss-http acl Safe_ports port 591 # filemaker acl Safe_ports port 777 # multiling http acl CONNECT method CONNECT http_access allow manager localhost http_access deny manager http_access deny !Safe_ports http_access deny CONNECT !SSL_ports http_access allow localhost http_access deny all http_port 3128 hierarchy_stoplist cgi-bin ? coredump_dir /var/spool/squid3 refresh_pattern ^ftp: 1440 20% 10080 refresh_pattern ^gopher: 1440 0% 1440 refresh_pattern -i (/cgi-bin/|\?) 0 0% 0 refresh_pattern . 0 20% 4320

Как видно, в конфигурации по умолчанию, прокси-сервер работает и разрешает обращения только с адресов 127.0.0.0/8. Следует внимательно просмотреть весь список и закомментировать строки с портами не нужных или не используемых сервисов. Более полное понимание данного конфига будет после прочтения следующих разделов. Т.о. если мы запустим консольный браузер lunx с указанием на наш прокси, то сможем увидеть заданную страницу:

Gw ~ # # запускаем бреузер с указанием страницы ya.ru: gw ~ # http_proxy=http://127.0.0.1:3128 lynx ya.ru Идет поиск "ya.ru" сначала gw ~ # # в логе видим обращение к заданной странице: gw ~ # cat /var/log/squid3/access.log 1329527823.407 110 127.0.0.1 TCP_MISS/200 9125 GET http://ya.ru/ - DIRECT/93.158.134.203 text/html

Некоторыепараметры в конфигурационом файле squid могут применяться несколько раз (например acl). Некоторые параметры, особенно имеющие одно значение могут использоваться только один раз. При этом, при использовании такого параметра 2 и более раз - будет использовано последнее значение. Например:

Logfile_rotate 10 # Несколько значений - кончное будет равно 5 logfile_rotate 5

Управление squid

Параметры, с которыми был собран squid Вашего дистрибутива можно посмотреть командой squid3 -v. Например, в Debian squeezу squid собран с параметрами, приведенными ниже:

Prefix=/usr - префикс для других ключей: --mandir=${prefix}/share/man - каталог хранения man-страниц --libexecdir=${prefix}/lib/squid3 - каталог с исполняемыми модулями (в том числе и хелперы) --sysconfdir=/etc/squid3 - каталог хранения конфигурации --with-logdir=/var/log/squid3 - каталог хранения журналов и мн. др...

Настройка squid

Описание настроек squid3 начну с основных настроек , которые желательно произвести при настройке любой конфигурации прокси-сервера. Конфиг сквида расположен в /etc/squid3/squid.conf , это основной конфигурационный файл, в котором содержатся все настройки. (В дистрибутивах Debian и RedHat так же при запуске просматриваются параметры из стартовых файлов настроек /etc/default/squid3 и /etc/sysconfig/squid3 , соответственно). Так же, я упоминал, что там более 5 тысяч строк и что сразу рваться настраивать что-то не разобравшись - не стоит. Синтаксис конфига squid3 классический: строки с # - это комментарии, параметры представляют собой строки "параметр значение ", возможно использование . Конфигурационный файл разбит на разделы для удобства, но важно помнить, что разбор параметров производится "сверху вниз" в порядке очередности. Так же, с помощью параметра include можно подключать внешние конфигурационные файлы.

По умолчанию разрешение имени узла, на котором работает Squid, происходит при помощи gethostname(), в зависимости от установок DNS, он иногда не может однозначно определить имя, которое будет фигурировать в журналах и выводах об ошибках “Generated … by server.com (squid/3.0.STABLE2) ”. Для корректной записи имени хоста, необходимо это имя (FQDN??) занести в параметр:

Visible_hostname myproxy

По умолчанию, squid принимает подключения на всех интерфейсах. Если у нас сервер одним из сетевых интерфейсов смотрит во внешний мир, то желательно ограничить подключения только на интерфейсе локальной сети (допустим, 10.0.0.10/24). За это отвечает параметр http_port :

Http_port 10.0.0.10:3128

Как работают данные параметры можно увидеть в следующем листинге:

Gw ~ # # проверяем работу демона до настройки: gw ~ # netstat -antp | grep squ tcp 0 0 0.0.0.0:3128 0.0.0.0:* LISTEN 25816/(squid) gw ~ # # внесенные изменения: gw ~ # grep ^http_port /etc/squid3/squid.conf http_port 10.0.0.10:3128 gw ~ # # перечитываем измененный конфиг gw ~ # /etc/init.d/squid3 reload Reloading Squid HTTP Proxy 3.x configuration files. done. gw ~ # # проверяем работу с измененным конфигом: gw ~ # netstat -antp | grep squ tcp 0 0 10.0.0.10:3128 0.0.0.0:* LISTEN 25816/(squid)

Как видно, теперь демон работает только на интерфейсе заданной сети. Стоит так же отметить, что новые версии squid (<3.1) поддерживают задание нескольких параметров http_port. При этом, у разных параметров могут быть указанны дополнительные ключи такие как intercept, tproxy, accel и др., например:

Gw ~ # grep ^http_port /etc/squid3/squid.conf http_port 10.0.0.10:3128 http_port 10.0.0.10:3129 tproxy

Данные параметры задают режи работы прокси-сервера. Например tproxy (старый синтаксис - transparent) задает режим . Данные режимы достойны отдельных статей и в будущем возможно будет рассмотрены.

Теперь необходимо настроить клиентский компьютер и пользоваться интернетом. Но по умолчанию, доступ разрешен только с локалхоста и при попытке доступа к веб пользователь получит ошибку "Доступ запрещен". В логе /var/log/squid3/access.log будет примерно такое сообщение:

1329649479.831 0 10.0.1.55 TCP_DENIED/403 3923 GET http://ya.ru/ - NONE/- text/html

Для того, чтобы клиенты локальной сети могли работать, необходимо настроить разрешения с помощью списков контроля доступа .

Настройка доступа squid

Фактически настройка доступа заключается в описании объекта доступа через параметр acl , а затем разрешении или запрете работы описанному объекту acl при помощи параметра “http_access” . Простейший формат данных настроек имеет следующий вид:

Acl имя_списка тип_отбора характеристики_типа_отбора

где acl - параметр описывающий список контроля доступа , имя которого задается значением имя_списка . Имя чувствительно к регистру букв. тип_отбора задает тип, которому будет соответствовать заданная далее характеристика_типа_отбора . Данная характеристика может принимать такие часто используемые значения, как src (от source) - источник запроса, dst - адрес назначения, arp - МАС-адрес, srcdomain и dstdomain - доменное имя источника и назначения соответственно, port - порт, proto - протокол, time - время и многие другие . Соответственно, значение характиристики_типа_отбора будут формироваться в зависимости от типа_отбора .

Можно указывать несколько строк acl с одинаковыми именами и типами_отбора, в таком случае, данные acl будут объеденены в один список с логической операцией ИЛИ. Например:

Acl site dstdomain site.com acl site dstdomain site.org # аналогичен записи: acl site dstdomain site.com site.org

Словами это звучит так: списку доступа с именем site принадлежат все запросы, отправленные на сайт site.com ИЛИ site.org. Кроме того, имена_спаска чувствительны к регистру, то есть acl site и acl Site это 2 разных списка доступа.

Когда списки доступа сформированы, при помощи параметра http_access разрешаем или запрещаем доступ указанному ACL. Общий формат вызова такой:

Http_access allow|deny [!]имя_списка

где, http_access - параметр задающий последующее правило разрешения (allow ) или запрещения (deny ) доступ, указанному далее имени_списка . При этом, необязательный восклицательный знак инвертирует значение имени списка. То есть при восклицательном знаке значение имени_списка будет звучать как все, кроме тех, кто в принадлежит данному списку . Кроме того, можно задавать несколько списков через пробел, тогда доступ будет разрешен при условии принадлежности ко всем заданным спискам. При этом, все разрешающие правила необходимо указывать до запрещающего ВСЁ правила:

Http_access deny all

Может возникнуть резонный вопрос: зачем задавать данное правило, если мы, например, разрешим доступ к сквиду только избранным acl? Ведь остальные, кто не попадают в данный acl итак "проходят мимо"... Все просто. По-умолчанию, squid использует разрешающее/запрещающее правило противоположное последнему. Например:

# у нас есть единственное разрешеющее правило для некоторого acl user: http_access allow user # если при доступе к squid, клиент не попал в этот acl, то к нему будет применено действие deny. # А если у нас есть два правила http_access allow user http_access deny user2 # и клиент не входит ни в acl user, ни в acl user2, то к нему применится allow. # То есть действие противоположное последнему http_access deny user2

Это, как говориться - основы основ. Давайте рассмотрим простой пример. Предположим, у нас есть 2 сети 10.0.1.0/24 и 10.0.0.0/24, а так же хост 10.0.4.1, которым необходимо разрешить доступ к интернету. Для разрешения доступа необходимо создать описание нового списка доступа в секции "ACCESS CONTROL" файла squid.conf:

Acl lan src 10.0.1.0/24 10.0.0.0/24 acl lan src 10.0.4.1

Для бОльшего удобства, можно задать эти правила в отдельном файле, указав путь к нему в место характеристики_типа_отбора . Вот:

Gw ~ # # создадим отдельный каталог для хранения списков доступа gw ~ # mkdir /etc/squid3/acls/ gw ~ # # занесем наши подсети и хосты в отдельный файл gw ~ # vim /etc/squid3/acls/lan.acl gw ~ # cat /etc/squid3/acls/lan.acl 10.0.1.0/24 10.0.0.0/24 10.0.4.1 gw ~ # # опишем созданный файл в конфиге (путь необходимо заключить в кавычки) gw ~ # grep lan.acl /etc/squid3/squid.conf acl lan src "/etc/squid3/acls/lan.acl"

Разрешим созданному списку доступа lan доступ в интернет и скажем сквиду перечитать конфигурационный файл:

Gw ~ # grep lan /etc/squid3/squid.conf | grep acce http_access allow lan gw ~ # service squid3 reload Reloading Squid HTTP Proxy 3.x configuration files. done.

Подводя маленький итог данному разделу, в двух словах можно сказать, что acl идентифицирует Web запрос, а http_access разрешает или запрещяет идентифицированный запрос. Теперь наши локальные клиенты с радостью пользуются интернетом, предварительно настроив браузер!

Настройка параметров кэша squid

Важным моментом настройки squid является настройка параметров кэширования в squid . Место размещения кэша задается параметром cache_dir в squid.conf. Формат параметр следующий:

Cache_dir тип путь размер L1 L2

где, тип - это алгоритм формирования кэша, может быть: ufs (unix file system), aufs (async ufs), diskd (внешние процессы для избежания блокировки squid на дисковом вводе/выводе). Рекомендуется использовать ufs , хотя некоторые хвалят aufs . Путь - задает место размещения кэша в файловой системе (должен существовать и иметь права доступа на запись для пользователя, под которым работает squid - обычно proxy). Размер - задает максимальный размер, после которого кэш начнет очищаться. В сети существует множество холиваров по этому параметру. Идеальный размер кеша - от 2 до 10 ГБ в зависимости от числа клиентов. Приблизительно 1 ГБ кеша на каждые 100 тысяч запросов/день. Я придерживаюсь значения в 5 Гб. В Squid каждый кешируемый объект располагается в отдельном файле, сами файлы не сваливаются в одно место, а используется двухуровневая иерархия каталогов. Количество каталогов 1 и 2 уровней и определяют параметры L1 и L2 . Эти значения можно оставить по умолчанию. Но для ориентирования в ситуации приведу цитату с bog.pp.ru:

Эксперимент показал, что при кэше в 700 МБ используется только 2 директории первого уровня. То есть для при стандартной структуре директорий кеша в него "с комфортом" влезает миллион объектов (9 GB), если их больше, то надо увеличить число директорий верхнего уровня

Можно использовать несколько cache_dir . Это положительно сказывается на производительности, особенно, если разместить кэш на разных дисках. Еще больше ускорить работу кэша можно, разместив кэш в tmpfs. Для каждого параметра cache_dir можно в разделе options определить параметр read-only (только чтение) и max-size (максимальный размер объекта).

Максимальный размер объекта в кэше определяется параметром maximum_object_size , значение по умолчанию - 4 Мб. Я данное значение увеличил до 60 Мб, т.к. сотрудникам в локальной сети часто приходится скачивать однотипные файлы до указанного размера:

Maximum_object_size 61440 KB

Аналогично? есть и параметр minimum_object_size отвечающий за минимальный размер объекта, по умолчанию его значение “0” то есть отключен. Я рекомендую значение этого параметра увеличить до 2-3 Кб, что снизит нагрузку на диск при поиске маленьких объектов.

Объем ОЗУ , используемый сквидом задается в параметре cache_mem , значение по умолчанию 256 Мб (в версии 3.1). Данное значение я оставил по умолчанию. Менять это значение стоит лишь в том случае, если сквид вас об этом попросит в логах. После данных изменений, необходимо перезапустить сквид, при этом будет создана структура каталогов:

Gw ~ # service squid3 start Starting Squid HTTP Proxy 3.x: squid3Creating Squid HTTP Proxy 3.x cache structure ... (warning). 2012/02/19 22:58:21| Creating Swap Directories 2012/02/19 22:58:21| /var/spool/squid3 exists 2012/02/19 22:58:21| Making directories in /var/spool/squid3/00 2012/02/19 22:58:21| Making directories in /var/spool/squid3/01 2012/02/19 22:58:21| Making directories in /var/spool/squid3/02 2012/02/19 22:58:21| Making directories in /var/spool/squid3/03 2012/02/19 22:58:21| Making directories in /var/spool/squid3/04 2012/02/19 22:58:21| Making directories in /var/spool/squid3/05 2012/02/19 22:58:21| Making directories in /var/spool/squid3/06 2012/02/19 22:58:21| Making directories in /var/spool/squid3/07 2012/02/19 22:58:21| Making directories in /var/spool/squid3/08 2012/02/19 22:58:21| Making directories in /var/spool/squid3/09 2012/02/19 22:58:21| Making directories in /var/spool/squid3/0A 2012/02/19 22:58:21| Making directories in /var/spool/squid3/0B 2012/02/19 22:58:21| Making directories in /var/spool/squid3/0C 2012/02/19 22:58:21| Making directories in /var/spool/squid3/0D 2012/02/19 22:58:21| Making directories in /var/spool/squid3/0E 2012/02/19 22:58:21| Making directories in /var/spool/squid3/0F .

Много интересных вопросов и ответов на них по использованию кэша и памяти squid"ом описано . На этом, можно считать типовое решение по настройке прокси-сервера законченным.

Пример настройки прозрачного прокси squid

Что есть прозрачный прокси ? Это режим работы прокси сервера, когда клиент не настраивается на работу через прокси и посылает запросы в сеть по протоколу HTTP, как если бы клиент браузер работал напрямую с веб-сервером. При этом, силами (в linux - ) исходящие запросы на HTTP направляются на порт, на котором запущен прокси. Прокси-сервер же, в свою очередь, преобразовывает HTTP запросы в запросы протокола прокси-сервера и посылает ответы клиенту, как веб сервер. Т.о. для клиента прозрачно происходит взаимодействие с прокси-сервером.

Важно понимать и знать! Данный метод поддерживает только HTTP протокол , и не поддерживает gopher, FTP или другое проксирование. А так же, Squid не умеет одновременно работать в прозрачном режиме и в режиме аутентификации.

Для настройки прозрачного режима, необходимо:

1. Задать прозрачный режим в настройках прокси. Это делается в параметре http_port , например:

Http_port ip:port transparent

2. Завернуть пользователей соответствующим правилом на нужный порт силами iptables:

Iptables -t nat -A PREROUTING -i имя_входящего_интерфейса -s подсеть_локльной_сети -p tcp --dport 80 -j REDIRECT --to-port порт_squid, пример: iptables -t nat -A PREROUTING -i eth1 -s 10.0.0.0/24 -p tcp --dport 80 -j REDIRECT --to-port 3128

Все. Можно наслаждаться завернутыми и ничего не подозревающими пользователями на наш прокси-сервер.

Траблешуттинг

В первую очередь, диагностика работы squid заключается в просмотре журналов , расположенных в /var/log/squid3 . Большинство проблем решается данным способом. Если это не помогло решить проблему, то переключив демона в дебаг режим командой squid3 -k debug проблему будет найти проще. Собственно, что из себя представляет лог сквида? Файлы логов содержат различную информацию о загрузке и производительности Squid. В log пишутся кроме информации о доступе, /preеще и системные ошибки и информация о потреблении ресурсов, таких, например, как память или дисковое пространство.

Формат log файлов Squid представляет собой строку из значений, разделенных одним или несколькими пробелами:

Время.мс время_отклика ip_src Squid_req_status/HTTP_status byte_snd метод URL user squid_her_status/ip_dst MIME

• время - время в формате unix (Количество секунд от 00:00 1970.01.01)
• мс - миллисекунды с точностью до 3х знаков
• время_отклика - время отклика, миллисекунд
• ip_src - IP адрес источника
• Squid_req_status - статус запроса у squid (например, TCP_HIT для ранее кешируемых объектов, TCP_MISS если запрашиваемый объект взят не из локального кеша, UDP_HIT и UDP_MISS то же для братских запросов)
• HTTP_status - статус http протокола (200 для удачных, 000 для UDP запросов, 403 для перенаправлений, 500 для ошибок)
• byte_snd - передано, байт в ответ включая HTTP заголовок
• метод - метод запроса GET или POST
• URL - запрошенный url-адрес
• user - имя авторизованного пользователя
• squid_her_status - статус иерархии squid - Результат запросов к братским/родительским кешам
• ip_dst - IP адрес запрашиваемого узла
• MIME - mime-type

Рассмотрим на примере:

1329732295.053 374 10.0.1.55 TCP_MISS/200 1475 GET http://www.youtube.com/live_comments? - DIRECT/173.194.69.91 text/xml

Как видно, запрос сделан в 1329732295.053, ответ удаленного сервера составил 374 мс, хост, запросивший страницу имеет IP 10.0.1.55, запрошенный объект был передан не из локального кэша (TCP_MISS), код ответа сервера - 200, клиенту передано 1475 байт методом GET, был запрошен URL http://www.youtube.com/live_comments?, имя пользователя не определено, объект был получен напрямую от сервера с IP 173.194.69.91, был передан текст, т.к. mime - text/xml. Вот.

Некоторые заключительные моменты о squid3

В статье я рассмотрел основные принципы работы прокси сервера, а так же, базовые настройки, позволяющие реализовать простейший кэширующий сервер, а так же организовать работу squid в прозрачном (transparent) режиме. Squid поддерживает несколько вариантов авторизации (по IP, через LDAP, MySQL, NTLM и др.), возможности ограничения пропускной способности канала и контроля доступа к ресурсам интернет. Работу сквида с методами различной авторизации и примеры контроля трафика я рассмотрю в следующих статьях.

Недавно в нашей компании возникла необходимость перевести прокси-сервера с MS ISA Server на свободное ПО. Прокси-сервер долго выбирать не пришлось (squid). Воспользовавшись несколькими практическими рекомендациями, настроил прокси под наши нужды. Некоторые затруднения возникли при выборе программы для учета трафика.

Требования были такие:

1) свободное ПО
2) возможность обработки логов с различных прокси на одном сервере
3) возможность построения стандартных отчетов с отправкой по почте, либо ссылка на веб-сервере
4) построение отчетов по отдельным подразделениям и рассылка таких отчетов руководителям подразделений, либо предоставление доступа по ссылке на веб-сервере

По программам учета трафика разработчиками представлена весьма скудная информация: лаконичное описание назначение программы плюс необязательным бонусом пара скриншотов. Да, понятно, что любая программа подсчитает количество трафика за сутки/неделю/месяц, а вот дополнительные интересные возможности, отличающую одну программу от других - не описаны.

Я решил написать этот пост, в котором попытаюсь описать возможности и недостатки таких программ, а так же некоторые их ключевые «фишки», чтобы немного помочь в выборе тем, кому его предстоит сделать.

Наши кандидаты:

SARG
free-sa
lightsquid
squidanalyzer
ScreenSquid

Отступление

Информация о «возрасте» программы и выходе последнего релиза не является параметром сравнения и приводится только для сведения. Постараюсь сравнить исключительно функционал программы. Так же я намеренно не стал рассматривать слишком старые программы, которые не обновлялись много лет.

Логи передаются на обработку анализатору в том виде, как их создал squid и не будут подвергаться какой-либо предварительной обработке с целью внесения в них изменений. Обработка некорректных записей и всевозможные преобразования полей логов должны вноситься самим анализатором и присутствовать только в отчете. Данная статья не является инструкцией по настройке. Вопросы конфигурирования и использования могут быть освещены в отдельных статьях.

Итак, приступим.

SARG - Squid Analysis Report Generator

Старейшина среди поддерживаемых программ такого класса (разработка начата в 1998 году, прежнее название - sqmgrlog). Последний релиз (версия 2.3.10) - апрель 2015 года. После этого было несколько доработок и исправлений, которые доступны в master-версии (можно скачать с помощью git с sourceforge).

Запуск программы производится вручную либо по cron-у. Запустить можно без параметров (тогда все параметры будут взяты из файла конфигурации sarg.conf), либо можно указать параметры в командной строке или скрипте, например даты, за которые строится отчет.

Отчеты создаются в виде html-страниц и складываются в каталог /var/www/html/squid-reports (по умолчанию). Можно задать параметр, задающий количество хранимых отчетов в каталоге. Например, 10 ежедневных и 20 недельных, более старые будут автоматически удаляться.

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

Подробно

При входе на главную страницу с отчетами можем выбрать период, за который он создан (определяется в параметрах создания отчета), дата его создания, количество уникальных пользователей, суммарный трафик за период, среднее количество трафика на пользователя.

При выборе одного из периодов сможем получить отчет topusers за этот период. Далее приведу описания и примеры всех типов отчетов, которые умеет делать SARG.

1) topusers - суммарный трафик по пользователям. Под пользователем понимается либо имя хоста, которому предоставлен доступ в Интернет, либо логин пользователя. Пример отчета:

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

Используете аутентификацию? Учетные записи преобразуются в реальные имена:

Внешний вид может быть настроен в css-файле. Выводимые столбцы тоже настраиваются, ненужные можно убрать. Поддерживается сортировка столбцов (sorttable.js).

При нажатии на иконку с графиком слева увидим подобный график:

При нажатии на иконку справа получим отчет 5.

2) topsites - отчет по самым популярным сайтам. По умолчанию выводится список из 100 самых популярных сайтов (значение корректируется). С помощью регулярных выражений или задания псевдонимов можно объединить трафик доменов 3-го и более высоких уровней до домена 2-го уровня (как на скриншоте) или задать любое другое правило. Для каждого домена можно задать правило отдельно, например, для yandex.ru и mail.ru объединять до 3-го уровня. Значение полей вполне очевидно.

3) sites_users - отчет о том, кто заходил на определенны сайт. Тут все просто: имя домена и кто к нему обращался. Трафик тут не отображается.

4) users_sites - отчет о посещенных сайтах каждым пользователем.

Тут тоже все понятно. Если нажать на иконку в первом столбце, получим отчет viii).

5) date_time - распределение трафика пользователя по дням и часам.

6) denied - заблокированные squid-ом запросы. Здесь отображается кому, когда и куда в доступе было отказано. Количество записей настраивается (по умолчанию - 10).

7) auth_failures - отказы в аутентификации. HTTP/407.
Количество записей настраивается (по умолчанию - 10).

8) site_user_time_date - показывается в какое время на какой сайт и с какой машины заходил пользователь.

9) downloads - список загрузок.

10) useragent - отчет об используемых программах

В первой части отчета отображается IP-адрес и использованные useragent"ы.

Во второй - общий список useragent"ов с распределением в процентах с учетом версий.

11) redirector - отчет показывает кому был заблокирован доступ средствами блокировщика. Поддерживаются squidguard, dansguardian, rejik, формат логов настраивается.

У SARG более 120 параметров настройки, поддержка языков (на русский язык переведено 100% сообщений), поддержка регулярных выражений, работа с LDAP, возможность предоставления пользователям доступа только к своим отчетам на web-сервере (через.htaccess), возможность преобразования логов в свой формат для экономии места, выгрузка отчетов в текстовый файл для последующего заполнения базы данных, работа с файлами логов squid (разбиение одного или нескольких лог-файлов по дням).

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

Можно отправлять отчеты по e-mail, правда, пока поддерживается только отчет topusers, а само письмо будет простым текстовым без поддержки HTML.

Можно исключить из обработки определенных пользователей или определенных хосты. Можно задавать псевдонимы для пользователей, объединяя трафик нескольких аккаунтов в один, например, всех аутстафферов. Также можно задать псевдонимы для сайтов, например, объединить в некий псевдоним несколько социальных сетей, в этом случае все параметры по указанным доменам (количество соединений, объем трафика, время обработки) будут просуммированы. Или с помощью регулярного выражения можно «отбросить» домены выше 3-го уровня.
Возможна выгрузка в отдельные файлы списка пользователей, превысившие определенные объемы за период. На выходе будет несколько файлов, например: userlimit_1G.txt - превысившие 1 Gb, userlimit_5G.txt - превысившие 5 Gb и так далее - всего 16 лимитов.

Еще SARG имеет в своем арсенале пару PHP-страниц: просмотра текущих подключений к squid и для внесения доменных имен в списки блокировки squidguard.

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

free-sa

Отечественная разработка. С ноября 2013 года новых версий не было. Заявлено более быстрое создание отчетов по сравнению с конкурирующими программами и меньший объем занимаемого места для готовых отчетов. Проверим!

Ближе всего по логике работы эта программа к SARG (да и автор сам сравнивает с этой программой (например, )), поэтому и мы сравнивать будем с ним.

Порадовало наличие нескольких тем оформления. Тема представляет собой 3 css-файла и 4 png-иконки, им соответствующие.

Отчеты действительно делаются быстрее. Дневной отчет создался за 4:30, когда у SARG за 12 минут. Правда, с занимаемым объемом оказалось не так: объем, занимаемый отчетами - 440 МБ (free-sa) и 336 МБ (SARG).

Попробуем дать задание посложнее: обработать лог-файл объемом 3,2 ГБ за 10 дней, в котором 26,3 млн строк.

Free-sa также сделал отчет быстрее, за 46 минут, отчет занимает 3,7 ГБ на диске. SARG потратил 1 час 10 минут, отчет занимает 2,5 ГБ.

Но оба эти отчета будет неудобно читать. Кому, например, захочется вручную считать, какой домен популярнее - vk.com или googlevideo.com и подсчитывать вручную трафик всех их поддоменов? Если в настройках SARG оставить только домены 2-го уровня, то создание отчета займет примерно столько же времени, но теперь уже сам отчет занимает на диске 1,5 ГБ (дневной с 336 МБ уменьшился до 192 МБ).

Подробно

При входе на главную страницу видим примерно следующее (выбрана тема blues):

Честно говоря, непонятно назначение вывода года и месяцев, при нажатии на них ничего не происходит. В поле поиска можно что-то написать, но опять же ничего не происходит. Можно выбрать интересующий период.

Список заблокированных URL:

Отчет CONNECT metdod:

Отчет PUT/POST metdod:

Популярные сайты:

Интересным показался отчет об эффективности прокси-сервера:

Отчет по пользователям:

При нажатии на значок графика во второй колонке получим график использования сети Интернет конкретным пользователем:

При нажатии на вторую иконку получим таблицу загрузки интернет-канала по часам:

При выборе IP-адреса получим список сайтов по пользователю в порядке убывания трафика:

Вся статистика отображается в байтах. Для переключения на мегабайты необходимо выставить параметр

reports_bytes_divisor=«M»

Программа не принимает сжатые файлы логов, не принимает больше одного файла с параметром -l, не поддерживает отбор файлов по маске. Автор программы предлагает обойти эти ограничения созданием именованных каналов.

Обнаружен досадный глюк - когда длина строки лога слишком большая, вместо адресов вписываются timestamp"ы:

При просмотре трафика этого «пользователя» можно увидеть домен с источником ошибки:

Таким образом, количество пользователей возросло в несколько раз.

Если сравнивать эти две программы, то free-sa создает отчет чуть быстрее. 20-кратного увеличения скорости, как заявлено автором, мне не удалось обнаружить. Возможно, ее можно увидеть при каких-то определенных условиях. Думаю, непринципиально сколько займет создание недельного отчета ночью - 30 минут или 50. По объему занимаемого отчетами места у free-sa преимущества нет.

lightsquid

Пожалуй, самая популярная считалка трафика. Работает быстро, отчеты занимают не много дискового пространства. Хоть эта программа и не обновлялась давно, я все же решил в этой статье рассмотреть ее возможности.

Логика работы программы иная: программа считывает журнал и создает набор файлов с данными, которые потом использует для создания веб-страниц. То есть заранее созданных отчетов с данными здесь нет, страницы с данными генерируются «на лету». Плюсы такого решения очевидны: для получения отчета не обязательно парсить все логи за период, достаточно раз в день «скармливать» lightsquid-у накопившийся журнал. Можно по cron-у делать это несколько даже несколько раз в день, чтобы быстро добавить новую порцию информации.

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

Есть странное ограничением: lightsquid «воспринимает» как несжатые файлы логов, как и сжатые (gz - точно), но во втором случае имя файла должно быть в таком формате: access.log.X.gz, файлы с форматом имени access.log-YYYYMMDD.gz не воспримет.

Путем нехитрых манипуляций преодолеваем это ограничение и смотрим что получилось.

Подробно

Отчет за месяц (суммарный трафик 3 Тб, 110 млн строк) занял на диске 1 Гб.

На начальной странице видим трафик по дням за текущий месяц.

При выборе дня видим отчет за день по всем пользователям:

Если заданы группы, в правой колонке отображается название группы, к которой принадлежит пользователь. Пользователи, не входящие ни в одну группу, объединяются в группу 00 no in group (в данном отчете они помечены вопросительным знаком).

При выборе на главной странице grp на соответствующую дату попадаем на страницу отчета пользователей, разбитых по группам. Сначала перечисляются не входящие ни в какую группу, затем группы по порядку.

При нажатии на название группы в таблице справа переходим ниже на место в странице, где начинается отчет по данной группе:

При нажатии на «Top sites report» получаем отчет по популярным сайтам за день:

Big files report:

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

Статистика за месяц:

При нажатии на значок с часами сможем увидеть таблицу по сайтам, времени доступа и потребленному в час трафику:

Здесь отображена статистика за день, но за месяц и за год будет выглядеть примерно так же, часовые статистики по доменам просуммируются.

При нажатии на значок графика можем увидеть потребление трафика пользователем в течение месяца:

Столбцы графика кликабельны: при нажатии на столбец переходим на статистику пользователя за другой день.

При нажатии на [M] получим отчет по потреблению трафика пользователем в течение месяца с указанием объёма за каждый день и за полную неделю.

При нажатии на имя пользователя получаем список сайтов, на которые заходил пользователь в порядке убывания трафика:

Ну вот вроде бы и всё. Все просто и лаконично. IP-адреса могут быть преобразованы в доменные имена. С помощью регулярных выражений доменные имена могут быть объединены в домены 2-го уровня, на всякий случай привожу регулярное выражение:

$url =~ s/(+://)??(+.){0,}(+.){1}(+)(.*)/$3$4/o;

При навыках в perl можно доработать под себя.

squidanalyzer

Схожая с lightsquid программа и тоже написана на Perl. Более симпатичное оформление. Последняя на текущий момент версия 6.4 выпущена в в середине декабря этого года, сделано много улучшений. Сайт программы: squidanalyzer.darold.net .

Squidanalyzer может использовать несколько процессоров компьютера (параметр -j), благодаря чему отчеты делаются быстрее, но это применимо только к несжатым файлам. Для запакованных (поддерживается формат gz) обработка происходит с использованием одного ядра процессора.

И еще одно сравнение с lightsquid: тот же самый отчет на том же самом сервере делался около суток, на диске занимает 3,7 ГБ.

Так же как и lightsquid, squidanalyzer не сможет объединить два и более лог-файла с разных серверов за один и тот же период.

Подробнее

Главная страница - можно выбрать год отчета.

При выборе любого периода (год, месяц, неделя, день) внешний вид веб-страниц будет схожим: сверху меню со следующими отчетами: MIME types, Networks, Users, Top Denied, Top URLs, Top Domains. Чуть ниже статистика прокси за выбранные период: Requests (Hit/Miss/Denied), Megabytes (Hit/Miss/Denied), Total (Requests/Megabytes/Users/Sites/Domains). Далее график по количеству запросов за период и по трафику.

В правом верхнем углу есть календарь. При выборе какого-нибудь месяца можно увидеть краткую статистику и график загрузки по дням:

В календаре есть возможность выбора недели. При выборе увидим похожую статистику:

При выборе дня видим статистику по часам:

Отчет по типу контента:

Отчет по сетям.

Отчет по пользователям.

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

Запрещенные ресурсы:

Отчет по доменам 2-го уровня.

От себя бы хотел отметить очень медлительную работу программы по мере накопления информации. С каждым новым логом пересчитывается статистика за неделю, месяц и год. Поэтому рекомендовать эту программу для обработки логов с сервера с большим количеством трафика я бы не стал.

screensquid

У этой программы другая логика: журнал импортируется в базу данных MySQL, затем данные запрашиваются из нее при работе в веб-интерфейсе. База с обработанным десятидневным логом, упомянутым ранее, занимает 1,5 Гб.

Подробнее

Программа не может импортировать файлы логов с произвольным именем, привязка только к access.log.

Главная страница:

Краткая статистика:

Для IP-адресов можно создать псевдонимы:

… а потом их можно объединить в группы:

Переходим к основному - отчетам.

Слева меню с типами отчетов:

Трафик пользователей логины
Трафик пользователей IP адреса
Трафик сайтов
Топ сайтов
Топ пользователей
Топ IP адресов
По времени суток
Трафик пользователей логины расширенный
Трафик пользователей IP адреса расширенный
Трафик IP адреса с резолвом
Популярные сайты
Кто качал большие файлы
Трафик по периодам (дни)
Трафик по периодам (имя дня)
Трафик по периодам (месяцы)
HTTP статусы
IP адреса логинов
Логины с IP адресов

Примеры отчетов.

Трафик пользователей IP адреса:

Трафик сайтов:

Топ сайтов:

… далее, если честно, не хватило терпения для изучения возможностей, поскольку страницы стали генерироваться по 3-5 минут. Отчет «по времени суток» за день, лог за который вообще не импортировался, создавался более 30 секунд. За день с трафиком - 4 минуты:

На этом все. Надеюсь, этот материал кому-нибудь пригодится. Всем спасибо за внимание.