Настройка прокси сервера на centos 7 (squid+ad+sams2)

Примеры delay pools

Работа по настройке delay pools заключается в следовании по следующим шагам:

создаем acl и соответствующее http_access разрешение для доступа пользователя(ей) к squid
задаем количество пулов, к которым будем присоединять соответствующие acl параметром delay_pools
задаем каждому пулу свой класс параметром delay_class
задаем каждому пулу задаем свои параметры через delay_parameters
задаем каждому пулу, кто или что в него будет попадать через delay_access

Давайте начнем с простого примера. Предположим, у нас есть некоторое соединение с интернет в 1 Мбит/с, при этом, нам нужно выделить на squid только 512 Кбит/с, чтобы остальная часть канала была отдана под другие сервисы. Для данной задачи нам подойдет пул класса 1:

# зададим acl и разрешим доступ:
acl all src 0/0
http_access allow all
# создадим 1 пул
delay_pools 1
# зададим первому пулу первый класс
delay_class 1 1
# зададим первому пулу скорость 512 Кбит/с (= 512 Кбит/с / 8 = 64 КБайт/с = 64000 Байт/с)
# и размер пула в 50 Мбайт
delay_parameters 1 64000/50000000
# включим всех в первый пул
delay_access 1 allow all

У данной схемы есть следующий недостаток: некоторые пользователи могут получить гораздо больше скорости, чем остальные. Чтобы избавиться от данной проблемы, можно использовать пул 2 класса. При этом, если у вас сеть больше размера /24, то есть в вашей сети более 255 хостов, то можно использовать пул 3 класса вместо 2 класса. Класс 3 позволяет ограничить скорость для 65536 хостов (255 подсетей * 255 хостов в этих подсетях). Давайте к прошлому примеру ограничим хосты скоростью в 64Кбит/с. При этом, избранных пользователей направим на пул с более высокой скоростью в 256 Кбит/с:

# зададим 2 acl и разрешим доступ:
acl all src 0/0
acl vip src 10.0.0.1 10.0.0.2
http_access allow all
# создадим 2 пула
delay_pools 2
# зададим первому пулу первый класс, а второму - третий
delay_class 1 1
delay_class 2 3
# зададим первому пулу скорость 256 Кбит/с (= 256 Кбит/с / 8 = 32 КБайт/с = 32000 Байт/с) и размер пула в 20 Мбайт
delay_parameters 1 32000/20000000
# зададим второму пулу скорость 512 Кбит/с (= 512 Кбит/с / 8 = 64 КБайт/с = 64000 Байт/с) и размер пула в 50 Мбайт для всей сети
# для подсетей отменим ограничения за ненадобностью (-1/-1)
# зададим для хостов скорость 64 Кбит/с (= 64 Кбит/с / 8 = 8 КБайт/с = 8000 Байт/с) и размер пула в 10 Мбайт для всей сети
delay_parameters 2 64000/50000000 -1/-1 8000/10000000
# включим вип-пользователей в первый пул и "традиционно" запретим использование данного пула всем остальным
delay_access 1 allow vip
delay_access 1 deny all
# включим всех во второй пул
delay_access 2 allow all

Хочу обратить внимание на слово «традиционно». Я так написал, потому что синтаксис delay_access аналогичен http_access и по умолчанию используется правило, противоположное последнему

Поэтому традиционно доступ к пулам, к которым применяются «избранные» пользователи завершают запрещающим правилом для всех — delay_access deny all.

Так же, хочу отметить, что в настоящее время смысл устанавливать ~~объем ведра~~ максимальный размер пула, то есть значения total_max, net_ma, ind_max, usr_max, имеет очень спорны характер. Т.к. современные сайты содержат в большинстве своем некэшируемый контент (js, php и др.), поэтому запрашивается напрямую с удаленного сервера. Соответственно, локальному клиенту он отдается со скоростью, заданной в delay_parameters. Хотя в сети ~~много~~ почти все мануалы уверенно утверждают, что если мы зададим объем ведра, то данный объем клиент получит на максимальной скорости интернета. Это, имхо, неверно!

Открытие портов

По умолчанию в конфигурации Squid разрешено использование только определенных портов.

acl SSL_ports port 443
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 Safe_ports port XXX

Где XXX — номер порта, использование которого нужно разрешить. Снова желательно пояснять ACL комментарием.

Не забываем перезапустить Squid для применения настроек

squid.conf

> ee /usr/local/etc/squid/squid.conf
# выводить сообщения пользователям на украинском языке, по умолчанию английский
error_default_language uk-ua
# Squid слушает порт только на localhost. intercept включаем прозрачный прокси
http_port 127.0.0.1:3128 intercept
visible_hostname = local
# например есть ОЗУ 192 Мб -  можно выставить 64 Mб. Выделение ОЗУ по кеш, а не под процесс SQUID.
cache_mem 64 MB
# размер папки с кешем 800 Мб
cache_dir ufs /usr/local/squid/cache 800 16 256
# пределы для включения механизма очистки кеша от устаревших данных, в процентах
# кеш при достижении 95% заполнения начинает очищаться
cache_swap_low 90
cache_swap_high 95
# политика очистки кеша по умолчанию
memory_replacement_policy lru
#Этот тэг задает размер объекта который может хранится в памяти. Объекты
#больше этого размера, сохранятся в памяти не будут. Объекты из памяти
#достаются быстрее, поэтому там должны содержатся только объекты, которые
#часто запрашиваются клиентами. Увеличение значения этого тэга приводит к снижению производительности сервера.
maximum_object_size_in_memory 512 KB
# минимальный размер файл для сохранения в кеше
minimum_object_size 0 KB 
# максимальный размер файл для сохранения в кеше
maximum_object_size 4096 KB
# Этот тэг позволяет задать пароль ftp пользователю Anonymous(!!!) от имени 
# которого Squid будет осуществлять просмотр анонимных ресурсов по FTP протоколу.
ftp_user [email protected]
# разрешить/запретить пассивный режим FTP
ftp_passive on

#Этот тэг определяет количество ротаций лог-файла. По умолчанию - 10. Это означает, что когда вы введете команду 'squid -k rotate',
то текущий файл журнала получит расширение от 0 до 9 и будет отложен. Вместо него создастся новый файл для ведения журнала и теперь
все записи будут вестись уже в новый файл. Если установить значение тэга logfile_rotate 0, то это отключит ротацию файлов.
logfile_rotate 4
access_log /var/log/squid/access.log squid
# отладочная информация. содержит основную информацию об использовании кэша.
cache_log /var/log/squid/cache.log
# Default: none
#cache_store_log /var/log/squid/store.log

#Этот тэг задает список слов, которые при нахождении их(этих слов) в URL, 
#сообщают Squid то, что объект расположенный по этому URL надо брать 
#напрямую, а не из кэша.
hierarchy_stoplist cgi-bin ?

Проверим конфигурационный файл Squid на ошибки.

> squid -f /usr/local/etc/squid/squid.conf -k parse
2010/03/16 16:40:32| Processing Configuration File: /usr/local/etc/squid/squid.conf (depth 0)

Перед первым запуском нужно создать кеш Squid.

> squid -z
2010/03/16 16:42:05| Creating Swap Directories
2010/03/16 16:42:05| /usr/local/squid/cache exists
2010/03/16 16:42:05| Making directories in /usr/local/squid/cache/00
...

Для запуска Squid нужно добавить строку squid_enable=yes в файл rc.conf

> /usr/local/etc/rc.d/squid start

Настройка CentOS

Kerberos

Устанавливаем следующие пакеты:

yum install cyrus-sasl-gssapi krb5-workstation krb5-devel

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

vi /etc/krb5.conf

Редактируем следующие строки:

…
default_realm = DOMAIN.LOCAL
..

DOMAIN.LOCAL = {
kdc = 192.168.0.15
kdc = 192.168.0.16
kdc = 192.168.0.17
admin_server = domain.local
}

* DOMAIN.LOCAL — наш домен; kdc — перечень контроллеров домена; admin_server — первичный контроллер (в данном примере будет использоваться случайный).

Проверяем настройки krb, запросив тикет:

kinit domainuser

klist

При правильных настройках мы увидим на подобие:

Ticket cache: KEYRING:persistent:0:0
Default principal: [email protected]

Valid starting Expires Service principal
15.05.2018 10:08:33 15.05.2018 20:08:33 krbtgt/[email protected]
renew until 22.05.2018 10:08:30

Проверяем keytab-файл, который мы перенесли на сервер с контроллера домена:

kinit -V -k -t /etc/squid/proxy.keytab HTTP/[email protected]

* где /etc/squid/proxy.keytab — путь до keytab-файла; HTTP/[email protected] — принципал, который был задан при создании файла.

И снова:

klist

Картина, примерно, следующая:

Ticket cache: KEYRING:persistent:0:krb_ccache_9MN6pt8
Default principal: HTTP/[email protected]

Valid starting Expires Service principal
16.05.2018 09:35:20 16.05.2018 19:35:20 krbtgt/[email protected]
renew until 23.05.2018 09:35:20

Зададим файлу следующие права:

chown squid:squid /etc/squid/proxy.keytab

chmod u+rwx,g+rx /etc/squid/proxy.keytab

NTLM

Устанавливаем следующие пакеты:

yum install samba-winbind samba-winbind-clients pam_krb5 krb5-workstation

Конфигурируем

authconfig —enablekrb5 —krb5kdc=domain.local —krb5adminserver=domain.local —krb5realm=domain.LOCAL —enablewinbind —enablewinbindauth —smbsecurity=ads —smbrealm=domain.LOCAL —smbservers=domain.local —smbworkgroup=domain —winbindtemplatehomedir=/home/%U —winbindtemplateshell=/bin/bash —enablemkhomedir —enablewinbindusedefaultdomain —update

* где domain.local — это наш домен, domain — домен в сокращенной нотации. Регистр важен.
* если после ввода команды мы увидим ошибку Job for winbind.service failed because the control process exited with error code. See «systemctl status winbind.service» and «journalctl -xe» for details — игнорируем ее. Она возникает из-за того, что наш сервер еще не в домене.

Добавляем сервер в домен:

net ads join -U administrator

* где administrator — учетная запись в AD с правами на ввод компьютеров в домен.

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

systemctl enable winbind

systemctl start winbind

Проверяем, что наш сервер умеет обращаться к службе каталогов:

wbinfo -t

wbinfo -g

* первая команда проверяет возможность отправлять запросы на контроллер домена; вторая — выводит список групп, находящихся в каталоге.

Перенаправление пакетов на другой порт

Перенаправление портов можно использовать для самых разных задач. Например, перенаправление пользователей из разных сетей на разные экземпляры веб-сервера, перенаправление порта на другой, если изменился порт какого-то сервиса, настройка прозрачного проксирования и так далее. Общая идея в том, что пакеты с определенного порта перенаправляются на другой порт на том же сетевом интерфейсе той же самой машины, либо на loopback’е.
Для перенаправления порта, например, 80, с внешнего интерфейса на порт 80 на loopback-интерфейсе мы можем использовать правило

iptables -t nat -A PREROUTING -d 192.168.0.1/32 -p tcp -m tcp --dport 80 -j DNAT --to-destination 127.0.0.1:80

Это правило позволит перенаправить пакеты на loopback, изменив назначение пакета путем трансляции адреса (Destination NAT), и после этого можно будет их отфильтровать в цепочке, которая будет задана для loopback-интерфейса. Естественно, нужно будет сделать и обратную трансляцию:

iptables -t nat -A POSTROUTING -s 127.0.0.1/32 -p tcp -m tcp --dport 80 -j SNAT --to-source 192.168.0.1

Таким образом, происходит обратный процесс, при этом изменяется Source NAT, то есть, транслируется адрес источника соединения.

Настройка SQUID с ntlm авторизацией через домен

Дальше будет попроще. Если на предыдущем этапе вы все сделали правильно, то squid заработает без проблем. Устанавливаем его:

# yum -y install squid

Открываем файл конфигурации /etc/squid/squid.conf и добавляем в самое начала следующие параметры:

auth_param ntlm program /usr/bin/ntlm_auth --diagnostics --helper-protocol=squid-2.5-ntlmssp --domain=XS
auth_param ntlm children 10
auth_param ntlm keep_alive off
acl auth proxy_auth REQUIRED

Не забудьте указать свой домен

Обращаю внимание на первую строку. В большинстве инструкций в интернете она выглядит немного не так, в ней нет дополнительных параметров

Без них у меня ntlm авторизация не хотела работать, я очень долго ее мучал.

Дальше находим в конфиге строку:

http_access allow localnet

Комментируем ее, она позволяет получить доступ всем компьютерам из локальной сети. После этой строки добавляем новую:

http_access allow auth

Разрешаем доступ только тем, кто прошел авторизацию. Запускаем squid и добавляем в автозагрузку:

# systemctl start squid
# systemctl enable squid

Все, можно идти проверять. Открываем браузер у какого-нибудь компьютера и указываем в качестве прокси ip адрес сервера, порт 3128. Пробуйте выйти в интернет.

Как понять, что все работает правильно:

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

# cat /var/log/squid/access.log | grep control

1449261311.346 9 10.1.4.189 TCP_MISS/304 438 GET http://yastatic.net/islands/_/S1-qWWyv85yFAtoHVvuxJXpOKA4.svg control HIER_DIRECT/178.154.131.217 -
 1449261311.351 11 10.1.4.189 TCP_MISS/200 622 GET http://yastatic.net/www/_/_/y/ljN5poHcx67T3HSZuHbvf2NNk.png control HIER_DIRECT/178.154.131.217 image/png
 1449261311.404 9 10.1.4.189 TCP_MISS/304 440 GET http://yastatic.net/morda-logo/i/disaster/metro11072015.png control HIER_DIRECT/178.154.131.217 -
 1449261311.488 97 10.1.4.189 TCP_MISS/302 355 GET http://kiks.yandex.ru/fu control HIER_DIRECT/213.180.204.143 -
 1449261311.507 9 10.1.4.189 TCP_MISS/304 341 GET http://kiks.yandex.ru/system/fc07.swf control HIER_DIRECT/213.180.204.143 -

В данном случае control — доменная учетная запись.

У нас получилась полностью дефолтная конфигурация, в которую мы просто добавили ntlm авторизацию и разрешили доступ в интернет только для тех, кто эту авторизацию прошел. Если компьютер находится не в домене, то при работе через прокси выскочит окно с авторизацией, в которую нужно будет ввести данные от учетной записи домена, чтобы получить доступ в интернет.

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

Ограничения delay pools и нюансы работы

У технологии delay pools есть некоторые ограничения в работе, которые нужно учитывать при конфигурировании. Предположим, у нас есть вот такой конфиг:

acl workday time 10:00-13:00
acl our_networks src 192.168.0.0/24
http_access allow our_networks
<...>
delay_pools 2
delay_class 1 1
delay_parameters 1 15000/15000
delay_access 1 allow  our_networks
delay_access 1 deny all

delay_class 2 1
delay_parameters 2 12000/12000
delay_access 2 allow our_networks workday
delay_access 2 deny all

Данные правила задают скорость 15000 байт/с круглосуточно и 12000 байт/с с 10 до 13 часов. При данном конфиге, если пользователь в 09.59 начал закачку какого-то большого объекта, то он его докачает со скоростью 15000 байт/с и в 10.00 скорость закачки не понизится. То есть если соединение уже было создано, то delay pool его не закрывает и не режет. delay pools отрабатывает при создании сессии.

Многие в сети называют технологию delay pools, как честный дележ канала, но на самом деле честностью тут и не пахнет и понятие честности тут весьма условно. Это выражается в том, например, что если у нас есть некий пул первого класса, в котором работают большое количество клиентов, то некоторому жадному клиенту ничто не мешает занять весь канал, не давая работать другим

Аналогично это правило и для всех остальных классов. Эту особенность в большей степени важно учитывать при задании диаметров «шлангов» для общих ограничений, например, всей сети (где уровень честности понижается), и в меньшей степени для индивидуальных пулов (где управлять «честностью» можно более гибко)

Когда запрос проходит через каскад пулов, то конечная скорость рассчитывается с учетом ограничений всех пулов. Например, рассмотрим пул 3 класса в котором заданы ограничения для всех, для подсетей и для отдельных хостов. Даже если ограничения хоста 20 Кбайт/с, а у подсети 30 Кбайт/с и при этом, у пуля для всех установлен лимит шланга в 2 Кбайта/с, то конечный клиент получит именно 2 Кбайта/с. Даже с учетом, что у некоторых пулов есть довольно большой ресурс трафика, клиент будет ограничен самым маленьким лимитом.

Так же, стоит учитывать, что устанавливаемые ограничения скорости действуют только на фактически переданные клиенту и не включают технические данные (например TCP, ICP, DNS и др.)

Резюме