Введение
Я успешно разобрался с настройкой sams2 под CentOS 7 и решил проделать то же самое на Freebsd 10.2. Мне нравится эта система. Не могу аргументировать чем именно, просто нравится и все. С нее началось мое первое знакомство с unix системами и с тех пор я стараюсь не забывать о ней, хотя работаю в ней все меньше и меньше.
Sams популярная и в своем роде уникальная система управления конфигурацией squid, которая работает через свой демон и php панель управления. Аналогов по удобству и функционалу я не встречал. Есть что-то похожее, но еще более старое, например STC. Но мне она внешне вообще не нравится, тоже очень старая и давно не развивается.
Можно схожий функционал реализовать отдельными средствами. Например, настроить ту или иную авторизацию в squid, создать списки доступа, списки ресурсов, включить все это. Потом анализировать логи, например, с помощью SARG. По идее, получится то же самое, что и самс, но управлять неудобно, отчеты в SARG не такие красивые и наглядные. В общем, не то.
Так что будем разбираться и настраивать самую последнюю из выпущенных версий самс — sams 2.0 от 1 апреля 2014 года.
Введение
Я успешно разобрался с настройкой sams2 под CentOS 7 и решил проделать то же самое на Freebsd 10.2. Мне нравится эта система. Не могу аргументировать чем именно, просто нравится и все. С нее началось мое первое знакомство с unix системами и с тех пор я стараюсь не забывать о ней, хотя работаю в ней все меньше и меньше.
Sams популярная и в своем роде уникальная система управления конфигурацией squid, которая работает через свой демон и php панель управления. Аналогов по удобству и функционалу я не встречал. Есть что-то похожее, но еще более старое, например STC. Но мне она внешне вообще не нравится, тоже очень старая и давно не развивается.
Можно схожий функционал реализовать отдельными средствами. Например, настроить ту или иную авторизацию в squid, создать списки доступа, списки ресурсов, включить все это. Потом анализировать логи, например, с помощью SARG. По идее, получится то же самое, что и самс, но управлять неудобно, отчеты в SARG не такие красивые и наглядные. В общем, не то.
Так что будем разбираться и настраивать самую последнюю из выпущенных версий самс – sams 2.0 от 1 апреля 2014 года.
Решение проблем
Предупреждение в cache.log:
WARNING: no_suid: setuid(0): (1) Operation not permitted
Баг Squid появился в версии 3.2, возникает на BSD-системах, из-за некорректного вызова функции setuid.
Баг-репорт: http://bugs.squid-cache.org/show_bug.cgi?id=3785
В зависимости от параметров конфигурации Squid, в некоторых случаях помогает изменение параметра daemon на stdio при указании пути к access.log-у.
Ошибка при запуске Squid:
FATAL: Bungled /usr/local/etc/squid/squid.conf line 64: acl manager proto cache_object
Начиная с версии 3.2 списки контроля доступа: manager, localhost и to_localhost являются предопределенными и создаются сквидом автоматически. При попытке их переопределения в файле конфигурации возникает ошибка. Данные параметры необходимо удалить из конфига.
Ошибка в cache.log:
ERROR: No forward-proxy ports configured.
Не задан порт для входящих подключений. Проверяем наличие в squid.conf директивы:
http_port 3128
В случае с прозрачным прокси, начиная с версии 3.2, необходимо задать две опции http_port. Одина для обычных запросов, вторая для перенаправляемого трафика:
http_port 3128 http_port 127.0.0.1:3128 intercept
При запуске Squid получаем следующие предупреждения:
WARNING: (A) '192.168.0.0/16' is a subnetwork of (B) '::/0' WARNING: because of this '192.168.0.0/16' is ignored to keep splay tree searching predictable WARNING: You should probably remove '192.168.0.0/16' from the ACL named 'all'
В файле конфигурации обнаружена декларация acl all. В третьей версии список контроля доступа all является предопределенным и создается сквидом автоматически. При попытке его переопределения в файле конфигурации возникает ошибка. Удалите или переименуйте acl all.
В cache.log постоянно пишутся предупреждения:
WARNING: transparent proxying not supported
При сборке не была включена поддержка прозрачного прокси для вашего брандмауэра. Переустановите Squid из коллекции портов с включением соответствующих параметров.
Настройка IPFW
Далее предполагается, что IPFW настроен на примере, предложенном в руководстве FreeBSD.
Открываем rc.conf:
ee /etc/rc.conf
Проверяем, включена ли маршрутизация:
gateway_enable="YES"
Если необходимо, включаем NAT:
natd_enable="yes" # Включить функцию NATD natd_interface="em0" # Название внешнего сетевого интерфейса natd_flags="-dynamic -m" # -m = по возможности сохранить номера портов
Находим параметры IPFW:
firewall_enable="YES" firewall_script="/etc/ipfw.rules"
Запоминаем путь к скрипту с правилами.
Редактируем список правил IPFW:
ee
Добавляем правила, выделенные красным, перед правилом, разрешающим доступ в интернет:
#!/bin/sh cmd="ipfw -q add" skip="skipto 500" # Внешний интерфейс pif=em0 ipfw -q -f flush # Разрешить SSH-доступ администратору с заданного IP-адреса # Раскомментируйте, чтобы не перекрыть себе доступ в случае проблем с настройкой брандмауэра #$cmd 001 allow ip from x.x.x.x to me dst-port 22 in via $pif #$cmd 001 allow ip from me to x.x.x.x src-port 22 out via $pif $cmd 002 allow all from any to any via em1 # разрешаем трафик на локальном интерфейсе $cmd 003 allow all from any to any via lo0 # разрешаем трафик на интерфейсе loopback $cmd 100 divert natd ip from any to any in via $pif $cmd 101 check-state # Разрешаем доступ пользователю Squid $cmd 124 allow all from me to any out via $pif keep-state uid squid # Отправляем http-запросы на порт прозрачного прокси $cmd 125 fwd 127.0.0.1,3128 tcp from any to any 80 out via $pif keep-state $cmd 130 $skip all from any to any out via $pif keep-state # Запрещаем весь входящий трафик с немаршрутизируемых адресных пространств #$cmd 300 deny all from 192.168.0.0/16 to any in via $pif #RFC 1918 для локальных IP $cmd 301 deny all from 172.16.0.0/12 to any in via $pif #RFC 1918 для локальных IP $cmd 302 deny all from 10.0.0.0/8 to any in via $pif #RFC 1918 для локальных IP $cmd 303 deny all from 127.0.0.0/8 to any in via $pif #loopback $cmd 304 deny all from 0.0.0.0/8 to any in via $pif #loopback # Закомментировать, если внешний интерфейс использует DHCP $cmd 305 deny all from 169.254.0.0/16 to any in via $pif #DHCP авто-конфигурации $cmd 306 deny all from 192.0.2.0/24 to any in via $pif #Зарезервировано для документации $cmd 307 deny all from 204.152.64.0/23 to any in via $pif #Sun cluster $cmd 308 deny all from 224.0.0.0/3 to any in via $pif #Class D & E multicast # Разрешаем входящие пакеты #$cmd 400 allow udp from xx.70.207.54 to any 68 in keep-state #$cmd 420 allow tcp from any to me 80 in via $pif setup limit src-addr 1 $cmd 450 deny log ip from any to any # Раздел skipto для правил с сохранением состояния для исходящих пакетов $cmd 500 divert natd ip from any to any out via $pif $cmd 510 allow ip from any to any ######################## Окончание файла правил ##################
Если менялись параметры rc.conf, включаем маршрутизацию и NAT. Будьте осторожны при настройке брандмауэра с внешнего IP, есть риск перекрыть себе доступ.
service routing restart service natd start
Загружаем обновленный список правил:
Инициируем веб-трафик с клиентского компьютера, проверяем лог доступа:
tail -f /var/log/squid/access.log
В случае проблем проверяем, работает ли правило брандмауэра:
ipfw show
Счетчик для правила перенаправления (fwd 127.0.0.1,3128) не должен быть нулевым.
Если перенаправление работает, но сайты не открываются, проверяем cache.log на предмет ошибок:
cat /var/log/squid/cache.log
Перенос логов доступа Squid
Логи доступа Squid могут занимать достаточно большой объем. На старых установках, где /var/log размещен на отдельном небольшом разделе, приходится перемещать лог доступа в /usr/local.
Создаем папку для логов, задаем права доступа:
mkdir -p /usr/local/squid/log chown root:squid /usr/local/squid/log chmod 770 /usr/local/squid/log
Останавливаем Squid:
service squid stop
Перемещаем логи в новое расположение:
mv /var/log/squid/* /usr/local/squid/log
Удаляем папку /var/log/squid и создаем ссылку на /usr/local/squid/log:
rmdir /var/log/squid ln -s /usr/local/squid/log /var/log/squid
Запускаем Squid:
service squid start
Отображение местного времени на страницах ошибок Squid
Из коробки на страницах ошибок Squid отображает время по Гринвичу, для отображения местного времени необходимо скорректировать шаблоны ошибок. Параметр шаблона %T указывает мировое время, %t — местное.
Копируем шаблоны ошибок в папку erros.local:
mkdir -p /usr/local/etc/squid/errors.local/ru cp /usr/local/etc/squid/errors/ru/* /usr/local/etc/squid/errors.local/ru
Заменяем общемировое время (%T), на местное (%t):
sed -i .bak "s/%T/%t/g" /usr/local/etc/squid/errors.local/ru/* && rm /usr/local/etc/squid/errors.local/ru/*.bak
Задаем путь к измененным шаблонам ошибок в squid.conf:
printf "\n\n #Местное время на страницах ошибок\nerror_directory /usr/local/etc/squid/errors.local/ru\n" >> /usr/local/etc/squid/squid.conf
Перенос логов доступа Squid
Логи доступа Squid могут занимать достаточно большой объем. На старых установках, где /var/log размещен на отдельном небольшом разделе, приходится перемещать лог доступа в /usr/local.
Создаем папку для логов, задаем права доступа:
mkdir -p /usr/local/squid/log chown root:squid /usr/local/squid/log chmod 770 /usr/local/squid/log
Останавливаем Squid:
service squid stop
Перемещаем логи в новое расположение:
mv /var/log/squid/* /usr/local/squid/log
Удаляем папку /var/log/squid и создаем ссылку на /usr/local/squid/log:
rmdir /var/log/squid ln -s /usr/local/squid/log /var/log/squid
Запускаем Squid:
service squid start
Устанавливаем php и phpextensions
Дальше устанавливаем php, настройки оставляем настройки по-умолчанию:
# cd /usr/ports/lang/php5 # make config-recursive # make install clean
После установки создаем файл конфигурации:
# cp /usr/local/etc/php.ini-production /usr/local/etc/php.ini
Устанавливаем расширения:
# cd /usr/ports/lang/php5-extensions # make config-recursive
Помимо настроек по-умолчанию, обязательно добавляем CURL, DOM, POSIX, FTP, GD, HASH, ICONV, XML, JSON, MBSTRING, MYSQL, MYSQLI, OPENSSL, SOCKETS, TOKENIZER, XMLREADER, ZLIB, EXIF, GETTEXT,
# make install clean
Теперь поставим модуль php для apache. Он теперь стал почему-то отдельным портом. Я не сразу первый раз сообразил, куда делся модуль, который всегда ставился вместе с портом php. В общем, ставим отдельно:
# cd /usr/ports/www/mod_php5 # make install clean
Для того, чтобы apache правильно обрабатывал php файлы, необходимо в конфиг httpd.conf добавить следующие строки:
<IfModule mod_php5.c> AddType application/x-httpd-php .php AddType application/x-httpd-php-source .phps DirectoryIndex index.php index.html </IfModule>
Теперь можно запустить apache и проверить, все ли у нас в порядке. Сначала проверим, нет ли у нас ошибок в конфигурации:
# apachectl -t AH00526: Syntax error on line 15 of /usr/local/etc/apache24/extra/httpd-vhosts.conf: Invalid command 'RewriteEngine', perhaps misspelled or defined by a module not included in the server configuration
У нас ошибка, модуль mod_rewrite не подключен. Чтобы это исправить, раскомментируем в конфиге апача строку
LoadModule rewrite_module libexec/apache24/mod_rewrite.so
Проверяем снова:
# apachectl -t AH00557: httpd: apr_sockaddr_info_get() failed for websrv.local AH00558: httpd: Could not reliably determine the server's fully qualified domain name, using 127.0.0.1. Set the 'ServerName' directive globally to suppress this message Syntax OK
Снова ошибка, но не критичная, можно работать и с ней, но мы все равно ее исправим. В фале httpd.conf находим строку со значением ServerName и приводим ее к виду:
ServerName websrv.local:80
Сохраняем файл, проверяем конфигурацию:
# apachectl -t Syntax OK
Все в порядке, можно стартовать apache:
# /usr/local/etc/rc.d/apache24 start
Проверяем, все ли запустилось:
# ps ax | grep httpd 60555 - Ss 0:00.06 /usr/local/sbin/httpd -DNOHTTPACCEPT 60556 - I 0:00.00 /usr/local/sbin/httpd -DNOHTTPACCEPT 60557 - I 0:00.00 /usr/local/sbin/httpd -DNOHTTPACCEPT 60558 - I 0:00.00 /usr/local/sbin/httpd -DNOHTTPACCEPT 60559 - I 0:00.00 /usr/local/sbin/httpd -DNOHTTPACCEPT 60560 - I 0:00.00 /usr/local/sbin/httpd -DNOHTTPACCEPT
Если получаете что-то подобное, значит все в порядке. Сейчас можно в браузере набрать http://ip-сервера/ и увидеть страничку с одной единственной надписью:
It works!
Это означает, что веб сервер apache работает, все в порядке.
Подмена заголовков в запросе клиента в Squid
Дело было на домашнем Debian-сервере. Один из интернет радио порталов напрочь отказывался воспроизводиться на моем музыкальном центре, настойчиво предлагая закрыть плейер и открыть браузер. К сожалению, не смотря на наличие интернета, браузер в музыкальном центре конструкцией не был предусмотрен. Пришлось замаскировать центр под браузер путем подмены заголовка User-Agent с помощью Squid’а и прозрачного проксирования.
Для подмены HTTP-заголовка, добавляем три опции в squid.conf:
Поскольку это безобразие нагло нарушает HTTP-стандарт, требуется сборка Squid с параметром LAX_HTTP, он же —enable-http-violations.
Настройки файервола для прозрачного проксирования
PF
ext_if_a="tun0" int_if_a="rl0" int_if_b="rl1" LanAll = "{10.90.90.0/24, 192.168.35.0/24, 192.168.1.0/24}" Lanint_if_b = "{10.90.90.0/24, 192.168.35.0/24}" # RDR transparent proxy rdr on $int_if_b inet proto tcp from $Lanint_if_b to any port 80 -> 127.0.0.1 port 3128 rdr on $int_if_a inet proto tcp from 192.168.1.0/24 to any port 80 -> 127.0.0.1 port 3128 # NAT nat on $ext_if_a inet from $LanAll to any -> ($ext_if_a)
Ошибка: IpIntercept.cc(316) PfInterception: PF open failed: (13) Permission denied. Для ее устранения нужно дать доступ (чтение) Squid к PF.
chown root:squid /dev/pf chmod 660 /dev/pf
Установка и базовая настройка
Устанавливаем прокси-сервер следующей командой:
apt-get install squid
Открываем на редактирование конфигурационный файл:
vi /etc/squid/squid.conf
Если сеть клиентских компьютеров отличается от стандартной (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 — количество каталогов второго уровня, которое будет создано для размещение кэша.
Останавливаем squid:
systemctl stop squid
Создаем структуру папок под кэш следующей командой:
squid -z
Запускаем squid и разрешаем его автозапуск:
systemctl enable squid —now
Онлайн курс по Linux
Если у вас есть желание научиться строить и поддерживать высокодоступные и надежные системы, рекомендую познакомиться с онлайн-курсом “Administrator Linux. Professional” в OTUS. Курс не для новичков, для поступления нужны базовые знания по сетям и установке Linux на виртуалку. Обучение длится 5 месяцев, после чего успешные выпускники курса смогут пройти собеседования у партнеров.
Что даст вам этот курс:
- Знание архитектуры Linux.
- Освоение современных методов и инструментов анализа и обработки данных.
- Умение подбирать конфигурацию под необходимые задачи, управлять процессами и обеспечивать безопасность системы.
- Владение основными рабочими инструментами системного администратора.
- Понимание особенностей развертывания, настройки и обслуживания сетей, построенных на базе Linux.
- Способность быстро решать возникающие проблемы и обеспечивать стабильную и бесперебойную работу системы.
Проверьте себя на вступительном тесте и смотрите подробнее программу по .
Дополнительные материалы по Freebsd
Онлайн курс Основы сетевых технологий
Теоретический курс с самыми базовыми знаниями по сетям. Курс подходит и начинающим, и людям с опытом. Практикующим системным администраторам курс поможет упорядочить знания и восполнить пробелы. А те, кто только входит в профессию, получат на курсе базовые знания и навыки, без воды и избыточной теории. После обучения вы сможете ответить на вопросы:
- На каком уровне модели OSI могут работать коммутаторы;
- Как лучше организовать работу сети организации с множеством отделов;
- Для чего и как использовать технологию VLAN;
- Для чего сервера стоит выносить в DMZ;
- Как организовать объединение филиалов и удаленный доступ сотрудников по vpn;
- и многое другое.
Уже знаете ответы на вопросы выше? Или сомневаетесь? Попробуйте пройти тест по основам сетевых технологий. Всего 53 вопроса, в один цикл теста входит 10 вопросов в случайном порядке. Поэтому тест можно проходить несколько раз без потери интереса. Бесплатно и без регистрации. Все подробности на странице .
Рекомендую полезные материалы по Freebsd: |
Описание установки Freebsd 11 на одиночный диск, либо на софтовый raid1, сделанный средствами zfs, которые поддерживает стандартный установщик. Базовая настройка Freebsd, которую можно выполнить после установки сервера общего назначения. Представлены некоторые рекомендации по повышению удобства пользования и безопасности. Описание и нюансы обновления системы Freebsd с помощью утилиты freebsd-update. Показано пошагово на конкретном примере обновления. Настройка Freebsd шлюза для обеспечения выхода в интернет. Используется ipfw и ядерный нат, dnsmasq в качестве dhcp и dns сервера. Мониторинг сетевой активности с помощью iftop. Подробная настройка на Freebsd прокси сервера squid + sams2 — панели управления для удобного администрирования. Настройка максимально быстрого web сервера на базе Freebsd и nginx + php-fpm. Существенный прирост производительности по сравнению с классическим apache. Настройка web сервера на Freebsd в связке с apache, nginx, php и mysql. Пошаговая установка и настройка каждого компонента. |
Настройка CentOS
Установка на этом не завершена. Для корректной работы консоли управления необходимо внести настройки в систему и Squid.
Настройка демона
Для работы службы sams2 копируем файл ее запуска:
cp redhat/init.d /etc/init.d/sams2
* подразумевается, что мы все еще находимся в каталоге sams2-master, распакованного исходника.
Открываем на редактирование данный файл:
vi /etc/init.d/sams2
Меняем:
[ -f __CONFDIR/sams2.conf ] || exit 0
…
DAEMON=__PREFIX/sams2daemon
… на:
[ -f /usr/local/etc/sams2.conf ] || exit 0
…
DAEMON=/usr/local/bin/sams2daemon
* в данном случае мы заменили __CONFDIR на /usr/local/etc и __PREFIX на /usr/local/bin.
Разрешаем автозапуск демона sams2 и запускаем его:
systemctl enable sams2
systemctl start sams2
Настройка Squid
При попытке внести какие либо изменения в консоли управления SAMS мы не увидим никаких изменений в конфигурационном файле SQUID. Проблема в том, что sams ориентируется по специальным комментариям, которых нет в конфиге последнего под CentOS.
Открываем конфигурационный файл squid.conf:
vi /etc/squid/squid.conf
… и в самый верх добавим:
# TAG: acl
# TAG: url_rewrite_access
# TAG: url_rewrite_program
# TAG: url_rewrite_children
# TAG: delay_pools
# TAG: delay_class
# TAG: delay_access
# TAG: delay_parameters
# TAG: http_access
# TAG: http_access2
# TAG: icp_access
* важно, чтобы между метками были разделяющие пустые строки. Теперь можно заходить на sams и настраивать SQUID
Теперь можно заходить на sams и настраивать SQUID.
Установка Squid и настройка в прозрачном режиме работы
Установка
Установите прокси-сервер следующей командой:
— для РЕД ОС версии 7.1 или 7.2:
# sudo yum install squid
— для РЕД ОС версии 7.3 и старше:
# sudo dnf install squid
Подготовка сертификатов
Чтобы работал HTTPS, необходимо сгенерировать сертификаты. Для этого создаем папку для хранения сертификатов, например, в /etc/squid/sslcert.
# sudo mkdir /etc/squid/sslcert
Переходим в эту папку:
# cd /etc/squid/sslcert
Генерируем ключ:
# sudo openssl genrsa -out /etc/squid/sslcert/squid.key
Создаем csr-запрос, используя ключ; нужно будет указать всю необходимую информацию для csr:
# sudo openssl req -new -key /etc/squid/sslcert/squid.key -out /etc/squid/sslcert/squid.csr
Подписываем сертификат самим собой:
# sudo openssl x509 -req -days 3650 -in /etc/squid/sslcert/squid.csr -signkey /etc/squid/sslcert/squid.key -out /etc/squid/sslcert/squid.pem
Генерируем корневой сертификат, который нужно будет добавить в браузер:
# sudo openssl x509 -in /etc/squid/sslcert/squid.pem -outform DER -out squid.der
Далее нужно будет дать права на папку с сертификатами для squid:
# chown -R :squid /etc/squid/sslcert
Описание настроек Squid.conf
Открываем файл настроек:
# sudo nano /etc/squid/squid.conf
Блок настроек «acl localnet src …» устанавливает правила доступа для вашей локальной сети, если в списке нет IP-адреса вашей сети, то его нужно добавить, например:
acl localnet src 10.9.1.0/24
или через файл:
acl localnet src "/etc/squid/acl_localnet"
* кавычки обязательны** после необходимо создать файл /etc/squid/acl_localnet и с каждой строчки перечислить разрешенные IP-адреса.
Блок настроек http_access устанавливает разрешения на доступ; чтобы разрешить весь трафик, добавляем следующую строчку:
http_access allow all
* важно, чтобы выше она была запрещающей – http_access deny all
Настройка Squid с HTTPS
Открываем файл конфигурации:
# sudo nano /etc/squid/squid.conf
Находим строку с http_port 3128 и под ней дописываем строки:
— создание прозрачного HTTP-порта 3129:
http_port 3129 intercept
— создание порта 3130 для https-трафика с генерацией сертификатов по ключу:
https_port 3130 intercept ssl-bump generate-host-certificates=on dynamic_cert_mem_cache_size=4MB cert=/etc/squid/sslcert/squid.pem key=/etc/squid/sslcert/squid.key
Отключаем проверку сертификатов:
sslproxy_cert_error allow all
Указываем, что необходимо принимать сертификаты, даже если они не прошли проверку:
sslproxy_flags DONT_VERIFY_PEER
Перенаправляем весь трафик на squid:
always_direct allow all
Устанавливаем безопасное соединение с сервером, затем с клиентом, используя имитированный сертификат сервера:
ssl_bump server-first all
Устанавливаем TCP-туннель, не расшифровывая прокси-трафик:
ssl_bump none all
Указываем расположение программы генерации сертификатов и устанавливаем кэширование:
sslcrtd_program /usr/lib64/squid/security_file_certgen -s /var/lib/ssl_db -M 4MB
Сохраняем и закрываем файл /etc/squid/squid.conf.
Дальше нужно пересоздать базу данных сертификатов:
# rm -rf /var/lib/ssl_db # sudo /usr/lib64/squid/security_file_certgen -c -s /var/lib/ssl_db -M 4MB
Устанавливаем владельца squid на папку базы данных сертификатов:
# sudo chown -R :squid /var/lib/ssl_db
Кэширование контента в Squid
На современных высокоскоростных безлимитных каналах связи кэширование потеряло свою актуальность. Для ускорения работы YouTube и других сетей доставки контента, кэширование также неэффективно, поскольку контент раздается с различных серверов.
По умолчанию дисковый кэш отключен, но в качестве кэша используется 256Мб оперативной памяти.
Полностью запретить кэширование можно добавив следующий параметр в squid.conf:
# Запретить кэширование cache deny all
Если необходим дисковый кэш, добавляем в squid.conf следующие параметры:
# Кэш: формат, размещение, размер в мегабайтах, число папок первой и второй вложенности # Указанный размер кэша не учитывает издержки файловой системы и должен быть примерно на 20% меньше доступного дискового пространства # Директиву cache_dir, можно указать несколько раз, выделив под кэш дополнительные разделы cache_dir ufs /var/squid/cache 3000 16 256 # Не кэшировать файлы больше заданного размера # По умолчанию 4Мб maximum_object_size 320 MB # Продолжить загрузку при отключении клиента, если осталось загрузить менее указанного объема данных # Позволяет сохранить объект в кэше при отмене загрузки клиентом # Значение 0 для quick_abort_min и quick_abort_max отменяют докачку # Значение -1 включает полную закачку объекта, не зависимо от оставшегося объема, повышает нагрузку на канал # По умолчанию 16 Кб quick_abort_min 5 MB
Если путь к кешу был изменен, создаем папку кэша, задаем права доступа:
mkdir -p /usr/local/squid/cache chown root:squid /usr/local/squid/cache chmod 770 /usr/local/squid/cache
Создаем структуру кэша:
/usr/local/sbin/squid -z
Squid аутентификация
Если ограничение доступа на основе IP не работает для вашего варианта использования, вы можете настроить squid на использование серверной части для аутентификации пользователей. Squid поддерживает базовую аутентификацию Samba , LDAP и HTTP.
В этом руководстве мы будем использовать базовую аутентификацию. Это простой метод аутентификации, встроенный в протокол HTTP.
Чтобы сгенерировать зашифрованный пароль, используйте инструмент . Следующая команда добавляет пару в файл :
Например, чтобы создать пользователя «josh» с паролем « », вы должны запустить:
Следующим шагом является включение базовой аутентификации HTTP и включение файла, содержащего учетные данные пользователя, в файл конфигурации squid.
Откройте основную конфигурацию и добавьте следующее:
/etc/squid/squid.conf
Первые три выделенные строки создают новый список контроля доступа с именем « , а последняя выделенная строка разрешает доступ аутентифицированным пользователям.
Перезапустите сервис Squid:
Заключение
Поле завершения установки и настройки sams2, а затем и реальной эксплуатации у меня ложилось двоякое впечатление. С одной стороны вроде работает, но как-то криво. В программе баги, в логи она во время работы постоянно сыпет сообщениями:
Dec 27 01:20:08 freebsd samsdaemon: ***ERROR: squidlogparser.cpp:445 Unknown cache result Dec 27 01:20:08 freebsd samsdaemon: +++WARNING: Unknown cache result TCP_TUNNEL
Хотя на работу это вроде как не влияет. В инет пускает, статистику считает. Я еще не настраивал редиректор и списки запрета доступа, но по отзывам, там тоже есть проблемы и работает все нестабильно. Начиная с версии 3.4 поменялся формат ответа редиректора и он стал несовместим с самсовским. Нужно править исходники и собирать с исправлениями. На CentOS я обошелся просто более старой версией squid, чтобы не разбираться с этой проблемой. Думаю, можно вообще без запретов обойтись, это сейчас не актуально из-за большого развития мобильных гаджетов и хорошего доступа в интернет с них
Но если вам это важно, имейте в виду
Несмотря на все проблемы, я не нашел замены, которая была бы такой же удобной и наглядной, как sams. Придется пока с ним дружить и находить общий язык. Надеюсь, что кто-нибудь возьмется за его развитие и поддержку.
Заключение
Поле завершения установки и настройки sams2, а затем и реальной эксплуатации у меня ложилось двоякое впечатление. С одной стороны вроде работает, но как-то криво. В программе баги, в логи она во время работы постоянно сыпет сообщениями:
Хотя на работу это вроде как не влияет. В инет пускает, статистику считает. Я еще не настраивал редиректор и списки запрета доступа, но по отзывам, там тоже есть проблемы и работает все нестабильно. Начиная с версии 3.4 поменялся формат ответа редиректора и он стал несовместим с самсовским. Нужно править исходники и собирать с исправлениями. На CentOS я обошелся просто более старой версией squid, чтобы не разбираться с этой проблемой. Думаю, можно вообще без запретов обойтись, это сейчас не актуально из-за большого развития мобильных гаджетов и хорошего доступа в интернет с них
Но если вам это важно, имейте в виду
Несмотря на все проблемы, я не нашел замены, которая была бы такой же удобной и наглядной, как sams. Придется пока с ним дружить и находить общий язык. Надеюсь, что кто-нибудь возьмется за его развитие и поддержку.
источник