Squid 5 что нового
Squid с фильтрацией HTTPS без подмены сертификата, интеграция с Active Directory 2012R2 + WPAD
1.1 Упрощенная схема работы WPAD
— Клиент на ОС Windows обращается к DNS-серверу с запросом на хост wpad.example.ru, и DNS-сервер имя соответствующую запись указывает куда обратиться. Далее, клиент обращается к wpad.example.ru с запросом на файл настроек. Получив его, начинает действовать соответственно инструкций в нём.
1.2 Чем хороша данная технология
— нет необходимости через GPO прописывать всем клиентам адрес-прокси
— Мобильность сотрудников (доступ к интернету вне офиса)
— Чтобы отключить использование данной технологии, достаточно отключить в «Свойствах браузера» — «Автоматическое получение настроек»
— «Автоматическое получение настроек» можно отключить любому пользователю, поэтому данную функцию лучше оставить включенной и запретить ее изменение через GPO
1.3 Squid Peek-n-splice — how to it works
Сотрудник пытается зайти на сайт с https через прокси. При установке зашифрованного соединие происходит «приветствие», которое передается в открытом виде, прокси-сервер его перехватывает, и исходя из конфигурации, squid разрешает или запрещает соединение. Т.е. перехватили на посмотреть «приветствие», разрешили или дропнули соединение.
1.4 Плюсы и минусы Peek-n-splice
— Это не MITM-атака, и не будет проблем с банк-клиентами
— Отображение доменных имен в статитстике сайтов запрашиваемых по https
— К сожалению, нельзя полностью просмотреть какая именно интернет-страница была открыта как при MITM-атаке
— Данная конфигурация хорошо себя показала только на CentOS (на Debian были проблемы, через некоторое время случался kernel-panic)
1.5 И так, теперь стоит отметить что дано
2 Конфигурирование операционной системы и установка Squid
Процесс установки CentOS описывать нет смысла. Так что будем иметь в виду, что у нас свежеустановленный CentOS 7 x64. Итак, чтобы Squid работал одинаково хорошо с http и https трафиком, необходимо следующее:
2.1 Squid должен быть собран с такими параметрами
Либо же можно скачать архив с собранным squid и его зависимостями.
2.2 Установка необходимых пакетов из официальных репозиториев
Стоит отметить, что для установки кальмара нужны некоторые зависимости. К сожалению, у CentOS довольно скудные официальные репозитории, поэтому некоторые пакеты надо качать с неофициальных. Установка необходимых пакетов из оф.репозиториев:
2.3 Ручная установка Squid и дополнительных пакетов
Если что-то не так, в терминале отобразится чего не хватает.
2.4 Установка прав доступа для каталога swap
2.5 конфигурационный файл /etc/squid/squid.conf
acl localnet src 10.0.0.0/24
acl localnet src 192.168.0.0/24
acl my_full external inet_full
acl my_medium external inet_medium
acl my_low external inet_low
acl auth proxy_auth REQUIRED
# помимо дефолтного 443, для себра бизнес онлайн нуже доп. порт 9443
acl SSL_ports port 443 9443
acl Safe_ports port 80 # http
acl Safe_ports port 21 # ftp
acl Safe_ports port 443 # https
acl Safe_ports port 70 # gopher
acl Safe_ports port 210 # wais
acl Safe_ports port 1025-65535 # unregistered ports
acl Safe_ports port 280 # http-mgmt
acl Safe_ports port 488 # gss-http
acl Safe_ports port 591 # filemaker
acl Safe_ports port 777 # multiling http
acl CONNECT method CONNECT
#В данной конфигурации whitelist — это список разрешенных сайтов для группы пользователей Internet-low@EXAMPLE.RU (доступ только на те сайты, которые в whitelist.txt)
#А blocked_http.txt — список запрещенных сайтов для группы Internet-medium@EXAMPLE.RU (на все сайты можно заходить, кроме тех, которые в blocked_http.txt)
acl white_list dstdomain «/etc/squid/whitelist.txt»
acl black_list dstdomain «/etc/squid/blocked_http.txt»
dns_nameservers 10.0.0.9
http_access deny my_medium black_list
http_access allow my_medium
http_access allow my_low white_list
http_access deny my_low all
http_access allow my_full
# Разрешаем локалхост
http_access allow localhost
# Запрещаем все остальное
http_access deny all
#Непрозрачный порт, через который происходит взаимодействие клиентских хостов с прокси-сервером
http_port 10.0.0.10:3130 options=NO_SSLv3:NO_SSLv2
always_direct allow all
sslproxy_cert_error allow all
sslproxy_flags DONT_VERIFY_PEER
#Данная опция нужна для корректной работы peek-n-splice. Сам файл blocked_https.txt ни на что не влияет, но и он не должен быть пустым. Магия.
#
acl blocked ssl::server_name «/etc/squid/blocked_https.txt»
acl step1 at_step SslBump1
ssl_bump peek step1
#терминируем соединение, если клиент заходит на запрещенный ресурс
ssl_bump terminate blocked
ssl_bump splice all
cache_dir aufs /var/spool/squid 20000 49 256
maximum_object_size 61440 KB
minimum_object_size 3 KB
#httpd_suppress_version_string on
#visible_hostname PROXYSERVER
cache_swap_low 90
cache_swap_high 95
maximum_object_size_in_memory 512 KB
memory_replacement_policy lru
logfile_rotate 4
2.6 Предварительно необходимо привести файл /etc/hosts к такому содержанию
2.7 Настраиваем selinux
В файле /etc/selinux/config должно быть значение:
Устанавливаем пакет для работы с selinux:
Добавляем правила selinux
Разрешаем подключения к кальмару:
Разрешаем подключения к кальмару на 3130 порту:
После изменения параметров selinux, необходимо перезагрузить систему для их применения.
2.8 генерация swap
2.9 Включение демона squid, проверка конфигурационного файла
Варнингов и эрроров не должно быть. Если же что-то есть — необходимо проверить настройки.
2.10 Разрешаем форвардинг трафика
Применяем настройку налету:
3 Интеграция с контроллером домена Active Directory 2012R2
Интеграция с контроллером домена необходима для того, чтобы пользователи домена могли авторизовываться на прокси-сервере по протоколу Kerberos. Самое разумное решение — оставить только Kerberos ввиду того, что данный метод самый безопасный, авторизация происходит автоматически. Что же касается клиентских машинах которые вне домена, то и здесь нет проблем, логин и пароль можно ввести вручную во всплывающем окне авторизации. Проверено, работает.
3.1 Конфигурационный файл /etc/krb5.conf
Конфигурационный файл /etc/krb5.conf необходимо привести к следующему виду:
[libdefaults]
default_realm = EXAMPLE.RU
ticket_lifetime = 24h
default_keytab_name = /etc/krb5.keytab
[realms]
EXAMPLE.RU = <
kdc = dc1.example.ru
admin_server = dc1.example.ru
default_domain = example.ru
>
[domain_realm]
.example.ru = EXAMPLE.RU
example.ru = EXAMPLE.RU
3.2 Создание DNS-записи
Всем отлично известно, что Active Directory тесно завязан с DNS, и для корректной работы авторизации, необходимо создать узел (A или ААА) c указание имени хоста и его ip-адреса (Получается запись sq.example.ru c ip-адресом 10.0.0.10).
3.3 Варианты интеграции с доменом
И так, есть два стула варианта интеграции с доменом. Первый вариант — средствами Windows (ktpass), второй вариант — средствами Linux (Msktutil). Windows вариант хорош тем, что можно отключить срок действия пароля для пользователя squid. Версия Linux хороша тем, что можно вводить в домен через создание учетной записи компьютера.
3.3.1 Интеграция средствами Windows
Создаем пользователя в AD, например squid
Теперь генерируем krb5.keytab. В командной строке на контроллере домена с правами администратора необходимо выполнить данную команду:
Сам файлик krb5.keytab переместить (Можно при помощи WinSCP) на sq.example.ru в каталог /etc.
3.3.2 Интеграция средствами Linux
В архиве со сквидом и зависимостями также приложен msktutil, устанавливаем его:
Теперь выполняем следующую команду:
В случае успеха, вывод команды будет большим, копировать сюда не вижу смысла. Ошибок и варнингов быть не должно. Стоит обратить внимание на —computer-name sq-k это не опечатка. Имя хоста должно отличаться.
В виду необходимости обновлять пароль для учетной записи компьютера, делать это можно через cron.
В него необходимо добавить задание:
3.4 Рекомендуемые права на файл krb5.keytab
После перемещения krb5.keytab, рекомендуется понизить права доступа к файлу
3.5 Группы доступа AD
В ActiveDirectory в OU Users необходимо создать три группы, согласно которых будет распределен доступ в Интернет: Internet-full, Internet-medium, Internet-low.
3.6 Проверка авторизации
Проверка авторизации в Active Directory при помощи файла /etc/krb5.keytab
Вывод команды должен быть примерно такой:
А klist должен отобразить следующее:
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: HTTP/sq.example.ru@EXAMPLE.RU
Valid starting Expires Service principal
09.10.2016 22:19:20 10.10.2016 08:19:20 krbtgt/EXAMPLE.RU@EXAMPLE.RU
renew until 10.10.2016 22:19:20
На это настройка Squid практически закончена, теперь перезагружаем хост для применения настроек. После перезагрузки для теста можно вручную прописать прокси в настройках sq.example.ru указав порт 3130.
4 WPAD
4.1 Установка и конфигурирование web-сервера apache2
После установки включаем в автозагрузку:
Если попробовать открыть в браузере доменное имя sq.example.ru, должна открыться тестовая страница apache2.
Далее необходимо создать /var/www/html/wpad.dat файл со следующим содержанием:
4.2 Описание файла wpad.dat
По дефолту в каталоге /var/www/html/wpad.dat файл отдается всем без дополнительных настроек apache2, а это как раз необходимо для корректного взаимодействия с клиентскими машинами на ОС Windows.
Если запрашиваемый ресурс не попадает под вышеперечисленные условия, выполняется следующее:
4.3 Создание CNAME
На DNS-сервере Active Directory необходимо создать cname wpad (FQDN wpad.example.ru) на sq.example.ru.
Для проверки необходимо открыть в браузере wpad/wpad.dat и файл wpad.dat должен автоматически скачаться. Таким образом, все хосты скачивают данный файл, и исходя из содержимого действуют. Рекомендуется сделать релог или перезагрузить все компьютеры в домене на ОС Windows, чтобы произошло скачивание файла.
5 Статистика
5.1 Установка SARG из исходников
Если не был установлен gcc ранее, сейчас самое время:
В файле po/Makefile.in.in указана версия gettext как 0.18, чтобы не было ошибки при make install, необходимо изменить на 0.19:
5.2 Конфигурирование SARG
Стандартный файл конфигурации /usr/local/etc/sarg.conf лучше забекапить:
Теперь создаем файл sarg.conf со следующим содержанием:
5.3 Расписание генерации отчетов при помощи cron
Данная строчка указывает, что отчеты будут генерироваться каждый день и за текущий день в 23:55
5.4 Конфигурация web-сервера
На ранее установленный веб-сервер можно еще возложить задачу отображение отчетов, с запросом ввода логина и пароля для авторизации. Создаем файл /etc/httpd/conf.d/sarg.conf со следующим сожержанием:
Alias /reports /var/www/html/squid-reports/
AuthType Basic
AuthName «Basic Authentication»
AuthUserFile /etc/httpd/conf/.htpasswd
require valid-user
AddDefaultCharset UTF-8
5.5 Авторизация на сайте со статистикой
Генерация файла логина и пароля для авторизации
При попытке открыть sq.example.ru/reports будет предложено ввести логин и пароль. В случае успешной авторизации можно просмотреть статистику.
6 Групповые политики
Здесь все неоднозначно и может зависит, от каких-то особенностей. В текущей задаче было разумным решением исключить возможность установки прокси-сервера пользователя, или же отключения «Автоматического определения параметров».
6.1 Редактирование GPO
Для запрета ввода прокси-сервера или изменения настроек по автоматическому определению параметров, можно воспользоваться групповой политикой. Создаем и связываем групповую политику с OU например, office.
Редактируем групповую политику:
Пользователь → Политики → Административные шаблоны → Компоненты Windows → Internet Explorer
В данном каталоге найти параметры и перевести в статус «Включено»:
«Запретить изменение параметров прокси»
«Отключить изменение параметров автоматической»
В заключение сказать могу вот что, данная конфигурация успешно работает по настоящее время с весны 2016-го, и отлично себя зарекомендовала. На все вопросы буду рад ответить.
UPD №1: 12.11.16
1 Были убраны из конфига сквида лишние строки портов 3128 и 3129.
2 включил selinux и добавил правила.
3 Была убрана генерация сертификата из мануала(без него работает)
4 Мелкие исправления
UPD №2: 20.11.16
1 Были убраны из конфига krb5.conf лишние строки
2 Добавлен метод интеграции с AD через Msktutil
3 Добавлен форвардинг
4 Обновлен архив со сквидом и зависимостями
Настройка 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, команда которая выводит и группирует столбцы: