Настройка кэша в squid
Обновлено: 03.07.2024
Настраиваем Squid в качестве прозрачного прокси-сервера для небольшой сети.
Содержание
Установка Squid
Бинарный пакет собран с поддержкой прозрачного прокси с перенаправлением пакетов с помощью IPFW. Если требуется поддержка прозрачного прокси с брандмауэром отличным от IPFW, необходима сборка Squid из коллекции портов.
Настройка Squid
В FreeBSD 9.1 и более ранних версиях для работы прозрачного прокси с IPFW необходима настройка ядра. Начиная с FreeBSD 9.2, настройка ядра не требуется.
Редактируем файл конфигурации:
Если необходимо, задаем дополнительные параметры squid.conf:
Отображение местного времени на страницах ошибок Squid
Из коробки на страницах ошибок Squid отображает время по Гринвичу, для отображения местного времени необходимо скорректировать шаблоны ошибок. Параметр шаблона %T указывает мировое время, %t - местное.
Копируем шаблоны ошибок в папку erros.local:
Заменяем общемировое время (%T), на местное (%t):
Задаем путь к измененным шаблонам ошибок в squid.conf:
Запуск Squid
Включаем Squid в rc.conf:
Проверяем, запущен ли демон:
Проверяем, слушается ли порт:
В случае успешного старта вывод будет примерно следующим:
Протокол управления кэшем Squid
Для получения статистики и оперативного управления кэшем, используем squidclient.
Получить общую статистику сервера:
Получить список доступных действий:
Получить текущие параметры конфигурации:
Для работы этой команды необходимо задать пароль в squid.conf:
Управление кэшем возможно также из браузера. Если на сервере браузер не установлен, можно разрешить доступ с другого компьютера, для этого потребуется скорректировать параметры разрешений в squid.conf:
Настройка IPFW
Далее предполагается, что IPFW настроен на примере, предложенном в руководстве FreeBSD.
Проверяем, включена ли маршрутизация:
Если необходимо, включаем NAT:
Находим параметры IPFW:
Запоминаем путь к скрипту с правилами.
Редактируем список правил IPFW:
Добавляем правила, выделенные красным, перед правилом, разрешающим доступ в интернет:
Если менялись параметры rc.conf, включаем маршрутизацию и NAT. Будьте осторожны при настройке брандмауэра с внешнего IP, есть риск перекрыть себе доступ.
Загружаем обновленный список правил:
Инициируем веб-трафик с клиентского компьютера, проверяем лог доступа:
В случае проблем проверяем, работает ли правило брандмауэра:
Счетчик для правила перенаправления (fwd 127.0.0.1,3128) не должен быть нулевым.
Если перенаправление работает, но сайты не открываются, проверяем cache.log на предмет ошибок:
Ротация логов Squid
Проверяем, поддерживается ли вашей системой newsyslog.conf.d
Если в вашей системе отсутствует папка newsyslog.conf.d, редактируем newsyslog.conf:
Если папка newsyslog.conf.d имеется, создаем папку с тем же именем в /usr/local/etc:
Создаем файл правил ротации логов Squid:
Задаем правила ротации логов:
Выполняем ротацию ежедневно в полночь, сохраняем логи за последние 180 дней, раскомментируйте store.log, если он используется в вашей системе.
Для корректной ротации логов в squid.conf необходимо добавить следующий параметр:
Кэширование контента в Squid
На современных высокоскоростных безлимитных каналах связи кэширование потеряло свою актуальность. Для ускорения работы YouTube и других сетей доставки контента, кэширование также неэффективно, поскольку контент раздается с различных серверов.
По умолчанию дисковый кэш отключен, но в качестве кэша используется 256Мб оперативной памяти.
Полностью запретить кэширование можно добавив следующий параметр в squid.conf:
Если необходим дисковый кэш, добавляем в squid.conf следующие параметры:
Если путь к кешу был изменен, создаем папку кэша, задаем права доступа:
Создаем структуру кэша:
Ограничения доступа к сайтам и контенту в Squid
Для настройки ограничений, корректируем squid.conf следующим образом:
Создаем папку для списков контроля доступа:
Создаем необходимые списки, значения в списке разделяются новой строкой.
Список IP-адресов с неограниченным доступом:
Список сайтов, доступ к которым запрещен пользователям. Точка в начале адреса блокирует доступ ко всем адресам в заданном домене. Для массовой блокировки развлекательных ресурсов потребуется установка редиректора SquidGuard.
Подмена заголовков в запросе клиента в Squid
Перенос логов доступа Squid
Логи доступа Squid могут занимать достаточно большой объем. На старых установках, где /var/log размещен на отдельном небольшом разделе, приходится перемещать лог доступа в /usr/local.
Создаем папку для логов, задаем права доступа:
Перемещаем логи в новое расположение:
Удаляем папку /var/log/squid и создаем ссылку на /usr/local/squid/log:
Решение проблем
Предупреждение в cache.log:
Баг Squid появился в версии 3.2, возникает на BSD-системах, из-за некорректного вызова функции setuid.
В зависимости от параметров конфигурации Squid, в некоторых случаях помогает изменение параметра daemon на stdio при указании пути к access.log-у.
Ошибка при запуске Squid:
Начиная с версии 3.2 списки контроля доступа: manager, localhost и to_localhost являются предопределенными и создаются сквидом автоматически. При попытке их переопределения в файле конфигурации возникает ошибка. Данные параметры необходимо удалить из конфига.
Ошибка в cache.log:
Не задан порт для входящих подключений. Проверяем наличие в squid.conf директивы:
При запуске Squid получаем следующие предупреждения:
В файле конфигурации обнаружена декларация acl all. В третьей версии список контроля доступа all является предопределенным и создается сквидом автоматически. При попытке его переопределения в файле конфигурации возникает ошибка. Удалите или переименуйте acl all.
В cache.log постоянно пишутся предупреждения:
При сборке не была включена поддержка прозрачного прокси для вашего брандмауэра. Переустановите Squid из коллекции портов с включением соответствующих параметров.
Установка Squid из коллекции портов
Обновляем коллекцию портов:
Если коллекция портов используется впервые, получаем ее актуальную версию:
Выполняем настройку порта:
В параметрах сборки проверяем, что включена поддержка прозрачного проксирования для используемого брандмауэра и поддержка больших файлов:
Если параметры сборки были изменены, блокируем переустановку Squid пакетным менеджером:
Пакетный менеджер и кастомизированный Squid
При обновлении, пакетный менеджер обнаружит порт, собранный с нестандартными параметрами и предложит выполнить переустановку. После установки бинарного пакета прозрачный прокси перестанет работать.
Частично проблему можно решить, заблокировав обновление Squid:
Теперь пакетный менеджер не будет обновлять Squid, но вместе с ним блокируется обновление и всех его зависимостей. Что рано или поздно приведет к неразрешимому конфликту зависимостей, когда другим пакетам потребуются новые версии библиотек.
Чтобы избежать проблем придется собирать Squid из портов при каждом обновлении, затрагивающем Squid или его зависимости. Процедура обновления получается следующая.
Обновляем коллекцию портов:
Снимаем блокировку обновления пакета:
Обновляем установленные пакеты:
Компилируем Squid, будут использованы параметры компиляции, заданные при первичной установке:
Собираем и устанавливаем Squid:
Блокируем переустановку Squid:
Настройка ядра (FreeBSD 9.1 и ранее)
Начиная с FreeBSD 9.2 настройка ядра не требуется, форвардинг пакетов отныне включен изначально, параметр IPFIREWALL_FORWARD удален из настроек ядра.
Для работы в режиме прозрачного прокси в версиях системы до 9.2 необходимо обеспечить перенаправление веб-трафика прокси-серверу. Если в качестве брандмауэра используется IPFW, необходимо включить форвардинг пакетов пересобрав ядро с опцией IPFIREWALL_FORWARD.
В ядре GENERIC опция перенаправления по умолчанию отключена. Чтобы проверить, включено ли перенаправление пакетов в вашей системе, выполняем команду:
Получаем следующий результат:
Получаем идентификатор ядра:
Если ранее ядро не изменялось, в результате получаем:
Создаем файл конфигурации ядра IPFORWARD:
Переходим в папку с исходниками системы:
Если файлы в /usr/src отсутствуют, необходимо установить исходники, соответствующие вашей версии системы.
Доброго времени суток.
Это продолжение статьи Squid для самых маленьких
В этой части я расскажу вам про то, какие основные параметры необходимо менять, хотя и не обязательны, ведь разработчики самого сквида выставили довольно хорошо львиную долю значений. Итак, начнем по порядку.
Так как я часто работаю через ssh соединение, иногда на некоторых серверах бывает отвратительная скорость, в связи с этой проблемой рекомендую писать все в самом начале конфига, что дает ему довольно хорошо читаемый вид, и не нужно поиском искать все значения. Хотя, хочу заметить, что все второстепенные параметры(кроме списков доступов ACL и парочки других) не задаются в конфиге по умолчанию. На деле же прописан дефолтный параметр, и он имеет комментарий. Так что нам не придется искать каждый параметр. НО(. ) если вы уже правили, то не нужно начинать писать все в самом верху, необходимо найти рас комментированные значения и менять их. Поехали.
Первое что я советую сметить, хотя бы на время тестирования это параметр shutdown_lifetime по дефолту он имеет значение 30 секунд, что очень долго. Приведу пример, иногда бывает такое, что ты что-то накосячил, и инет у всего офиса пропал, ты быстро изменил свою ошибку, но сам сквид после того как ты ему послал SIGTERM или SIGHUP(перезагружаешь) ждет время, которое стоит в этом параметре, в течении которого новые соединения не будут устанавливаться, а старые должны закончить закачку. Я обычно ставлю:
shutdown_lifetime 5
Слудущими параметрами будут параметры описывающие кеш cache_dir, maximum_object_size
Итак, если у нас стоит нормальный шлюз, которые проксирует инет, и в организации хватает компов >30, то нужно ставить минимум 2 гига, хотя два в принципе и достаточно большинству. У параметра cache_dir много параметров, я не хочу на них останавливаться, ибо все это отлично описано в манах. Я привиду лишь, то что считаю наиболее рациональным, стандартные 256 Мб ни куда не годятся :)
cache_dir ufs /var/squid/cache 2048 16 256
после этого необходимо пересоздать каталоги командой Squid -z, что сотрет весь наш предедуший кеш.
maximum_object_size говорит сквиду стоит ли записывать файлы размером больше определенного.
maximum_object_size 10024, мне кажется что этого вполне хватит, потом некоторые можно будет выуживать из кеша. Иногда полезно если у вас работники качают свежую версию, например Adobe Flash Player.
Если нужно предоставить совместный доступ сервисам нескольким пользователям с возможностью кэширования трафика, то в первую очередь вспоминают о кэширующем прокси-сервере Squid. Это очень гибкое решение, которое применяют как в малых офисах с несколькими пользователями, так и в корпоративных сетях со сложной топологией. Предлагаю разобрать, как настроить в Squid самые популярные функции – контроль доступа и работу с кэшем.
Установка Squid
$ sudo apt-get install squid squid-commonИли для Squid 3:
$ sudo apt-get install squid3 squid3-common
После инсталляции Squid будет запущен с установками по умолчанию.
Иногда в процессе запуска появляется ошибка:
Формат squid.conf стандартен для Unix, каждая запись состоит из строк вида:
$ sudo /etc/init.d/squid start
$ sudo cat /var/log/squid/access.log | grep 192.168.0.10
Чтобы в Интернет могли попасть остальные пользователи сети, нужно установить соответствующие разрешения, используя контроль доступа.
Настраиваем доступ
acl localnet src 192.168.0.0/24 172.16.0.0/12
acl localnet src 192.168.1.1
acl work_hours time M T W T F 9:00-18:00
В описании используются первые буквы английского языка, соответствующие дням недели. В секции “ACCESS CONTROL” уже описаны некоторые ACL, в частности описываются номера некоторых портов (привожу не все) и ACL соответствующий всем адресам:
acl SSL_ports port 443 563 873
acl Safe_ports port 80 21 443 563 1025-65535
acl all src 0.0.0.0/0.0.0.0
Восклицательный знак инвертирует значение списка, то есть звучит как “все кроме”. По умолчанию используется правило:
Его мы обязательно помещаем в конец списка правил. В этом случае все соединения которые явно тобой не разрешены, будут блокированы. Майнтайнеры собирающие пакеты в дистрибутивах, как правило, добавляют и несколько своих правил.
Чтобы разрешить подключение к Squid с указанных адресов и работу только с нужными портами пишем:
Сохраняем результат и перезапускаем Squid:
$ sudo /etc/init.d/squid restart
И проверяем. Если все нормально, идем дальше. Чтобы не перестраивать клиентские системы проще использовать iptables:
Еще один пример, нам нужно, чтобы компьютеры определенными IP могли соединяться только в рабочее время. Без проблем:
Можно расписать это правило на два, сделав его более читабельным:
Первая строка разрешит доступ при совпадении двух ACL: рабочее время и IP-адрес. Вторая запретит доступ всех записанных в ACL workip при несовпадении с первым правилом, то есть в другой временной промежуток.
Режем баннеры и сайты
Если в сети есть юзеры, которым разрешено все, например начальство не очень любит когда их куда то не пускают, то запрещающее правило можно дополнить списком адресов:
В том случае если нужно будет указать домен источника, то используй srcdomain. Это самый простой способ, но далеко не самый удобный, так как юзвери не попав на любимый ресурс, быстро бросятся на поиск альтернативы и естественно его найдут. Поэтому адреса в ACL удобнее задавать при помощи регулярных выражений:
Удобнее для хранения URL использовать отдельный файл:
Заносим данные о расширениях в указанный файл:
$ sudo nano /etc/squid/blocks.files.acl
deny_info ERR_BLOCKED_FILES blockfiles
И создаем файл /etc/squid/errors/ERR_BLOCKED_FILES в котором популярно расписываем причину блокировки.
Составив подобным образом URL можно блокировать рекламу, например Google AdSense и некоторые другие попадут под правило:
Настройки кэша
Борьба с баннерами не единственная возможность сэкономить трафик. Поэтому нельзя обойти стороной некоторые настройки кэширования. А Ubuntu кэш по умолчанию размещается в каталоге /var/spool/squid. В других дистрибутивах может быть иначе, чтобы не искать просмотри значение переменной cache_dir. Формат ее такой:
cache_dir type путь размер L1 L2 [options]
cache_dir ufs /var/spool/squid 10249 16 256
Поле type определяет формат кэша: ufs (unix file system), aufs и diskd. В особенности углубляться не буду, по умолчанию используется ufs. Максимальный размер после которого кэш будет очищаться установлен по умолчанию в 100 Мб. При больших нагрузках он быстро заполнится, поэтому есть смысл увеличить его до нескольких гигабайт. Удобно, что можно использовать несколько cache_dir, установив кэш на разных дисках. Это положительно сказывается на производительности. В Squid каждый кешируемый объект располагается в отдельном файле, сами файлы не сваливаются в одно место, а используется в двухуровневая иерархия каталогов. Количество каталогов 1 и 2 уровней и определяют параметры L1 и L2. По умолчанию их значения 16 и 256 соответственно. Дополнительно для каждого cache_dir можно определить параметр read-only (только чтение) и max-size (максимальный размер объекта).
Глобально максимальный размер объекта в кэше определяется переменной maximum_object_size, значение по умолчанию которой 4 Мб, имеет смысл его увеличить:
maximum_object_size 10240 KB
Хотя можно вместо глобальной установки, установить такой параметр для некоторых типов файлов. Теперь документация на странице reload_into_ims отсылает нас к не менее интересному refresh_pattern, который задает параметры кэширования. В общем, шаблон записи выглядит так:
refresh_pattern [-i] regex min percent max [options]
refresh_pattern ^ftp: 1440 20% 10080
refresh_pattern ^gopher: 1440 0% 1440
refresh_pattern . 0 20% 4320
refresh_pattern (cgi-bin|\?) 0 0% 0
И параметры появившиеся в третьей версии:
В самом простом случае вместо правил по умолчанию можно написать одно правило, заставляющее принудительно кэшировать объекты на целый год:
refresh_pattern . 518400 80% 518400 override-expire override-lastmod reload-into-ims ignore-no-cache ignore-private ignore-auth ignore-no-store
refresh_pattern \.exe$ 43200 100% 43200 override-expire override-lastmod reload-into-ims ignore-no-cache ignore-private ignore-auth ignore-no-store
refresh_pattern \.zip$ 43200 100% 43200 override-expire override-lastmod reload-into-ims ignore-no-cache ignore-private ignore-auth ignore-no-store
Как видишь в Squid ничего страшного нет. Если ручную настройку не считаешь удобной, то обратись к Webmin, в котором большинство установок можно произвести в удобной наглядной форме. Базовая настройка занимает минут 10, после некоторой доводки пользователи будут радоваться скорости Интернета, а руководство использованием трафика.
Пакет Squid распространяется по свободной лицензии GNU General Public License и имеет следующие основные возможности:
- Контроль доступа к сети Интернет. Ограничение доступа для групп или отдельных пользователей, доступ по расписанию, доступ к ограниченному числу ресурсов или создание “запрещённого списка” сайтов - для регуляции доступа сотрудников к “развлекательным” сайтам в рабочее время и защиты от проникновения во внутреннюю сеть посторонних клиентов;
- Контроль трафика. Множество вариантов настройки, позволяющие серверу обеспечивать доступ максимальному количеству клиентов без перегрузки возможностей сетевого оборудования, в том числе отдельные конфигурации для разных видов трафика. Организация открытой точки wi-fi без боязни за возможную нестабильность сети. Возможность выдавать отдельным клиентам или группам ограниченного объема трафика для работы;
- Мониторинг использования сетевых ресурсов. Различные статистические данные, которые собирает Squid, и созданные для него расширения будут незаменимы для оптимизации локальной сети, анализа нагрузки, исследования причин возможных сбоев сети и обнаружения атак на локальную сеть компании;
- Обратное кэширование. Возможность работы в режиме “обратного прокси” или “ускорителя” - для существенного снижения нагрузки на сервер путем кэширования запросов, к которым идет больше всего обращений от пользователей.
Squid может работать в качестве прозрачного прокси-сервера. В таком случае пользователь может даже не знать, что его запрос был обработан прокси-сервером. Благодаря этому отпадает необходимость настройки каждой клиентской машины для работы в локальной сети.
Настройка локальной сети
Прежде чем переходить к установке и настройке прокси-сервера Squid, необходимо настроить локальную сеть. Для этого на проксируещем сервере должно быть как минимум два сетевых интерфейса - первый осуществляет взаимодействие с Интернетом, в то время как ко второму будут подключаться компьютеры локальной сети. Все настройки и команды приводится на примере дистрибутива Ubuntu.
Чтобы изменить конфигурацию локальной сети или внести полученные от провайдера настройки для подключения сервера к сети Интернет, необходимо отредактировать всего один конфигурационный файл:
Приведём его к следующему виду:
Для применения новых настроек необходимо перезапустить сеть командой:
По окончании настройки желательно убедиться, что интерфейсы настроены верно. Вывод информации о сетевых подключениях осуществляется командой:
Полученные данные будут иметь примерно следующий вид:
По этим данным ясно, что у сервера имеется два сетевых интерфейса, eth0 и eth1, с IP-адресами 185.22.174.75 для eth0 и 192.168.0.1 для eth1. К адаптеру eth0 подключен кабель интернет-провайдера, а к адаптеру eth1 будут подключены компьютеры локальной сети.
Настройка DHCP
На данном этапе уже есть возможность указать на локальной машине статический IP-адрес из локальной подсети, например 192.168.0.2, наш сервер (192.168.0.1), в качестве шлюза, и DNS-сервер. Компьютер будет подключен к локальной сети.
Но система статических IP-адресов имеет свои недостатки: необходимо настраивать каждую машину для подключения к локальной сети, возможен конфликт одинаковых IP и тому подобное.
Поэтому следующим этапом будет настройка механизма автоматической трансляции IP-адресов через DHCP. В таком случае при подключении к сети нового компьютера все настройки будут переданы ему автоматически.
Для установки сервера DHCP используется команда:
Файл конфигурации по умолчанию находится в /etc/dhcp/dhcpd.conf, откроем файл в редакторе с помощью команды:
В большинстве случаев минимальная настройка производится внесением блока вида:
После изменения конфигурационного файла необходимо перезапустить сервер DHCP для применения новых настроек:
Теперь все клиенты локальной сети будут получать все настройки автоматически при подключении.
Настройка NAT
После организации локальной сети необходимо подключить её к Интернету - для этого реализуется трансляция сетевых адресов (Network Address Translation или NAT). Благодаря NAT несколько компьютеров могут выходить в интернет, используя один IP-адрес.
В Ubuntu механизм NAT реализуется с помощью сетевого фильтра iptables, который одновременно является брандмауэром.
Для автоматической загрузки настроек iptables при старте системы создадим новый пустой конфигурационный файл командой:
И откроем его для изменения:
Варианты конфигурации брандмауэра зависят от политики сетевой безопасности в компании. Минимальный набор настроек выглядит следующим образом:
После сохранения изменений обеспечим для файла права на исполнение:
Далее необходимо поставить созданный файл на автозагрузку при включении сервера. Для этого откроем рассмотренный ранее файл interfaces:
и добавим в самый низ строку:
Перезагрузим сервер для автоматического применения новых настроек:
Установка и настройка Squid
Для инсталляции Squid используется команда:
Когда установка завершится, сервис запустится автоматически.
Перейдём к настройке. Файл конфигурации расположен по адресу /etc/squid3/squid.conf. Для неподготовленного пользователя он может показаться совершенно необъятным - в нём более 7000 строк. Большая часть из них закомментированы и описывают значительную часть всех возможных вариантов работы Squid.
Для комфортной работы скопируем файл настроек в ту же папку под другим именем, чтобы всегда иметь под рукой стандартные настройки:
При необходимости перед началом настройки можно обратиться к официальной документации проекта.
Теперь можно удалять из файла конфигурации все закомментированные строки и пояснения, оставляя только активные директивы. По умолчанию их немного:
Основной инструмент настройки Squid - это списки контроля доступа или ACL (Access Control List). ACL объявляются директивой, имеющей следующий синтаксис:
acl имя параметр элементы_списка
Параметр даёт серверу понять тип элементов списка. АCL с параметром port содержит номера портов, а с параметром src - ip-адреса, с которых на сервер поступает запрос. Полный список параметров весьма обширен и доступен в официальной документации.
Таким образом, строка
добавляет в список Safe_ports, содержащий элементы типа “порт”, новое значение 80.
определяет правила работы с элементами указанного acl. Например, строка:
блокирует все порты, не входящие в список Safe_ports.
По умолчанию доступ к Squid разрешен только с самого сервера:
Чтобы открыть доступ клиентам локальной сети создадим для них новый список доступа c параметром src:
И разрешим доступ:
Теперь укажем порт, на котором работает Squid, и установим прозрачный режим работы:
Минимальная настройка конфигурационного файла Squid завершена, теперь можно перейти к описанию политики информационной безопасности.
Параметр src позволяет регулировать доступ для клиентов со статичными ip-адресами:
Параметр dst позволяет указать список ip-адресов назначения, к которым клиент желает получить доступ:
Параметр dstdomain даёт возможность указывать домен, к которому выполняется запрос:
Если необходимо указать домен источника, используется параметр srcdomain .
Параметры srcdom_regex и dstdom_regex позволяют использовать в ACL регулярные выражения:
Ключ -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-адресов и отдельных доменов. Например:
Параметр proto позволяет указывать протокол передачи информации:
acl имя_acl proto список
Используя его можно запретить пересылку файлов по протоколу ftp:
Ограничения по скорости
На сегодняшний день, когда ушли в прошлое каналы с пропускной способностью в 256 кбит/с и менее, можно ошибочно предположить что устанавливать ограничения по скорости соединения в случае небольшого количества клиентов локальной сети бессмысленно. Тем не менее, очень желательно устанавливать хотя бы самые простые правила регулирования скорости соединения для отдельных пользователей, чтобы избежать перегрузки сети и нехватки ресурсов для отдельных пользователей, для которых важна хорошая скорость работы сети. Подводные камни могут скрываться в следующих процессах:
- автоматическое резервное копирование данных с сервера компании и прочие процессы передачи больших объемов данных, выполняющиеся сервером по расписанию;
- операции передачи файлов для личных и рабочих нужд, особенно своей способностью использовать все доступные сетевые ресурсы известен протокол BitTorrent;
- технические неисправности в отдельных компьютерах и программах, а так же действия вредоносных программ;
- злонамеренные сетевые атаки на отдельные компьютеры локальной сети.
Прокси-сервер Squid позволяет реализовывать политику ограничения скорости с помощью механизма пулов. Пул можно представить себе, как емкость с водой, которая постоянно заполняется до краёв, а клиенты по мере надобности наливают воду в свои стаканы через персональные краны.
Работу пулов регулируют три директивы: delay_class , delay_parameters , delay_access .
Количество пулов устанавливает директива delay_pools:
Создадим несколько пулов:
Пулы могут быть трёх классов:
- Один кран на всю сеть ограничивает поток воды;
- Весь поток ограничен одним краном, после которого идут отдельные персональные краны(для каждого IP-адреса сети);
- Весь поток ограничен одним краном, от которого идут отдельные краны для каждой группы пользователей(подсети), каждый из которых, в свою очередь, делится на персональные краны для каждого клиента(для отдельного IP-адреса).
Класс пула должен быть указан в директиве delay_class :
delay_class номер_пула класс_пула
Укажем класс пула:
Директива delay_parameters устанавливает параметры пула:
delay_parameters номер_пула параметры
Формат записи параметров зависит от выбранного класса пула:
Для пула №1 выбран класс 1, установим для него скорость передачи данных в 512 кбит/с:
Запись параметра производится по следующим правилам: сперва указывается ограничение скорости, затем указывается лимит, после которого это ограничение начинает действовать. Таким образом значение параметра 64000/64000 говорит о том, что после того, как пользователь скачал на максимальной скорости первые 64Кб запроса, на клиента накладывается ограничение скорости в 512 Кбит/с. Удобно устанавливать второе значение параметра несколько больше чем первое, например конфигурация:
позволяет пользователю получить первые 256Кбайт запроса на максимальной скорости и только потом ограничить клиента шириной канала в 512 Кбит/с.
Для снятия ограничений по скорости используйте значение -1, например:
Теперь можно распространять действие пула на отдельных клиентов сети при помощи директивы delay_access , имеющей формат:
delay_access номер_пула действие имя_acl
Параметр “ действие” имеет значения allow (разрешить) и deny (запретить). Пул будет действовать на тех клиентов, которым он разрешен и не будет действовать на тех, кому запрещён.
распространяет действия пула №1 на отдельного пользователя SingleUser, но не затрагивает группу пользователей UserGroup.
Для группы пользователей используем пул №2:
Применим ограничения пула №2:
Настройка кэширования
Прокси-сервер Squid поддерживает два вида кэширования - кэш в оперативной памяти и на жестком диске. При их настройке стоит помнить, что кэширование в принципе может ускорить скорость обработки запросов, но может вызвать и обратный эффект - в случае неверно подобранных параметров конфигурации. Также немаловажным является тот факт, что любое кэширование влечет дополнительную нагрузку на ресурсы сервера, в частности, слишком большой объем кэша в RAM может полностью парализовать работу сервера, спровоцировав нехватку оперативной памяти.
В стандартной конфигурации Squid включен только RAM кэш, объем используемой памяти установлен на 256Мб. Увеличим объем кэша и установим максимальный размер кэшированного объекта с помощью соответствующих директив:
Следует учитывать, что кэш в оперативной памяти сбрасывается каждый раз при перезагрузке или выключении сервера, поэтому оценивать результаты изменения конфигурации стоит только по прошествии некоторого времени.
За использование HDD кэша отвечает директива cache_dir , имеющая формат:
cache_dir тип_хранилища путь_к_хранилищу размер L1 L2
Размер кэша на диске указывается в мегабайтах, в примере выше кэш с максимальным размером 1 Гб будет хранится в папке /var/squid_cache. Тип хранилища ufs стандартный. Параметры 16 и 256 указывают количество директорий первого и второго уровня, эти значения так же прописаны в документации как стандартные.
Максимальный размер объекта в дисковом кэше также можно указать:
Настройка логирования
Squid имеет мощную систему подробного логирования для контроля проходящего через прокси-сервер траффика. Логи делятся на три различных журнала:
Чаще всего используется журнал access.log. Укажем в конфигурации собственный путь для его хранения:
Параметр, имеющий в примере значение “squid” определяет формат лог-файла. Можно задать формат лога “common” для того, чтобы можно было обрабатывать полученный журнал сторонними программами, но в таком случае стоит помнить, что этот формат лога не содержит всей информации, которая есть в логе по умолчанию. Помимо стандартных вариантов имеется возможность создать собственный формат лог-файла, используя директиву logformat. Подробную информацию о работе этой директивы можно найти в документации к продукту.
Директивы cache_log и cache_store_log позволяют указать путь к файлам cache.log и store.log соответственно. Они не требуют указания формата:
Помимо различных видов журналов Squid имеет настройку уровней логирования. За глубину отладки отвечает директива debug_options . У неё два обязательных параметра - секция и глубина отладки:
Значение секции рекомендуется оставлять ALL (либо осторожно выбирать конкретную секцию из списка). Уровень логирования же может менятся в диапазоне от 1 до 9, где с ростом уровня увеличивается подробность логов, и, соответственно, количество записей в журнале. Как правило, уровень выше 5 редко используется в реальной жизни, потому что выводит уже слишком много “избыточной” информации для каждого произошедшего события.
Для того чтобы всегда иметь возможность начать новый файл логов и упорядочить их существует параметр количества ротаций:
Значение 31 означает, что при создании нового файла логов старый получит расширение от 0 до 30 и дальнейшая запись в него вестись не будет. Создание нового файла логов производится с помощью команды:
Таким образом, добавив в cron задачу каждый день создавать новый файл логов, можно иметь упорядоченный отчет обо всём прошедшем через прокси-сервер трафике за прошедший месяц.
Если даже с самым низким уровнем логирования объем логов возрастает до нежелательных масштабов - стоит применить дополнительные средства, вроде автоматического сжатия журналов или переноса их в отдельное хранилище. Так же можно изменить количество или частоту ротаций в зависимости от задачи. Можно хранить меньшее количество логов, либо чаще создавать свежий журнал, а старый архивировать и перемещать. Для прокси-сервера Squid есть множество надстроек и сторонних программ, упрощающих все этапы работы с лог-файлами.
Оставим без изменений остальные параметры и проверим файл настроек с помощью команды:
Эта команда предназначена для поиска ошибок в конфигурационном файле, если она ничего не выводит - значит ошибок нет.
Теперь осталось применить новые параметры:
После завершения настройки прокси-сервера перенаправим на него весь трафик локальной сети, внеся изменения в файл /etc/nat командой:
Добавим в самый низ файла следующую строку:
После этого перезагрузим сервер для автоматического применения новых настроек:
Таким образом, несмотря на большое общее количество параметров настройки Squid, минимальный набор для начала работы достаточно скромен. Использование прокси-сервера Squid позволит вам быстро реализовать политику доступа групп пользователей или отдельных клиентов к ресурсам сети интернет, а так же мониторинг их деятельности и сбор статистики об использовании канала.
Читайте также: