Установка и настройка прокси сервера на freebsd 10 (squid+sams2)

Введение

Я успешно разобрался с настройкой 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:
  • Установка
  • Настройка
  • Обновление
  • Шлюз
  • Прокси сервер
  • Веб сервер NGINX
  • Веб сервер Apache

Описание установки 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. Придется пока с ним дружить и находить общий язык. Надеюсь, что кто-нибудь возьмется за его развитие и поддержку.

источник

Рейтинг
( Пока оценок нет )
Понравилась статья? Поделиться с друзьями:
Техноарена
Добавить комментарий

;-) :| :x :twisted: :smile: :shock: :sad: :roll: :razz: :oops: :o :mrgreen: :lol: :idea: :grin: :evil: :cry: :cool: :arrow: :???: :?: :!: