Для инсталляции Squid используется команда:

Apt-get install squid3

Когда установка завершится, сервис запустится автоматически.

Перейдём к настройке. Файл конфигурации расположен по адресу /etc/squid3/squid.conf . Для неподготовленного пользователя он может показаться совершенно необъятным — в нём более 7000 строк. Большая часть из них закомментированы и описывают значительную часть всех возможных вариантов работы Squid.

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

При необходимости перед началом настройки можно обратиться к официальной документации проекта .

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

Основной инструмент настройки Squid — это списки контроля доступа или ACL (Access Control List) . ACL объявляются директивой, имеющей следующий синтаксис:

acl имя параметр элементы_списка

Параметр даёт серверу понять тип элементов списка. АCL с параметром port содержит номера портов, а с параметром src — ip-адреса, с которых на сервер поступает запрос. Полный список параметров весьма обширен и доступен в официальной документации.

Таким образом, строка

добавляет в список Safe_ports, содержащий элементы типа “порт”, новое значение 80.

Директива http_access, имеющая формат

http_access указание имя_acl

определяет правила работы с элементами указанного acl. Например, строка:

блокирует все порты, не входящие в список Safe_ports.

По умолчанию доступ к Squid разрешен только с самого сервера:

Чтобы открыть доступ клиентам локальной сети создадим для них новый список доступа c параметром src:

И разрешим доступ:

Теперь укажем порт, на котором работает Squid, и установим прозрачный режим работы:

Минимальная настройка конфигурационного файла Squid завершена, теперь можно перейти к описанию политики информационной безопасности.

Параметр src позволяет регулировать доступ для клиентов со статичными ip-адресами:

Параметр dst позволяет указать список ip-адресов назначения, к которым клиент желает получить доступ:

Параметр dstdomain даёт возможность указывать домен, к которому выполняется запрос:

Если необходимо указать домен источника, используется параметр srcdomain .

Параметры srcdom_regex и dstdom_regex позволяют использовать в ACL регулярные выражения:

Acl SitesRegexFree dstdom_regex free #сайты, содержащие в доменном имени слово “free” acl SitesRegexComOrg dstdom_regex \.com$ \.org $ #сайты доменных зон.com и.org http_access deny SingleUser SitesRegexFree http_access deny SingleUser SitesRegexComOrg

Ключ -i необходим для игнорирования регистра символов в регулярных выражениях:

acl имя [-i] url_regex элементы_списка

С помощью параметра url_regex возможно указать шаблон регулярного выражения для URL:

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

Ограничение пользователей по времени осуществляется с помощью параметра time:

acl имя time дни чч:мм-ЧЧ:ММ

Где день: M — Понедельник, T — Вторник, W — Среда, H — Четверг, F — Пятница, A — Суббота, S — Воскресенье.

Важно отметить что время начала промежутка должно быть всегда меньше времени конца. Например, возможно указать вариант 00:00-23:59, но промежуток 20:00-09:00 придётся разбить на 20:00-23:59 и 00:00-09:00.

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

Acl WeekendTime time AS 10 :00 -15 :00 #обозначим некоторый временной промежуток для выходных дней: http_access allow SingleUser WeekendTime MusicMP3 #разрешим пользователю достум к файлам формата mp3 в выбранный промежуток времени http_access deny SingleUser MusicMP3 #и запретим в любое другое время

Параметр proto позволяет указывать протокол передачи информации:

acl имя_acl proto список

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

Ограничения по скорости

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

• автоматическое резервное копирование данных с сервера компании и прочие процессы передачи больших объемов данных, выполняющиеся сервером по расписанию;
• операции передачи файлов для личных и рабочих нужд, особенно своей способностью использовать все доступные сетевые ресурсы известен протокол BitTorrent;
• технические неисправности в отдельных компьютерах и программах, а так же действия вредоносных программ;
• злонамеренные сетевые атаки на отдельные компьютеры локальной сети.

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

Работу пулов регулируют три директивы: delay_class , delay_parameters , delay_access .

Количество пулов устанавливает директива delay_pools:

delay_pools количество_объявленных_пулов

Создадим несколько пулов:

Пулы могут быть трёх классов:

• Один кран на всю сеть ограничивает поток воды;
• Весь поток ограничен одним краном, после которого идут отдельные персональные краны(для каждого IP-адреса сети);
• Весь поток ограничен одним краном, от которого идут отдельные краны для каждой группы пользователей(подсети), каждый из которых, в свою очередь, делится на персональные краны для каждого клиента(для отдельного IP-адреса).

Класс пула должен быть указан в директиве delay_class:

delay_class номер_пула класс_пула

Укажем класс пула:

Директива delay_parameters устанавливает параметры пула:

delay_parameters номер_пула параметры

Формат записи параметров зависит от выбранного класса пула:

Для пула №1 выбран класс 1, установим для него скорость передачи данных в 512 кбит/с:

Запись параметра производится по следующим правилам: сперва указывается ограничение скорости, затем указывается лимит, после которого это ограничение начинает действовать. Таким образом значение параметра 64000/64000 говорит о том, что после того, как пользователь скачал на максимальной скорости первые 64Кб запроса, на клиента накладывается ограничение скорости в 512 Кбит/с. Удобно устанавливать второе значение параметра несколько больше чем первое, например конфигурация:

позволяет пользователю получить первые 256Кбайт запроса на максимальной скорости и только потом ограничить клиента шириной канала в 512 Кбит/с.

Теперь можно распространять действие пула на отдельных клиентов сети при помощи директивы delay_access , имеющей формат:

delay_access номер_пула действие имя_acl

Параметр “ действие” имеет значения allow (разрешить) и deny (запретить). Пул будет действовать на тех клиентов, которым он разрешен и не будет действовать на тех, кому запрещён.

Например, конфигурация:

распространяет действия пула №1 на отдельного пользователя SingleUser, но не затрагивает группу пользователей UserGroup.

Для группы пользователей используем пул №2:

Опишем ограничения:

Применим ограничения пула №2:

Настройка кэширования

Прокси-сервер Squid поддерживает два вида кэширования — кэш в оперативной памяти и на жестком диске. При их настройке стоит помнить, что кэширование в принципе может ускорить скорость обработки запросов, но может вызвать и обратный эффект — в случае неверно подобранных параметров конфигурации. Также немаловажным является тот факт, что любое кэширование влечет дополнительную нагрузку на ресурсы сервера, в частности, слишком большой объем кэша в RAM может полностью парализовать работу сервера, спровоцировав нехватку оперативной памяти.

В стандартной конфигурации Squid включен только RAM кэш, объем используемой памяти установлен на 256Мб. Увеличим объем кэша и установим максимальный размер кэшированного объекта с помощью соответствующих директив:

Cache_mem 1024 MB # объем доступной для кэширования памяти maximum_object_size_in _memory 512 KB # максимальный размер объекта в кэше

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

За использование HDD кэша отвечает директива cache_dir , имеющая формат:

cache_dir тип_хранилища путь_к_хранилищу размер L1 L2

Cache_dir ufs /var /squid_cache 1024 16 256

Размер кэша на диске указывается в мегабайтах, в примере выше кэш с максимальным размером 1 Гб будет хранится в папке /var/squid_cache . Тип хранилища ufs стандартный. Параметры 16 и 256 указывают количество директорий первого и второго уровня, эти значения так же прописаны в документации как стандартные.

Максимальный размер объекта в дисковом кэше также можно указать:

Настройка логирования

Squid имеет мощную систему подробного логирования для контроля проходящего через прокси-сервер траффика. Логи делятся на три различных журнала:

• access.log — содержит записи о запросах клиентов;
• store.log — содержит записи, относящиеся к действиям с кэшем;
• cache.log — содержит сообщения об ошибках, возникающих при работе Squid.

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

Параметр, имеющий в примере значение “squid” определяет формат лог-файла. Можно задать формат лога “common” для того, чтобы можно было обрабатывать полученный журнал сторонними программами, но в таком случае стоит помнить, что этот формат лога не содержит всей информации, которая есть в логе по умолчанию. Помимо стандартных вариантов имеется возможность создать собственный формат лог-файла, используя директиву logformat. Подробную информацию о работе этой директивы можно найти в документации к продукту.

Директивы cache_log и cache_store_log позволяют указать путь к файлам cache.log и store.log соответственно. Они не требуют указания формата:

Cache_log daemon:/etc/squid3/logs/cache .log cache_store_log daemon:/etc/squid3/logs /store .log

Помимо различных видов журналов Squid имеет настройку уровней логирования. За глубину отладки отвечает директива debug_options . У неё два обязательных параметра — секция и глубина отладки:

Значение секции рекомендуется оставлять ALL (либо осторожно выбирать конкретную секцию из списка). Уровень логирования же может менятся в диапазоне от 1 до 9, где с ростом уровня увеличивается подробность логов, и, соответственно, количество записей в журнале. Как правило, уровень выше 5 редко используется в реальной жизни, потому что выводит уже слишком много “избыточной” информации для каждого произошедшего события.

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

Значение 31 означает, что при создании нового файла логов старый получит расширение от 0 до 30 и дальнейшая запись в него вестись не будет. Создание нового файла логов производится с помощью команды:

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

Если даже с самым низким уровнем логирования объем логов возрастает до нежелательных масштабов — стоит применить дополнительные средства, вроде автоматического сжатия журналов или переноса их в отдельное хранилище. Так же можно изменить количество или частоту ротаций в зависимости от задачи. Можно хранить меньшее количество логов, либо чаще создавать свежий журнал, а старый архивировать и перемещать. Для прокси-сервера Squid есть множество надстроек и сторонних программ, упрощающих все этапы работы с лог-файлами.

Оставим без изменений остальные параметры и проверим файл настроек с помощью команды:

Эта команда предназначена для поиска ошибок в конфигурационном файле, если она ничего не выводит — значит ошибок нет.

Теперь осталось применить новые параметры:

После завершения настройки прокси-сервера перенаправим на него весь трафик локальной сети, внеся изменения в файл /etc/nat командой:

Добавим в самый низ файла следующую строку:

После этого перезагрузим сервер для автоматического применения новых настроек:

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

Доброго времени, уважаемые читатели и гости! С данной статьи я начну описание работы кэширующего прокси-сервера 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 и др.), возможности ограничения пропускной способности канала и контроля доступа к ресурсам интернет. Работу сквида с методами различной авторизации и примеры контроля трафика я рассмотрю в следующих статьях.

Squid - это полнофункциональное приложение кэширующего прокси сервера, которое предоставляет сервисы кэширования и прокси для HTTP , FTP и других популярных сетевых протоколов. Squid может осуществлять кэширование и проксирование SSL запросов и кэширование результатов DNS поиска, а также выполнять прозрачное кэширование. Squid также поддерживает широкий набор кэширующих протоколов, таких как ICP (кэширующий интернет протокол), HTCP (гипертекстовый кэширующий протокол), CARP (протокол кэширования маршрутизации) и WCCP (кэширующий протокол перенаправления контента).

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

Установка

В терминале введите следующую команду для установки сервера Squid:

Sudo apt-get install squid

Настройка

Squid настраивается редактированием директив, содержащихся в конфигурационном файле /etc/squid/squid.conf. Следующие примеры иллюстрируют некоторые директивы, которые могут быть изменены для воздействие на поведение сервера Squid. Для более глубокой настройки Squid смотрите раздел .

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

Скопируйте файл /etc/squid/squid.conf и защитите его от записи следующими командами в терминале:

Sudo cp /etc/squid/squid.conf /etc/squid/squid.conf.original sudo chmod a-w /etc/squid/squid.conf.original

1. Для настройки вашего сервера Squid на прослушивание порта 8888 вместо стандартного 3128, измените директиву http_port как показано здесь:

Http_port 8888

2. Измените директиву visible_hostname для того, чтобы присвоить серверу Squid определенное имя хоста (hostname). Это имя необязательно должно быть именем хоста компьютера. В примере оно определено как weezie:

Visible_hostname weezie

3. Используя контроль доступа Squid, вы можете настроить, чтобы использование интернет сервиса прокси было доступно только пользователям с определенных IP адресов. Например, мы проиллюстрируем доступ пользователей только из подсети 192.168.42.0/24:

ACL

Acl fortytwo_network src 192.168.42.0/24

http_access вашего файла /etc/squid/squid.conf:

Http_access allow fortytwo_network

4. Используя великолепные возможности контроля доступа Squid, вы можете настроить возможность использования интернет сервиса прокси только в обычные рабочие часы. Например, мы покажем как настроить доступ сотрудников, которые работают с 9:00 до 17:00 с понедельника по пятницу из подсети 10.1.42.0/24:

Добавьте следующее в конец секции ACL вашего файла /etc/squid/squid.conf:

Acl biz_network src 10.1.42.0/24 acl biz_hours time M T W T F 9:00-17:00

Затем добавьте следующее в начало секции http_access вашего файла /etc/squid/squid.conf:

Http_access allow biz_network biz_hours

После внесения изменений в файл /etc/squid/squid.conf сохраните его и перегрузите приложение сервера squid, чтобы изменения вступили в силу, следующей командой в терминале: sudo /etc/init.d/squid restart

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

Воспользуемся для этого прокси сервером SQUID3

Устанавливаем сервер командой:

Внимание: В Ununtu Server версий менее 16, адрес папки прокси сервера squid — /etc/squid3 , в Ubuntu Server 16 адрес папки прокси сервера squid — /etc/squid . Будьте внимательны при прописывании путей. Визуально в правильном пути до папки SQUID можно убедится с помощью .

Файл конфигурации SQUID3 находится по адресу /etc/squid3 /squid.conf , так как данное руководство предназначается для новичков, а файл конфигурации очень большой и содержит очень много комментариев, мы создадим новый файл конфигурации, а оригинальный скопируем под другим названием.

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

Переименуем оригинальный файл squid3.conf в файл с названием squid3.conf.bac

Создаем пустой файл конфигурации squid.conf :

Открываем файл конфигурации:

Вставляем в файл следующий текст конфигурации:

Ubuntu Server 15: Файл начальной конфигурации прокси сервера SQUID

Что мы изменили в изначальной конфигурации:

• acl localnet src 192.168.137.0/24 — указали диапазон нашей локальной сети;
• http_port 192.168.137.1:3128 intercept — открыли прозрачный прокси сервер на порту 3128, в режиме «прозрачный» на клиентах не нужно настраивать адрес прокси сервера;
• cache_dir ufs /var/spool/squid3 2048 16 256 — указали настройки использования кеша. Обратите внимание на путь до папки SQUID в зависимости от версии вашего сервера;
• maximum_object_size 4 MB — минимальный размер кешируемого файла;
• maximum_object_size_in_memory 512 KB — максимальный размер кешируемого объекта в оперативной памяти;
• cache_mem 1024 MB — допустимый объем памяти для хранения кеша;
• access_log daemon:/var/log/squid3 /access.log squid — включения ведения логов. Обратите внимание на путь до папки SQUID в зависимости от версии вашего сервера;
• logfile_rotate 31 — срок хранения лог файлов.

Все остальные параметры, отставлены в изначальном файле конфигурации — без изменения.

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

Если команда отрабатывает без вывода — ошибок нет, в противном случае изучаем вывод и исправляем допущенные ошибки.

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

Откроем созданный в файл /etc/nat и укажем перенаправление http трафика через наш прокси сервер squid:

Добавим в конце файла следующее:

Ubuntu Server: Настройка squid

Перезапускаем сервер.

Прокси сервер Squid успешно настроен.

Большинство «не работает» вызвано невнимательностью! Внимательно проверяйте команды и не допускайте в файлах конфигурации лишних символов.