Установка squid для linux

Как установить и настроить прокси-сервер Squid в Ubuntu 20.04

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

В этом руководстве объясняется, как настроить прокси-сервер Squid на Ubuntu 20.04 и настроить веб-браузеры Firefox и Google Chrome для его использования.

Установка Squid на Ubuntu

Пакет squid включен в стандартные репозитории Ubuntu 20.04. Чтобы установить его, выполните следующие команды от имени пользователя sudo :

После завершения установки служба Squid запустится автоматически. Чтобы убедиться в этом, проверьте статус сервиса:

Результат будет выглядеть примерно так:

Настройка Squid

Сервис squid можно настроить, отредактировав файл /etc/squid/squid.conf . Файл конфигурации содержит комментарии, описывающие, что делает каждый параметр конфигурации. Вы также можете поместить свои параметры конфигурации в отдельные файлы, которые можно включить в основной файл конфигурации с помощью директивы «include».

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

Чтобы начать настройку вашего экземпляра squid, откройте файл в текстовом редакторе :

По умолчанию squid настроен на прослушивание порта 3128 на всех сетевых интерфейсах сервера.

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

Запуск Squid на всех интерфейсах и на порту по умолчанию должен подойти большинству пользователей.

Squid позволяет вам контролировать, как клиенты могут получать доступ к веб-ресурсам, используя списки контроля доступа (ACL). По умолчанию доступ разрешен только с локального хоста.

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

Вместо добавления IP-адресов в основной файл конфигурации создайте новый выделенный файл, который будет содержать разрешенные IP-адреса:

После этого откройте основной файл конфигурации и создайте новый ACL с именем allowed_ips (первая выделенная строка) и разрешите доступ к этому ACL с помощью директивы http_access (вторая выделенная строка):

Порядок правил http_access важен. Убедитесь, что вы добавили строку перед http_access deny all .

Директива http_access работает аналогично правилам межсетевого экрана. Squid читает правила сверху вниз, и когда правило совпадает, правила ниже не обрабатываются.

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

Squid аутентификация

Если ограничение доступа на основе IP не работает для вашего варианта использования, вы можете настроить squid на использование серверной части для аутентификации пользователей. Squid поддерживает базовую аутентификацию Samba , LDAP и HTTP.

В этом руководстве мы будем использовать базовую аутентификацию. Это простой метод аутентификации, встроенный в протокол HTTP.

Чтобы сгенерировать зашифрованный пароль, используйте инструмент openssl . Следующая команда добавляет пару USERNAME:PASSWORD в файл /etc/squid/htpasswd :

Например, чтобы создать пользователя «josh» с паролем « P@ssvv0rT », вы должны запустить:

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

Откройте основную конфигурацию и добавьте следующее:

Первые три выделенные строки создают новый список контроля доступа с именем « authenticated , а последняя выделенная строка разрешает доступ аутентифицированным пользователям.

Перезапустите сервис Squid:

Настройка межсетевого экрана

Чтобы открыть порты Squid, включите профиль UFW ‘Squid’:

Если Squid работает на другом порту, отличном от порта по умолчанию, например, 8888 вы можете разрешить трафик на этом порту с помощью: sudo ufw allow 8888/tcp .

Настройка вашего браузера для использования прокси

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

Fire Fox

Приведенные ниже шаги одинаковы для Windows, macOS и Linux.

В верхнем правом углу щелкните значок гамбургера ☰ чтобы открыть меню Firefox:

Щелкните ссылку ⚙ Preferences .

Прокрутите вниз до раздела « Network Settings » и нажмите кнопку « Settings. .

Откроется новое окно.

• Установите переключатель « Manual proxy configuration ».
• Введите IP-адрес вашего сервера Squid в поле HTTP Host и 3128 в поле Port .
• Установите флажок Use this proxy server for all protocols .
• Нажмите кнопку OK , чтобы сохранить настройки.

На этом этапе ваш Firefox настроен, и вы можете просматривать Интернет через прокси-сервер Squid. Чтобы проверить это, откройте google.com , введите «what is my ip», и вы должны увидеть IP-адрес своего сервера Squid.

Чтобы вернуться к настройкам по умолчанию, перейдите в « Network Settings , установите переключатель « Use system proxy settings » и сохраните настройки.

Есть несколько плагинов, которые также могут помочь вам настроить параметры прокси Firefox, например FoxyProxy .

Гугл Хром

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

Чтобы запустить Chrome с новым профилем и подключиться к серверу Squid, используйте следующую команду:

Linux:

macOS:

Windows:

Если профиль не существует, он будет создан автоматически. Таким образом, вы можете запускать несколько экземпляров Chrome одновременно.

Чтобы убедиться, что прокси-сервер работает правильно, откройте google.com и введите «какой у меня IP». IP-адрес, отображаемый в вашем браузере, должен быть IP-адресом вашего сервера.

Выводы

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

Мы показали вам, как установить и настроить Squid в Ubuntu 20.04 и настроить ваш браузер для его использования.

Если вы столкнулись с проблемой или хотите оставить отзыв, оставьте комментарий ниже.

Источник

Установка и настройка Squid на Ubuntu

Данную инструкцию можно также применять для установки SQUID на Debian. В качестве клиентов могут использоваться Windows, Linux, Mac OS и любые браузеры.

Установка и базовая настройка

Устанавливаем прокси-сервер следующей командой:

apt-get install squid

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

Если сеть клиентских компьютеров отличается от стандартной (192.168.0.0/16, 172.16.0.0/12, 10.0.0.0/8), необходимо ее добавить в acl, например:

# TAG: acl
.
acl localnet src 217.66.157.0/24

# TAG: acl
.
acl localnet src «/etc/squid/acl_localnet»

* кавычки обязательны
** после необходимо создать файл /etc/squid/acl_localnet и с каждой строчки перечислить разрешенные IP-адреса.

С точки зрения безопасности, лучше закомментировать все подсети, которые не используются в нашей локальной сети, например:

# TAG: acl
.
#acl localnet src 0.0.0.1-0.255.255.255
#acl localnet src 10.0.0.0/8
#acl localnet src 100.64.0.0/10
#acl localnet src 169.254.0.0/16
#acl localnet src 172.16.0.0/12
acl localnet src 192.168.0.0/16
#acl localnet src fc00::/7
#acl localnet src fe80::/10

* в данном примере мы оставили только подсеть 192.168.0.0/16.

Разрешаем доступ для локальных сетей, которые заданы опцией acl localnet:

# TAG: http_access
.
http_access allow localnet

* данную опцию нужно либо раскомментировать, либо вставить выше опции http_access deny all.

Настраиваем директорию для кэша:

# TAG: cache_dir
.
cache_dir ufs /var/spool/squid 4096 32 256

* где ufs — файловая система (ufs для SQUID является самой подходящей); /var/spool/squid — директория хранения кэша; 4096 — объем пространства в мегабайтах, которое будет выделено под кэш; 32 — количество каталогов первого уровня, которое будет создано для размещение кэша; 256 — количество каталогов второго уровня, которое будет создано для размещение кэша.

systemctl stop squid

Создаем структуру папок под кэш следующей командой:

Запускаем squid и разрешаем его автозапуск:

systemctl enable squid —now

Проверка

Заходим в настройки браузера и настраиваем использование прокси-сервера. Например, в Mozilla Firefox настройки нужно выставить такими:

* где 192.168.163.166 — IP-адрес моего прокси-сервера.

Теперь открываем сайт 2ip.ru. После его загрузки мы увидим внешний IP-адрес — он должен соответствовать той сети, от которой работает настроенный SQUID.

Прозрачный прокси

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

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

# TAG: http_port
.
http_port 3128

И приводим ее к следующему виду:

# TAG: http_port
.
http_port 3128 transparent

И перезапускаем конфигурацию squid:

squid -k reconfigure

Авторизация по логину и паролю

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

# TAG: auth_param
.
auth_param basic program /usr/lib/squid/basic_ncsa_auth /etc/squid/auth_users
auth_param basic children 25
auth_param basic realm SQUID PROXY
auth_param basic credentialsttl 3 hours

* где /usr/lib/squid/basic_ncsa_auth — расположение ncsa_auth (в зависимости от системы может находиться в другом каталоге); /etc/squid/auth_users — файл с логинами и паролями; children 25 разрешает 25 одновременных подключений; SQUID PROXY — произвольная фраза для приветствия; credentialsttl 3 hours будет держать сессию 3 часа, после потребуется повторный ввод логина и пароля.

Создаем acl для пользователей, которые прошли регистрацию. Сделаем регистрацию обязательной:

# TAG: acl
.
acl auth_users proxy_auth REQUIRED

http_access deny !Safe_ports

И после нее добавляем:

http_access allow auth_users

Устанавливаем утилиту apache2-utils:

apt-get install apache2-utils

Создаем файл с пользователями и создаем первую пару логина и пароля:

htpasswd -c /etc/squid/auth_users user1

Создаем второго пользователя:

htpasswd /etc/squid/auth_users user2

И перечитываем конфигурацию squid:

squid -k reconfigure

Слушаем на определенном интерфейсе

По умолчанию, squid будет слушать запросы на всех сетевых интерфейсах, которые доступны серверу. Чтобы указать конкретный, добавляем его IP к http_port:

# TAG: http_port
.
http_port 192.168.1.15:3128

* в данном примере squid будет слушать на адресе 192.168.1.15.

И перечитываем конфигурацию squid:

squid -k reconfigure

Исходящий сетевой интерфейс

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

acl 217_66_157_33 localip 217.66.157.33
tcp_outgoing_address 217.66.157.33 217_66_157_33

acl 217_66_157_34 localip 217.66.157.34
tcp_outgoing_address 217.66.157.34 217_66_157_34

* в данном примере, при подключении к прокси через IP 217.66.157.33, исходящие пакеты будут от IP 217.66.157.33; аналогично для IP 217.66.157.34.

Перечитываем конфигурацию squid:

squid -k reconfigure

Настройка цепочки прокси-серверов

Мы можем передать запрос на другой прокси-сервер. Для этого открываем конфигурационный файл:

Настраиваем передачу запроса на другой прокси сервер:

# TAG: cache_peer
.
cache_peer 10.11.12.13 parent 3128 3128 proxy-only

* в данном примере мы передадим запрос на сервер 10.11.12.13. Синтаксис для cache_peer — cache_peer [options]:

• hostname — другой сервер, на который мы будем передавать запрос.
• type — тип «родства» другого сервера. Могут быть варианты:
  • parent
  • sibling
  • multicast
• http-port — номер порта, на котором партнер принимает HTTP-запросы.
• icp-port — порт для запроса кэша.
• options — дополнительный опции.

* более подробное описание можно найти в самом конфигурационном файле SQUID.

Если на прокси, к которому мы подключаемся, необходима авторизация, добавляем опцию login:

cache_peer 10.11.12.13 parent 3128 3128 proxy-only login=loginname:password

Запрещаем использование нашего прокси-сервера напрямую (не через cache_peer):

# TAG: never_direct
.
never_direct allow all

Источник

Настройка 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 к конкретному сайту.

. Важное примечание . Правило должно быть расположено выше правил с аутентификацией basic, ntlm, kerberos и др.

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 blockextention urlpath_regex -i «/etc/squid/ban/blockextention.txt»

Есть еще любопытный 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 функцию, загружают помощника для поиска пользователя в группе, можете сами выполнить в командной строке /usr/lib/squid3/ext_kerberos_ldap_group_acl -a -g internet-allow-all -D DOMAIN.LOCAL жмем enter и набираем имя пользователя, если пользователь будет найден в указанной группе, то ответ будет OK если нет то ERR. Обращаю внимание на то, что указанная группа internet-allow-all создана в AD.

Если Вы обратили внимание, то две строки отличаются, в 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 всё же хорошая идея позволяющая значительно снизить количество соединений.

Была еще 1 ошибка:

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 минут.

Изменение соотношения количества children и idle нужного результата не дало. В процессе отладки была ясная картина, при любой конфигурации в период пиков запускалось максимальное количество процессов аутентификации. Был проанализирован access.log, как результат анализа было выделено то, что в момент пиковой нагрузки было очень много ssl соединений, это натолкнуло на мысль что проблема кроется не в авторизации а в ssl_bump, для эксперимента был отключен ssl_bump, как результат было полное отсутствие нагрузки на протяжении всего дня. В целом в течении дня работа кальмара и его помощников не вызывала нарекании, но в определенные моменты приходило огромное количество соединений, сухие цифры: от 1 компьютера в единицу времени (5-15 мин) пришло 10000 запросов на ssl соединение которое попадает под правило bump. В другой день тоже самое с другого компьютера на .*whatsapp.net.

В конечном итоге 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, команда которая выводит и группирует столбцы:

Источник