Як відомо, перші три класи пулів працюють з мережами, підмережами і конкретними вузлами. Існують поширені помилки, що пули працюють з елементами ACL, а їх вміст не настільки важливо. Зізнаємося, ми самі у свій час перебували під їх впливом, але найкращий спосіб розвіяти помилки - перевірити всі на власному досвіді.
Емпіричним шляхом було з'ясовано, що якщо елемент ACL для пулів 1-3 класів не містить опису мереж, підмереж або хостів, то його вміст при роботі delay pools буде проігноровано. Таким чином для роботи з користувачами слід застосовувати тільки пули 4 класу, які крім налаштувань для мереж і хостів містять певний параметр для аутентифицированного користувача.
І якщо опис пулу 3-го класу виглядає так:
то в 4-му класі до них додаються налаштування користувача
Тому право застосовується для пулу 4-го класу елементі ACL обов'язково повинні бути присутніми користувачі, в іншому випадку такий пул працювати не буде.
Як застосовувати даний клас пулів? Почнемо з найпростішої завдання: обмежимо швидкість всім користувачам, які пройшли перевірку автентичності на проксі.
Перш за все поставимо елемент ACL для них:
Потім опишемо пул:
Першим рядком ми вказали кількість пулів, потім перерахували їх вказавши номер і клас, нижче розмістили список доступу, дозволивши роботу з пулом тільки елементам ACL auth - тобто всім аутентифицироваться користувачам. І нарешті поставили обмеження швидкості. Перші три опції ми виставили без обмежень, а в останній ми вказали максимальну швидкість для користувача в 1,25 МБ / с = 10 Мбіт / с.
При цьому даний пул можна використовувати і для обмеження швидкості для вузлів і підмереж. Для цього вкажіть там відповідні налаштування і додайте ще один список доступу з ACL містить вузли та мережі, в цьому випадку робота пулу нічим не буде відрізнятися від пулу 3-го класу, а настройки для користувачів будуть проігноровані.
Ми створили два елементи ACL: для когось публічного ПК, з якого доступ в мережу буде здійснюватися без аутентифікації, і для пройшли перевірку автентичності користувачів. Потім розмістили список доступу для публічного ПК вище списку доступу користувачів, в іншому випадку проксі перш потребують аутентифікацію.
І нарешті поставили два списки доступу для пулу, в даному випадку їх порядок особливо важлива, так як елементи ACL містять різні типи даних і не перекривають один одного. В налаштуваннях пулу ми задали швидкість в 10 Мбіт / с як для вузла, так і для користувача. Комбінуючи настройки слід враховувати їх вкладеність, обмеження для користувача також враховують обмеження для вузла, підмережі і для пулу в цілому. Наприклад, обмеживши для вузла швидкість в 1 Мбіт / с і залишивши 10 Мбіт / с для користувача ми все одно не отримаємо швидкості вище 1 Мбіт / с.
До сих пір ми оперували загальним поняттям користувачі, але в більшості випадків потрібні обмеження для конкретних користувачів або груп. Якщо Squid самостійно займається аутентифікацією користувачів, то можна просто перерахувати в описі ACL необхідні імена. Для прикладу розділимо інтернет в невеликій групі для боса і підлеглих.
Тепер у нас два елементи ACL, в перший потрапляє користувач з ім'ям boss, а в другій співробітники Іванов, Петров і Сидоров.
Створимо два пула четвертого класу і вкажемо списки доступу для них:
Тепер задамо параметри пулів. Для боса обмежень немає і на перший погляд було б логічно вказати:
Але досвідченим шляхом було встановлено, що при такій настройці доступ в інтернет буде утруднений, на практиці це виражається в нескінченній завантаженні деяких сайтів.
Тому слід явно вказувати значення швидкості, наприклад, повну швидкість каналу, або свідомо більшого значення. У нашому випадку зазначимо 100 Мбіт / с для боса і 10 Мбіт / с для співробітників.
Якщо ви використовуєте аутентифікацію через зовнішні служби, наприклад, через каталог Active Directory, то набагато зручніше оперувати користувачами, а групами. Для отримання відомостей про членство користувача в тій чи іншій групі застосовуються зовнішні утиліти - хелпери, робота з якими проводиться спеціальною директивою external_acl_type. Більш докладно про це можна прочитати в статті:
Ми не будемо детально зупинятися на цьому питанні і візьмемо в якості прикладу настройки з зазначеної статті. Ми будемо перевіряти членство користувачів в двох доменних групах і на підставі цього поміщати їх в один з елементів ACL:
А як бути з тими, хто не потрапив ні в який список? Якщо залишити все як є, то ніякі обмеження до них не застосовуються. Тому створимо третій пул, переконавшись перед цим, що у нас є елемент ACL для всіх користувачів.
Потім вкажемо для них список доступу і поставимо його найостаннішим. Списки обробляються в порядку черговості і до першого збігу, тому в нього потраплять тільки ті, хто не потрапив ні в один інший список. Тобто правильно буде так:
При цьому взаємне розташування списків для адмінів і користувачів особливої ролі не грає, так як їх вміст не перетинається, проте якщо раптом якийсь користувач виявиться відразу в декількох групах, то для нього спрацює обмеження того пулу, правило для якого знаходиться вище в списку, хоча таких ситуацій слід по можливості уникати.
Для кращого розуміння роботи і налагодження правил можна включити розширені логи, для цього додайте в відповідну секцію конфігураційного файлу директиву:
Після чого в файл /var/log/squid3/cache.log будуть записуватися події пов'язані з пулами затримки. Погляньмо на приклад такого логу:
Як бачимо, нічого складного в обмеженні швидкості для користувачів немає, треба всього лише розуміти принцип роботи пулів затримки і не плутати об'єкти, до яких застосовуються обмеження.