Что такое squid proxy
Установка и настройка прокси-сервера Squid
Squid – самый популярный HTTP-прокси сервер для кэширования и перенаправления. Он широко используется различными компаниями для кэширования веб-страниц с веб-сервера для повышения скорости работы последнего, снижения времени ответа и ограничения использования пропускной способности сети. В данном руководстве мы рассмотрим установку прокси-сервера squid и его использование в качестве HTTP-прокси сервера.
Установка прокси-сервера Squid
Прежде чем начать, стоит отметить, что сервер Squid не требует значительных ресурсов, но использование оперативной памяти может изменяться в зависимости от количества клиентов, осуществляющих доступ в интернет через прокси-сервер.
Пакет Squid доступен в стандартном репозитории
В Ubuntu/Debian
Запустите его и задайте запуск при загрузке:
После этого можно проверить статус службы:
Важные файлы Squid располагаются в следующих директориях:
Файл конфигурации: /etc/squid/squid.conf
Журнал доступа: /var/log/squid/access.log
Журнал кэша: /var/log/squid/cache.log
Файл конфигурации по умолчанию содержит ряд директив, при помощи которых осуществляется управление работой сервера. Для внесения изменений откройте файл любым текстовым редактором.
В нем довольно много параметров, мы рассмотрим самые важные из них.
http_port порт HTTP-прокси сервера, по умолчанию 3128. Для безопасности рекомендуется сменить его на другой.
visible_hostname Параметр используется для определения имени узла сервера Squid. Можно задать любое имя.
Также можно указать параметр intercept (или transparent для старых версий), например, http_port 3128 intercept. В этом случае ваш сервер будет работать как прозрачный прокси (без необходимости настраивать его использование на стороне клиента).
Для последующего понимания работы прокси, нужно понять следующие параметры
http_access-Данный параметр регулирует доступ к HTTP-прокси серверу. С помощью него можно разрешить или запретить доступ через сервер как к определенным ресурсам в интернете, так и определенным группам пользователей.
В данный момент любой доступ запрещен (deny all). Чтобы начать использование сервера, нужно изменить ее, например, на http_access allow all (разрешить любой доступ). Параметр all можно заменить на имя списка доступа, которые мы рассмотрим чуть ниже.
acl(access control list) — В этом параметре указываются ресурсы в интернете, порты, ip адреса пользователей, локальные сети. В общем это список к которому будут применяться различные правила. Таких списков может быть неограниченное количество.
После внесения изменений нужно перезапустить Squid следующей командой:
Настройка Squid как HTTP-прокси
В данном разделе мы рассмотрим настройку Squid в качестве HTTP-прокси, использующий для аутентификации только IP-адрес клиента.
Общий синтаксис в прокси выглядит следующим образом
При описании контроля доступа можно использовать оператор отрицания «!». Например следующая строка запрещает доступ ко всем портам, кроме описанных в листе Safe_ports
Добавление списков контроля доступа
Рассмотрим создание списков доступа acl подробнее. По умолчанию уже есть преднастроенный acl localnet
Вы можете его отредактировать или удалить. Создадим новый acl
Добавьте правило следующего вида:
Где boss — имя списка контроля доступа, src — параметр, задающий адрес источника (source), а XX.XX.XX.XX — IP-адрес машины клиента (можно также указывать подсети или диапазоны). Новые списки контроля доступа нужно добавлять в начало раздела ACL. Аналогичным образом можно создавать списки доступа с ограничением по адресу места назначения (параметр dst вместо src), а также использовать вместо адресов доменные имена (srcdomain для источника, dstdomain для места назначения).
Очень желательно рядом с ACL указывать комментарий с кратким описанием пользователя этого IP-адреса, например:
После этого нужно разрешить доступ для boss:
Чтобы изменения вступили в силу, нужно перезагрузить Squid.
Открытие портов
По умолчанию в конфигурации Squid разрешено использование только определенных портов.
Если требуется использование дополнительных портов, можно задать их в файле конфигурации:
Где XXX — номер порта, использование которого нужно разрешить. Снова желательно пояснять ACL комментарием.
Не забываем перезапустить Squid для применения настроек
Работа прокси в прозрачном режиме
Как уже было сказано, прозрачный режим предполагает автоматическую работу прокси-сервера без необходимости в явном виде указывать его на клиентских машинах. В общем случае клиент может вообще не знать, что работает через прокси. Это может быть полезным для обеспечения анонимности, ограничения доступа к некоторым сайтам и даже экономии сетевого трафика, так как прокси-сервер может сжимать данные.
Помимо уже рассмотренной выше опции intercept в параметре http_port файла конфигурации, для обеспечения правильной работы прозрачного прокси требуется соответствующим образом настроить маршрутизатор. Чтобы все входящие и исходящие запросы на порт 80 перенаправлялись на порт, используемый прокси-сервером.
В случае использования iptables нужно добавить следующие правила (в рассматриваемом примере eth1 — внутренний интерфейс, eth0 — внешний, SQUID_IP — IP-адрес прокси-сервера):
Аутентификация клиента
Cоздадим файл passwd для хранения имени пользователя для аутентификации. Сквид работает как пользователь squid, поэтому он должен быть владельцем файла.
Создадим нового пользователя ivan и установим ему пароль.
Для задания базовой HTTP-аутентифркации откройте файл конфигурации Сквид в текстовом редакторе:
И пропишите следующие директивы после ACL портов:
Чтобы применить изменения, сохраните файл и перезапустите Сквид. Теперь при попытке получить доступ в интернет необходимо будет ввести логин с паролем
Настройка параметров кэширования
Одна из важных функций прокси-сервера — кэширование веб-страниц для разгрузки веб-сервера и ускорения доступа. Сквид поддерживает два типа кэша, в оперативной памяти и на жёстком диске.
Кэш в оперативной памяти настраивается следующими параметрами:
cache_mem 1024 MB — выделенный для кэширования объем памяти
maximum_object_size_in_memory 512 KB — максимальный размер объекта в кэше
Параметры кэша на жёстком диске задаются следующей директивой:
Размер указывается в мегабайтах, ур_1 и ур_2 — количество директорий первого и второго уровня, соответственно, например:
Аналогично кэшу в памяти при помощи следующего параметра указывается максимальный размер объекта в кэше на диске:
Ограничение скорости
Squid может ограничивать скорость доступа к сети. Хотя в современных условиях эта функция может показаться избыточной, она часто может оказаться полезной, например, для ограничения использования пропускной способности канала какими-либо автоматизированными задачами.
Для реализации ограничения скорости Сквид использует механизм пулов задержки (delay pools). Пулы задержки можно условно представить в виде ёмкости, которая “заполняется” данными, и после этого “выпускает” их только с определенной скоростью. Количество пулов задаётся в файле конфигурации следующим образом:
Каждый пул имеет номер (от 1 до заданного количества), а также класс. Классы реализуют многоступенчатую структуру ограничения:
1 класс — общее ограничение
2 класс — общее ограничение и ограничения для подсетей
3 класс — общее ограничение, ограничения для подсетей и ограничения для отдельных ip-адресов
Классы пулов задаются директивой delay_class, в качестве аргументов которой передаются номер пула и класс.
Параметры пулов задаются директивой delay_parameters и описывают максимальный объем пула и ограничение на каждый уровень (в байтах) в зависимости от класса. Например, параметры для пула 1 класса с номером 1:
Будут означать, что после получения первых 256 Кб запроса на максимальной скорости скорость будет ограничена 64 Кб/с, то есть 512 Кбит/с.
Для 2 класса и выше аналогичным образом задаются ограничения для подсети, отдельного адреса и т.д., например следующая директива ограничивает общую скорость до 8 Мбит/с, а скорость для подсети после первых 256 Кб запроса — до 512 Кбит/с.
Чтобы задать пулы задержки для определенных списков контроля доступа, используется директива delay_access, содержащая номер пула, параметр allow или deny и имя списка, например:
для примера создадим два пула, 1 и 2 класса:
Теперь пользователи из листа office1 будут иметь скорость доступа в интернет в соответствии с delay_parameters 1.
Создаем 2-й класс
Это означает, что пользователи acl office2 ограничены общей скоростью на всю сеть в 512 кбит, но при этом отдельные пользователи в этой сети ограничены после первых 256 Кб, скоростью в 64 кбит
Проверим на сайте speedtest.net, работу ограничений
Как видите скорость загрузки действительно ограничена приблизительно до 256 кбит. Обратите внимание, что сквид ограничивает только скорость отдачи от него, т.е скорость загрузки пользователя. На скорость отдачи от пользователя ограничение не действует.
Блокировка веб-сайтов
Для блокировки доступа к нежелательным веб-сайтам сначала создайте файл с “черным списком”:
Теперь в этот файл нужно добавить сайты, к которым требуется заблокировать доступ. Например заблокируем доступа к одноклассникам и вконтакте:
Точки перед именами указывают Сквид блокировать все ссылки на эти сайты, в том числе www. vk.com, subsite.vk.com и т.д.
Далее нужно открыть файл конфигурации
И добавить список контроля доступа по доменным именам, указанным в файле, а также правило, запрещающее доступ для этого списка:
Обратите внимание на порядок расположения правил, правила доступа выполняются сверху вниз. Поэтому запрещающее правило расположено выше разрешающего
Сохраните файл и перезапустите Squid:
Теперь при попытке получить доступ к сайтам из списка, пользователь получит предупреждение
Блокировка по маске
Можно осуществлять блокировку не только по именам сайтов, но и по маске. Т.е. заблокировать доступ в сайтам, в которых есть определенное сочетание букв. Аналогичным образом создаётся файл со списком запрещенных ключевых слов:
Далее в него добавляются ключевые слова, например:
Откройте файл конфигурации и внесите в него следующие список контроля доступа и правило:
А затем сохраните файл и перезапустите Сквид:
Теперь, все сайты в названии доменов которых встречаются facebook, instagram, gmail будут заблокированы.
Заключение
Squid — очень мощное решение для создания прокси-сервера, обладающее огромными возможностями, значительной гибкостью и применимое практически в любой сети, от небольшого офиса до крупной корпорации. Мы охватили наиболее важные функции и параметры конфигурации Squid. Для получения более подробной информации о его конфигурации можно обратиться к официальной документации.
Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.
Блог о системном администрировании. Статьи о Linux, Windows, СХД NetApp и виртуализации.
Доброго времени, уважаемые читатели и гости! С данной статьи я начну описание работы кэширующего прокси-сервера SQUID. Эта статья в большинстве своем будет вводная теоретическая.
Что такое proxy-сервер и что такое squid
Режимы работы прокси-сервера Squid
Прокси-сервер Squid может работать в следующих трех основных режимах:
Прозрачный режим
В этом режиме HTTP соединение осуществляемое клиентами перенаправляется на прокси-сервер без их ведома или явной конфигурации. В этом режиме не требуется настройка клиентов. Недостатки данного способа: необходима конфигурация NAT и перенаправления трафика, аутентификация клиентов не работает, не перенаправляются FTP и HTTPS запросы.
Аутентифицирующий режим
Для работы в этом режиме клиенты должны быть настроены для работы с прокси-сервером (в настройках соединения должен быть прописан адрес прокси-сервера). Может выполняться аутентификация и авторизация клиентов через Kerberos, Ldap, NTLM, IP и Radius. Возможно построение взаимодействия с серверами Microsoft Active Directory путем аутентификации клиентов – членов домена, используя протокол Kerberos, и последующей авторизации членов групп домена используя LDAP в прозрачном режиме (пользователь вводит свой пароль только при регистрации в домене). Для авторизированных групп возможно применение различных настроек контроля доступа и QoS (delay pools).
Обратный прокси-сервер
Прокси-сервер кэширует исходящие данные. Обратный прокси-сервер Squid получает данные у HTTP сервера от имени клиента и передает их обратно клиенту (например, в Интернет). Этот режим позволяет осуществить:
Схемы режимов работы SQUID
На приведенных схемах зелеными стрелками обозначены потоки проксируемого трафика. Движение данных потоков в Linux чаще всего регулируется силами правил iptables и настройками браузера. Кроме того, очень часто, функции маршрутизатора и прокси выполняет одна машина.
Установка SQUID
Перед установкой и настройкой squid необходимо настроить сеть linux и убедиться, что машина, на которой будет работать squid имеет доступ во внешнюю сеть и клиенты, которые будут использовать данный прокси имеют доступ к данной машине. Установка прокси-сервера squid как и другого ПО в Linux возможна различными способами, описанными в статье управление программным обеспечением в linux. Я затрону способ установки из репозитория в Debian. Итак, для установки squid необходимо установить пакет squid3, для этого выполнить вот такую команду:
Как видно, в конфигурации по умолчанию, прокси-сервер работает и разрешает обращения только с адресов 127.0.0.0/8. Следует внимательно просмотреть весь список и закомментировать строки с портами не нужных или не используемых сервисов. Более полное понимание данного конфига будет после прочтения следующих разделов. Т.о. если мы запустим консольный браузер lunx с указанием на наш прокси, то сможем увидеть заданную страницу:
Управление squid
Демон управляется init-скриптом /etc/init.d/squid3. Прокси-сервер представляет собой процесс /usr/sbin/squid3. Демон поддерживает множество параметров, с которыми можно ознакомиться в man squid, но в таких дистрибутивах, как Debian и RH для управления демоном вполне достаточно init-скрипта.
Проверить работоспособность сервера squid можно следующим образом:
Будет неправильно, если я не обращу внимание на следующий момент. При установке squid из репозиториев Вашего дистрибутива, пакет является уже настроенным и имеет какие-то заданные настройки по умолчанию. Например, расположение каталога журнала, каталога конфигурационных файлов, поддерживаемые методы проверки подлинности и множество других. Какие настройки задавать при сборке бинарного пакета определяется сборщиком пакета и сообществом, которое осуществляет поддержку дистрибутива. Если параметры по умолчанию Вас не устраивают, то необходимо будет установить squid из исходников.
Настройка squid
По умолчанию разрешение имени узла, на котором работает Squid, происходит при помощи gethostname(), в зависимости от установок DNS, он иногда не может однозначно определить имя, которое будет фигурировать в журналах и выводах об ошибках “Generated … by server.com (squid/3.0.STABLE2)”. Для корректной записи имени хоста, необходимо это имя (FQDN??) занести в параметр:
По умолчанию, squid принимает подключения на всех интерфейсах. Если у нас сервер одним из сетевых интерфейсов смотрит во внешний мир, то желательно ограничить подключения только на интерфейсе локальной сети (допустим, 10.0.0.10/24). За это отвечает параметр http_port:
Как работают данные параметры можно увидеть в следующем листинге:
Как видно, теперь демон работает только на интерфейсе заданной сети. Стоит так же отметить, что новые версии squid ( всем заданным спискам. При этом, все разрешающие правила необходимо указывать до запрещающего ВСЁ правила:
Может возникнуть резонный вопрос: зачем задавать данное правило, если мы, например, разрешим доступ к сквиду только избранным acl? Ведь остальные, кто не попадают в данный acl итак «проходят мимо». Все просто. По-умолчанию, squid использует разрешающее/запрещающее правило противоположное последнему. Например:
Для бОльшего удобства, можно задать эти правила в отдельном файле, указав путь к нему в место характеристики_типа_отбора. Вот:
Разрешим созданному списку доступа lan доступ в интернет и скажем сквиду перечитать конфигурационный файл:
Подводя маленький итог данному разделу, в двух словах можно сказать, что acl идентифицирует Web запрос, а http_access разрешает или запрещяет идентифицированный запрос. Теперь наши локальные клиенты с радостью пользуются интернетом, предварительно настроив браузер!
Настройка параметров кэша squid
Важным моментом настройки squid является настройка параметров кэширования в squid. Место размещения кэша задается параметром cache_dir в squid.conf. Формат параметр следующий:
Эксперимент показал, что при кэше в 700 МБ используется только 2 директории первого уровня. То есть для при стандартной структуре директорий кеша в него «с комфортом» влезает миллион объектов (9 GB), если их больше, то надо увеличить число директорий верхнего уровня
Можно использовать несколько cache_dir. Это положительно сказывается на производительности, особенно, если разместить кэш на разных дисках. Еще больше ускорить работу кэша можно, разместив кэш в tmpfs. Для каждого параметра cache_dir можно в разделе options определить параметр read-only (только чтение) и max-size (максимальный размер объекта).
Аналогично? есть и параметр minimum_object_size отвечающий за минимальный размер объекта, по умолчанию его значение “0” то есть отключен. Я рекомендую значение этого параметра увеличить до 2-3 Кб, что снизит нагрузку на диск при поиске маленьких объектов.
Объем ОЗУ, используемый сквидом задается в параметре cache_mem, значение по умолчанию 256 Мб (в версии 3.1). Данное значение я оставил по умолчанию. Менять это значение стоит лишь в том случае, если сквид вас об этом попросит в логах. После данных изменений, необходимо перезапустить сквид, при этом будет создана структура каталогов:
Пример настройки прозрачного прокси squid
Важно понимать и знать! Данный метод поддерживает только HTTP протокол, и не поддерживает gopher, FTP или другое проксирование. А так же, Squid не умеет одновременно работать в прозрачном режиме и в режиме аутентификации.
Для настройки прозрачного режима, необходимо:
1. Задать прозрачный режим в настройках прокси. Это делается в параметре http_port, например:
2. Завернуть пользователей соответствующим правилом на нужный порт силами iptables:
Все. Можно наслаждаться завернутыми и ничего не подозревающими пользователями на наш прокси-сервер.
Траблешуттинг
Формат log файлов Squid представляет собой строку из значений, разделенных одним или несколькими пробелами:
Рассмотрим на примере:
Некоторые заключительные моменты о squid3
В статье я рассмотрел основные принципы работы прокси сервера, а так же, базовые настройки, позволяющие реализовать простейший кэширующий сервер, а так же организовать работу squid в прозрачном (transparent) режиме. Squid поддерживает несколько вариантов авторизации (по IP, через LDAP, MySQL, NTLM и др.), возможности ограничения пропускной способности канала и контроля доступа к ресурсам интернет. Работу сквида с методами различной авторизации и примеры контроля трафика я рассмотрю в следующих статьях.
Что еще почитать:
В SQUID-FAQ есть много интересной и полезной информации, с которой определенно стоит ознакомиться: http://unix1.jinr.ru/faq_guide/net_management/squid/squid_faq.html
Описание разницы между 2 и 3 squid: http://www.tux.in.ua/articles/731
Перевод squid.conf: http://break-people.ru/cmsmade/index.php?page=translate_squid_conf_file
Еще один перевод: http://www.opennet.ru/base/net/squid_conf.txt.html
Много информации на русском о сквиде: http://squid.opennet.ru/
Отличная книга Squid Proxy Server 3.1 Beginner’s Guide Saini K. (http://books.google.ru/books/about/Squid_Proxy_Server_3_1.html?id=C_c7mAEACAAJ)
Squid. The definitive guide (http://etutorials.org/Server+Administration/Squid.+The+definitive+guide/ )
Upd 2012.02.26: добавил информацию о конфигурации по умолчанию
Upd 2012.03.30: дополнил информацию о http_access
Upd 2012.04.07: дополнил некоторую информацию
Upd 2012.04.08: добавил Squid Proxy Server 3.1 Beginner’s Guide
Настройка squid или как не купить платное решение
Часто в организациях используем разного рода прокси, прокси как составляющая программного шлюза или самостоятельный классический вариант squid + анализатор логов и т.п.
Мы пытались внедрить решение от Ideco и ИКС, в итоге остановились на squid. Под катом история пути и техническая информация по настройке старого доброго кальмара.
Начну пожалуй с того, что конечно странно на habr в 2018 году видеть статью про настройку squid, но тем не менее, даже в нынешние время платные продукты могут уступать по некоторым пунктам open source софту который так или иначе лежат в основе платного продукта с красивым интерфейсом.
Всё началось с того, что руководство дало ясно понять что мы можем позволить себе купить интернет биллинг.
Требования следующие: интеграция в Windows AD, полное управление пользователями из AD, шейпер скорости, фильтрация по типу контента, по спискам сайтов, возможность дать доступ всей сети к локальным ресурсам компании.
В сети компании насчитывается свыше 550 компьютеров. Большинству из них нужен доступ к внутренним ресурсам.
Все разворачивалось в виртуальной среде, сервер виртуализации Hyper-v core — Неверный выбор, о причинах изложу в конце статьи.
Немного о выборе конкурсантов, UserGate помню его из времен начала работы в IT, по старой памяти приложение windows — по умолчанию не подходит.
Интернет Контроль Сервер (ИКС)- дело дошло до тестов. Удалось корректно загрузить из 10 только 2 раза, отмечая его отличную нестабильность пошли дальше. К стати, не могу не отметить юмор разработчиков, кто в курсе тот поймет! Продукт развивается, может быть уже проблем нет, но и задача решена.
Ideco — мне понравилось, отличное решение, но в функционал включен не только интернет биллинг, это полноценный шлюз со всеми плюшками, для нас лишнее. Но тем не менее он прошел полный тест, возникло 2 непреодолимых препятствия:
1. Невозможно дать доступ к определенным ресурсам всей сети или всем пользователям домена — по умолчанию не считая таких пользователей за пользователя которого нужно лицензировать.
1.1 — Из пункта 1 вытекает немалая цена, т.к. у нас в компании довольно много компьютеров которым необходимо подключение к внутренним web сервисам и не нужен доступ в интернет, покупать лицензии для использования внутренних ресурсов мы не планировали, также не планировали разводить зоопарк серверов раздающих интернет.
2. IP адрес компьютера жестко привязывается к имени пользователя который первый прошел аутентификацию на прокси, так при смене сотрудника нужно было в админ. панели удалять привязку в ручном режиме, что конечно не отвечает требованию управлять всем через AD.
Кстати, шлюз ideco доступен в бесплатной версии до 40 пользователей и без привязки к AD. Также появился IDECO SELECTA, или я не заметил его выпуска или он был выпущен уже после всех тестов.
После всех пройденных этапов было решено своими силами сделать все на squid но с поправкой на наши технические требования, что из этого получилось читайте далее.
Начнем с того, что корректных и полных мануалов в сети нет, есть некоторые части, но все инструкции сводились на нет новыми релизами сквида.
Мы используем ubuntu server, следовательно следующая информация актуальна для этой ОС и с другими ОС может серьёзно различаться.
Все в командной строке нужно делать из под sudo, далее дописывать перед каждой командой sudo не буду.
Настройка OS ubuntu server 16.04:
Т.к. мы используем Hyper-v виртуализацию то мы установили необходимые пакеты.
Качаем с оф сайта сквид, в данном посте разбираем версию 3.5.26, для других версии возможно будет неактуально. UPD в докере настроил 3.5.28 полет нормальный.
Распаковываем в home или любой другой каталог.
Указываем какие пакеты нам нужны, можете ненужное удалить или что-то добавить. Кому-то покажется что тут куча лишнего. Список взять из установленной версии сквида и добавлены дополнительные пакеты.
—with-openssl=/usr/lib/ssl/ — указываем путь до openssl, указан дефолтный путь в ubuntu server.
—disable-ipv6 — выключаем ipv6 — о причинах читайте ниже.
—enable-ssl-crtd — это для связки генерации ssl сертификатов для bump.
Возможно будут зависимости, нужно их установить.
По умолчанию все устанавливается в /etc/squid/
Создаем папку внутри /etc/squid для ssl сертификатов:
Создаем сертификат:
Переходим в каталог
Конвертируем сертификат в понятный для браузера формат
Создаем базу сертификатов:
Обращаю Ваше внимание на то, что имя прокси сервера и имя указанное при создании сертификата должно быть одинаковое. Формат squid3.domain.local.
Полученный squid3domainlocal.der через групповые политики или вручную вносим в доверенные центры сертификации. Прокси сервер в браузере указываем не ip а полное имя компьютера, к примеру squid3.domain.local.
Создаем обычного пользователя в домене, пусть будет squid3.
Для прохождения аутентификации через kerberos нам нужен keytab пользователя squid3 для principal HTTP/squid3.DOMAIN.LOCAL@DOMAIN.LOCAL, при стандартном входе в домен через net ads создается keytab /etc/krb5.keytab, но в нем указаны principal не http а host. Что делает невозможным проходить аутентификацию пользователей через web браузер. Если Вы расположили keytab в /etc/krb5.keytab и после вводите в домен саму машину, то keytab просто будет дополнен новыми principal.Но обращаю Ваше внимание на то, что устанавливать пакет samba и вводить машину в домен не нужно, достаточно сгенерированного keytab для пользователя.
Далее идем на домен контроллер и выполняем нехитрую команду:
Переносим полученный файл на прокси сервер и далее помещаем в удобное расположение, я выбираю /etc/krb5.keytab.
Если Вы хотите сделать авторизацию еще и для web сайта, статистика или внутренний портал компании то нужно создать группу и включить туда пользователей proxy и www-data.
Добавляем необходимых пользователей в группу:
Назначаем владельцев на krb5.keytab
Если нет необходимости дополнительным сервисам давать доступ, то группу не создаем, просто выставляем владельцев и права:
Чтение и запись для root, только чтение для allowreadkeytab и без доступа для остальных.
Обращаю Ваше внимание, что ниже squid.conf не будет содержать все acl и все правила, будут лишь по 1 примеру настройки, полная настройка acl и листами доступа к сайтам и т.п. будет слишком объемной. Ниже приведенный конфиг можно рассматривать как требующий доработки под свои нужды.
Переходим к настройке squid:
Тут важный момент, есть сайты которые поднимают соединение непосредственно с «компьютером», и аутентификация пользователя не производится. Как следствие происходит блокировка соединения. Для обхода этой проблемы дается доступ конкретному ip к конкретному сайту.
Acl для определения типа контента:
acl application_mime rep_mime_type application/octet-stream
acl video_mime rep_mime_type «/etc/squid/ban/mime_type_video.txt»
Также фильтровать некоторый контент можно по url, для этого создаем acl:
Есть еще любопытный acl allowerrorsert, т.к. мы не разрешаем по умолчанию доступ к сайтам с кривыми сертификатами, я использую allowerrorsert для определения перечня разрешенных сайтов с «кривыми» ssl. Об этом не много ниже.
Также есть возможность управлять доступом к сайтам на основе ssl правил, но на мой взгляд эффективнее управлять через http_access. Вот пример acl для использования в правилах ssl:
Ниже мы еще вернемся к этому типу acl и их применению.
Позволяет видеть в расширенном режиме запросы POST и mime.
Аутентификация и авторизация пользователя в группе active direcory через kerberos:
Тут следует остановиться и разобрать подробнее, children — максимальное количество процессов доступные для запуска, startup количество процессов которые запущены всегда, idle максимальная очередь к помощнику при превышении указанного числа будет запускаться новый процесс помощника.
Небольшое отступление по работе авторизации:
Тут есть особенность, дело в том, что некоторые сайты пытаются подключить вагон разных ресурсов и картинок с других сайтов, собрать кучу статистики и прочее, каждый запрос проходит авторизацию это может вызвать большую очередь к процессу помощника авторизации, можно просто увеличить children, увеличить idle… но это только на первый взгляд, запросов от 1 пользователя может быть несколько десятков тысяч, что за собой несет большую очередь. При появлении большой очереди нагрузка на CPU зашкаливает. В условиях большого количества пк и малой доли пользователей с полноценным доступом в интернет, установленный на пк chrome создавал прям удивительное количество соединений — 500 тыс. запросов на clients1.google.com в сутки. Как следствие были пики очередей.
Подробности решения в конце статьи, где будут описаны некоторые технические моменты решение возникших проблем в процессе отладки.
Поиск пользователя в группе:
Если Вы обратили внимание, то две строки отличаются, в 1 непонятный набор букв и цифр во второй все ясно… В первой строке указана группа «Пользователи домена», не желая разбираться с кириллицей в конфиге сквида и работе хелпера, я решил сделать так, это единственная группа в AD которая связана с этим сервисом имя которой написано кириллицей. Синтаксис тоже изменен, с g что означает группу на T.
Обещал рассказать почему отключил ipv6, это была длинная история, не шла авторизация у пользователя потому что я не указал в строке external_acl_type. ipv4 т.к. мы не используем ipv6 да и мало кто использует в локальных сетях решено было вообще отключить чтобы избежать подобных проблем. На сёрфинге интернета это тоже никак не отражается.
Группы для ограничения скорости:
internet-allow-speed — Группа созданная в AD.
Так как группы и пользователей мы получаем из внешнего хелпера, нам нужно определить acl в синтаксисе squid для работы http_access и т.д.
Далее следуют разрешающие и блокирующие правила. Правила работают как обычно по цепочке, все что cверху имеет большее значение.
Тут начинается bump, в строке http_port указываем порт и указываем функцию ssl-bump далее включаем генерацию сертификатов, далее размер кеша, далее указываем сам сертификат к слову который добавлен в качестве доверенного центра сертификации на компьютерах домена, далее ключ.
Схема работы следующая, клиент заходит на сайт google.com, клиент устанавливает соеденение ssl с прокси, а прокси в свою очередь с сайтом, прокси поднимает ssl с сайтом и отдельно ssl с клиентом выступая при этом посредником.
эта схема при полном бампе соединения, можно разбирать не полностью, а только для 1 из сторон, я не нашел этому применения, поэтому мы это не используем. К тому же чтобы видеть весь трафик открыто, как http, подходит только эта схема.
настройки помощника который генерирует ssl сертификаты для сайтов:
Cоздаем acl с шагами bump, существует всего 3 шага, sslbump1 смотрит на открытую информацию в сертификате, та которая доступна всем.
sslbump2 создает соединение с сайтом sslbump3 создает соединение с клиентом.
Указываем acl которые будут внесены в исключения при работе с sslbump
В bank.txt и allowsplice.txt находятся имена доменов.
Это правило разрешает принимать сертификаты с ошибкой, т.e. просроченный, самоподписанный, выданных на другой хост и т.п. Мы создавали acl для этого правила выше.
splice — пропустить все последующие действия т.е. не делать bump пропустить как есть.
peek — подсмотреть доступную инфу без полного бампа
terminate — закрыть соединение, не используем, фильтруем через http_access
bump — «влезает» в соединение, делает https видимым как http
Закрываем доступ всем.
Режем скорость, указываем сколько пулов задержки мы используем:
VIP-пользователи, избранные сайты без ограничений по скорости
В нерабочее время — Интернет отключается (до 100КБ/сек.)
Ограничение на закачку — до 10MB загружают весь канал без ограничений, свыше только 100 КБ/С
В синтаксисе лога изменена буква a на большую A, вот тут: %6tr %>A. Это дает возможность в логах видеть имя компьютера вместо его IP адреса, что конечно удобней.
Не много о проблемах и об особенностях которые возникали.
Прокси сервер выведен в отдельную dmz, файрволом жестко ограничен доступ в dmz и из нее. Т.к. сквид постоянно опрашивает dns и kerberos по udp преимущественно, то он незамедлительно превышал допустимое количество подключений с 1 ip, на сервер AD который находится в другой dmz, соединения сбрасывались. Проблема была неочевидная, хелпер авторизации падал, клиент получал окно аутентификации.
Ошибка выглядит так:
support_krb5.cc(64): pid=36139 :2017/10/24 08:53:51| kerberos_ldap_group: ERROR: Error while initializing credentials from keytab: Cannot contact any KDC for realm ‘DOMAIN.LOCAL’
Решили проблему подняв bind на прокси сервере, количество запросов значительно уменьшилось. В целом можно было отключить ограничения на файрволе, что собственно и сделали, но bind всё же хорошая идея позволяющая значительно снизить количество соединений.
support_sasl.cc(276): pid=8872 :2017/10/24 06:26:31| kerberos_ldap_group: ERROR: ldap_sasl_interactive_bind_s error: Local error
support_ldap.cc(957): pid=8872 :2017/10/24 06:26:31| kerberos_ldap_group: ERROR: Error while binding to ldap server with SASL/GSSAPI: Local error
В bind нужно скопировать обратную зону.
UPD — Самое интересное
Возникла проблема с высокой нагрузкой на cpu и io, проц грузил в основном negotiate_kerberos io грузил ext_kerberos_ldap_group_acl, понятное дело что negotiate_kerberos запускал ext_kerberos_ldap_group_acl, нагрузка была не постоянная, два раза в день по 30 минут.
В конечном итоге ssl_bump включен, работает без нареканий. Если идет куча запросов на хост который недоступен по таймауту, вот тут возникают пики. На уменьшение очереди в основном повлияло исключение clients1.google.com и clients2.google.com из прокси.
Решать дать доступ к clients1.google.com и clients2.google.com, отключить задание на обновление или исключить эти хосты из прокси решать Вам.
Относительно hyper-v, в целом всё работает стабильно, uptime обычно превышает два месяца, но наступает тот день когда абсолютно на ровном месте без ошибок в логах и какой-либо нагрузки зависают виртуальные машины или выполняется их перезагрузка, но при этом последующая загрузка не приводит загрузке рабочего состояния. Приходится делать сброс и последующая загрузка производится нормально, прошу прощения за тавтологию. При всех равных на указанном сервере крутится две виртуалки ubuntu server 16.04 и у обоих происходит ода и та же проблема с разницей между ними в несколько дней, потом опять uptime не менее 2 месяцев. Для решения этой проблемы переносим сквид в докер, следующую статью оформлю про настройку сквида в докере, в целом мало чем отличается кроме целой кучи зависимостей.
Редактируем и вставляем:
Для его работы нужно установить apache2:
Рассказывать о том, как настаивать его не буду, по ссылкам довольно понятно и доступно. Обращу внимание лишь на одно, пока не будет сгенерирован первый отчет — по web адресу ничего не появится, будет ошибка.
Как только будет сформирован первый отчет, Вы получите заветную страничку с отчетами.
Стоит отметить что страницу с отчетами можно стилизовать под Вашу компанию, сменить логотипы, подписи, фон и т.п. Часть следует менять в основном конфиге:
И в скрипте который является шаблоном для /usr/bin/squid-analyzer:
Статья писалась с перерывами, периодически дополнялась и корректировалась, надеюсь она будет полезна.
Ниже листинг подчищенного конфига, его следует использовать как образец, не подлежит копипасту, это не даст рабочий экземпляр, нужно создавать файлы которые указаны в acl, заполнять их и т.д.
В процессе отладки очень помог awk, команда которая выводит и группирует столбцы: