Тема ограничения скорости через прокси-сервер squid уже поднималась на страницах нашего блога, однако тогда мы рассмотрели вариант с ограничением для узлов сети и ее сегментов, не касаясь вопросов аутентификации пользователей. В тоже время перед администраторами крупных сетей встает вопрос об ограничении скорости именно пользователей и групп, в том числе на основе членства в группах Active Directory. Сегодня мы расскажем, как это можно сделать.
Онлайн-курс по устройству компьютерных сетей
На углубленном курсе "Архитектура современных компьютерных сетей" вы с нуля научитесь работать с Wireshark и «под микроскопом» изучите работу сетевых протоколов. На протяжении курса надо будет выполнить более пятидесяти лабораторных работ в Wireshark.
Мы не будем подробно возвращаться к механизму ограничения скорости в Squid, полагая что читатели данной статьи владеют необходимым минимумом знаний, в противном случае рекомендуем прежде ознакомиться с нашим материалом:
Как известно, первые три класса пулов работают с сетями, подсетями и конкретными узлами. Существуют распространенные заблуждения, что пулы работают с элементами ACL, а их содержимое не столь важно. Признаемся, мы сами одно время находились под их влиянием, но самый лучший способ развеять заблуждения - проверить все на собственном опыте.
Эмпирическим путем было выяснено, что если элемент ACL для пулов 1-3 классов не содержит описания сетей, подсетей или хостов, то его содержимое при работе delay pools будет проигнорировано. Таким образом для работы с пользователями следует применять только пулы 4 класса, которые кроме настроек для сетей и хостов содержат отдельную настройку для аутентифицированного пользователя.
И если описание пула 3-го класса выглядит так:
delay_parameters n общие подсеть узел
то в 4-ом классе к ним добавляются настройки пользователя
delay_parameters n общие подсеть узел пользователь
Поэтому в применяемом для пула 4-го класса элементе ACL обязательно должны присутствовать пользователи, в противном случае такой пул работать не будет.
Как применять данный класс пулов? Начнем с самой простой задачи: ограничим скорость всем пользователям, которые прошли проверку подлинности на прокси.
Прежде всего зададим элемент ACL для них:
acl auth proxy_auth REQUIRED
Затем опишем пул:
delay_pools 1
delay_class 1 4
delay_access 1 allow auth
delay_parameters 1 -1/-1 -1/-1 -1/-1 1250000/1250000
Первой строкой мы указали количество пулов, затем перечислили их указав номер и класс, ниже разместили список доступа, разрешив работу с пулом только элементам ACL auth - т.е. всем аутентифицированным пользователям. И наконец задали ограничения скорости. Первые три опции мы выставили без ограничений, а в последней мы указали максимальную скорость для пользователя в 1,25 МБ/с = 10 Мбит/с.
Проверяем:
При этом данный пул можно использовать и для ограничения скорости для узлов и подсетей. Для этого укажите там соответствующие настройки и добавьте еще один список доступа с ACL содержащим узлы и сети, в этом случае работа пула ничем не будет отличаться от пула 3-го класса, а настройки для пользователей будут проигнорированы.
Например:
acl public_pc src 192.168.31.111
acl auth proxy_auth REQUIRED
http_access allow public_pc
http_access allow auth
delay_access 1 allow public_pc
delay_access 1 allow auth
delay_parameters 1 -1/-1 -1/-1 1250000/1250000 1250000/1250000
Мы создали два элемента ACL: для некого публичного ПК, с которого доступ в сеть будет осуществляться без аутентификации, и для прошедших проверку подлинности пользователей. Затем разместили список доступа для публичного ПК выше списка доступа пользователей, в противном случае прокси прежде потребует аутентификацию.
И наконец задали два списка доступа для пула, в данном случае их порядок особо неважен, так как элементы ACL содержат разные типы данных и не перекрывают друг друга. В настройках пула мы задали скорость в 10 Мбит/с как для узла, так и для пользователя. Комбинируя настройки следует учитывать их вложенность, ограничения для пользователя также учитывают ограничения для узла, подсети и для пула в целом. Например, ограничив для узла скорость в 1 Мбит/с и оставив 10 Мбит/с для пользователя мы все равно не получим скорости выше 1 Мбит/с.
Кстати, такую комбинацию удобно использовать для терминальных серверов, когда требуется ограничить не только скорость каждого пользователя, но и скорость всего сервера в целом. Не забудьте только задать ACL с адресом сервера.
До сих пор мы оперировали общим понятием пользователи, но в большинстве случаев требуются ограничения для конкретных пользователей или групп. Если Squid самостоятельно занимается аутентификацией пользователей, то можно просто перечислить в описании ACL необходимые имена. Для примера разделим интернет в небольшой группе для босса и подчиненных.
acl boss proxy_auth boss
acl sotrudniki proxy_auth ivanov petrov sidirov
Теперь у нас два элемента ACL, в первый попадает пользователь с именем boss, а во второй сотрудники Иванов, Петров и Сидоров.
Создадим два пула четвертого класса и укажем списки доступа для них:
delay_pools 2
delay_class 1 4
delay_class 2 4
delay_access 1 allow boss
delay_access 2 allow sotrudniki
Теперь зададим параметры пулов. Для босса ограничений нет и на первый взгляд было бы логично указать:
delay_parameters 1 -1/-1 -1/-1 -1/-1 -1/-1
Но опытным путем было установлено, что при такой настройке доступ в интернет будет затруднен, на практике это выражается в бесконечной загрузке некоторых сайтов.
Поэтому следует явно указывать значения скорости, например, полную скорость канала, либо заведомо большее значение. В нашем случае укажем 100 Мбит/с для босса и 10 Мбит/с для сотрудников.
delay_parameters 1 -1/-1 -1/-1 -1/-1 12500000/12500000
delay_parameters 2 -1/-1 -1/-1 -1/-1 1250000/1250000
Если вы используете аутентификацию через внешние службы, например, через каталог Active Directory, то гораздо удобнее оперировать не пользователями, а группами. Для получения сведений о членстве пользователя в той или иной группе применяются внешние утилиты - хелперы, работа с которыми производится специальной директивой external_acl_type. Более подробно об этом можно прочитать в статье:
Мы не будем подробно останавливаться на этом вопросе и возьмем в качестве примера настройки из указанной статьи. Мы будем проверять членство пользователей в двух доменных группах и на основании этого помещать их в один из элементов ACL:
acl squid-admin external squid-admin
acl squid-user external squid-user
Дальнейшая настройка ничем не отличается от вышеприведенного примера, достаточно только прописать в списки доступа ACL с авторизованными на основе групп доменными пользователями.
delay_access 1 allow squid-admin
delay_access 2 allow squid-user
А как быть с теми, кто не попал ни в какой список? Если оставить все как есть, то никакие ограничения к ним не применятся. Поэтому создадим третий пул, убедившись перед этим, что у нас есть элемент ACL для всех пользователей.
acl auth proxy_auth REQUIRED
Затем укажем для них список доступа и поставим его самым последним. Списки обрабатываются в порядке очередности и до первого совпадения, поэтому в него попадут только те, кто не попал ни в один другой список. Т.е. правильно будет так:
delay_access 1 allow squid-admin
delay_access 2 allow squid-user
delay_access 3 allow auth
При этом взаимное расположение списков для админов и пользователей особой роли не играет, так как их содержимое не пересекается, однако если вдруг какой-либо пользователь окажется сразу в нескольких группах, то для него сработает ограничение того пула, правило для которого находится выше в списке, хотя таких ситуаций следует по возможности избегать.
Для лучшего понимания работы и отладки правил можно включить расширенные логи, для этого добавьте в соответствующую секцию конфигурационного файла директиву:
debug_options ALL,1 77,9
После чего в файл /var/log/squid3/cache.log будут записываться события связанные с пулами задержки. Взглянем на пример такого лога:
Из отладочной информации прекрасно видно какой пользователь попадает в какой пул, поэтому мы советуем включать отладку всегда, когда вы испытываете затруднения с распределением пользователей по пулам или с непонятной работой последних. Однако не следует включать эту опцию на рабочих серверах во избежание стремительного роста файла лога, ну и не забывайте выключать ее после настройки.
Как видим, ничего сложного в ограничении скорости для пользователей нет, надо всего лишь понимать принцип работы пулов задержки и не путать объекты, к которым применяются ограничения.
Онлайн-курс по устройству компьютерных сетей
На углубленном курсе "Архитектура современных компьютерных сетей" вы с нуля научитесь работать с Wireshark и «под микроскопом» изучите работу сетевых протоколов. На протяжении курса надо будет выполнить более пятидесяти лабораторных работ в Wireshark.
Последние комментарии