Linuxnews - Forum

Настраиваем squid - multik (08-May-2001, 14:27)

Общая настройка сквида чаще всего не вызывает сложностей. Сложности обычно вызывают три вещи - настройка ACL (access control list - список прав доступа) и правил для них, настройка дополнительных программ вроде баннерорезалок и настройка ограничений использования канала. Вот эти три вещи я и постараюсь описать в этой статье.

Итак, ACL. Обратимся к соответсвующему месту файла squid.conf и прокомментируем его.

ACL прописываются в виде строки acl имя_acl тип_acl параметры или acl имя_acl тип_acl "файл" - при этом в файле сохраняется по одному значению на строку.

Итак, пойдем по типам списков.

acl aclname src ip-address/netmask - в этом acl описывается ip-адрес или сеть, принадлежащая клиентам squid. Например:

acl vasya src 192.168.1.1/255.255.255.255 описывает единственную машину с адресом 192.168.1.1 и назначает ей ACL с именем vasya

acl office src 192.168.1.1/255.255.255.0 описывает диапазон машин с адресами 192.168.1.1-.254 и назначает этому ACL имя office. Если диапазон необходимо сузить, то необходимо либо изменить маску подсети, либо воспользоваться явным указанием - acl vip_user src 192.168.1.1-192.168.1.5/255.255.255.0. Здесь squid выбирает тот диапазон адресов, который окажется меньше - либо по маске, либо по явному указанию.

acl aclname dst ip-address/netmask - этот тип ACL описывает уже сервер, страницы с которого будут запрашивать клиенты. Особо отмечу - что в этом типа ACL задается не символьный адрес сервера, а ip.

acl aclname srcdomain .domain.ru - описывает клиентов, но уже не по ip-адресам, а по реверсным DNS. То есть в данном примере нет разницы, какие ip-адреса принадлежат клиентам - главное, что бы они определялись dns. Соответсвенно, пож это правило попадут все клиенты, стоящие в домене domain.ru.

acl aclname dstdomain .domain.ru - описывает сервер. Сравнивается с запросом из URL. Под этот ACL попадут все сервера 3его уровня домена domain.ru.

acl aclname srcdom_regex [-i] xxx
acl aclname dstdom_regex [-i] xxx
Описания аналогичны предыдущим, но теперь для выяснения, подходит ли правило под запрос, используются regex-правила. Если символьный адрес не смог определиться из ip-адреса, к запросу будет применена строка none.

acl aclname time [day-abbrevs] [h1:m1-h2:m2] - ACL, описывающий время.
Коды дней недели определяются так: S - Sunday - Воскресенье, M - Monday - Понедельник, T - Tuesday - Вторник, W - Wednesday - Среда, H - Thursday - Четверг, F - Friday - Пятница, A - Saturday - Суббота.

Ну а вместо h1:m1 и h2:m2 вставляется время. Запомните - h1:m1 всегда должно быть меньше h2:m2.

Итак, acl worktime time MTWHF 08:00-17:00 описывает рабочее время с понедельника по пятницу, с 8 утра до 5 вечера. acl weekday time SA описывает целиком субботу с воскресеньем, а acl evening time 17:00-23:59 описывает время до полуночи. Если необходимо описать всю ночь, то приходится заводить два ACL- первый с вечера до полуночи, а второй с полуночи до утра.

acl aclname url_regex [-i] ^http:// - regex-правила, применяемый ко всему URL.
acl aclname urlpath_regex [-i] \.gif$ - аналогичные правила, применяемые к URL.

acl aclname port 80 70 21 - ACL, описывающий порты. Вместо простого перечисления можно указать диапазон, например 1-1024.

acl aclname proto HTTP FTP - ACL, описывающий протокол, по которому клиент желает сделать запрос на сервер.

acl aclname method GET POST - метод, которым передаются данные клиента серверу.

acl aclname browser [-i] regexp - regexp запрос на клиентский браузер.
Вычисления основаны на заголовке User-Agent, который отдает браузер.

acl aclname ident username - ACL описывает имя пользователя, от которого запущена программа на клиентской машине. Имя узнается с помощью ident-сервера.

acl aclname ident_regex [-i] pattern - то же самое, но основанное на regex правилах.

acl aclname proxy_auth username
acl aclname proxy_auth_regex [-i] pattern - ACL, описывающие имя пользователя. Это имя возвращает внешняя авторизующая программа.

acl aclname maxconn number - Это правило сработает, если клиент сделат больше number запросов к кешу.

acl req_mime_type mime-type1 - правило, срабатывающие при аплоаде файлов клиентом. Заметье, АПЛОАДЕ, а не скачивании.

Я конечно, некоторые описания ACL пропустил (большей частью по незнанию, что они значат), но большинство необходимых в повседневной жизни я описал. Думаю, мо вам этого тоже будет достаточно. Если не достаточно - то добро пожаловать на просмотр squid.conf - там все описано, правда, по английски.

Итак, давайте создадим правила обычной сети.

acl all src 0.0.0.0/0.0.0.0
acl office src 192.168.1.0/255.255.255.0

all - правило, описывающий все машины и office - описывающий все машины в подсети 192.168.1.

http_access allow office
http_access deny all

эти два правила описывают полный доступ машинам, описываемый acl office и запрещает доступ машинам, описываемым all. Как же так - спросите вы - как могут машины использовать прокси-сервер, если они попадают под правило all - а этому правилу запрещено? Тут в дело вступает порядок просмотра ACL - они просматриваются в порядке обьявления, и если сработало одно правило, то другие уже не просматриваются.

К примеру, если мы введем в дополнение ACL
acl vasya src 192.168.1.100/255.255.255.255

и расположим правила так:

http_access allow office
http_access deny vasya
http_access deny all

то машина с ip-адресом 192.168.1.100 по прежнему будет иметь возможность ходить через прокси-сервер.

а если так:

http_access deny vasya
http_access allow office
http_access deny all

То все будет в порядке. Остальные офисные машины не попадают под действие первого правила.

Если в списке нет ни одно правила, то запрос будет отвергнут. Если не одно правило не сработало, то за основу берется последнее. Если, к примеру, мы заменим предпоследнее правило на http_access allow all, то нашим прокси-сервером смогут совпользоваться абсолютно все (кроме vasya), кто сможет соедениться с портом squid. Так что будьте аккуратнее. Но авторы squid постарались - даже если последнее правило будет разрешающим всем все, то запрос будет отвергнут. Это поможет избежать дыр в прокси-сервере.

На основе этих же списков правил так же управляется и доступ к другим возможностям прокси - опять отсылаю вас к файлу squid.conf, где все расписано.

Но правила-правилами, но у вас в сети завелись пользователи, которые честно подключаются к серверу и начинают выкачивать гигабайтами какую-нибудь гадость. При этом занесение этих сайтов в deny-список вызывает их возмущение и капание начальству на предмет того, что на этих серверах находится очень важная для процветания фирмы информация. Ну кто из администраторов не встречался с такими?

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

Итак, давайте разберемся с траффик-шейпингом - именно так эта штука называется. В squid же эта вещь носит название delay-pool. Замечу, что squid при сборке должен быть собран с опцией --enable-delay-pools.

Итак, сначала разберемся, какие есть пулы. Пулы делятся на 3 класса. Первый, и самый простой, это когда всему acl зарезается трафик до определенной величины. Второй - когда отдельно зарезается трафик для одной машины из подсети и для всей подсети. И третий класс - когда зарезается трафик для отдельных машин, для подсети класса С или меньше и для подсети класса B. Не понятно? Сейчас разьясню.

Итак, давайте обыграем ситуацию, когда у нас в сети завелся "дискокачальщик".

delay_pools 1 - у нас всего 1 пул.
delay_class 1 1 - 1й пул у нас первого класса
delay_access 1 allow vasya
delay_access 1 deny all

В первый пул попадают только машины, описываемые ACL vasya. Остальные ходят как им положенно - ведь им доступ к 1му пулу заказан.

delay_parameters 1 800/64000

Вот и все. Теперь файлики и страницы обьемом до 64кб будут скачиваться на максимальной скорости (то есть для веба хватит за глаза), а то, что больше этого - на скорости 800 байт в секунду.

Если он вас совсем достал, то напишите правило

delay_parameters 1 800/800 - и злобный качальшик все будет качать на скорости 800 байт в секунду.

Но у вас офис и в его канале периодически начинается толчея - все хотя что-то качать, в итоге никому ничего не хватает.

Исправляем строчку с delay_pools на
delay_pools 2

теперь у нас будет 2 пула

delay_class 2 2 - второй пул будет второго класса (совпадение номеров чисто случайно ;-)) - первый - это vasya

delay_access 2 allow office
delay_access 2 deny all

во второй пул попадают только машины с ACL office.

delay_parameters 2 64000/64000 4000/4000

В итоге вся подсеть, описываемая office, будет использовать канал не больше 512Кбит/с (64Кб/с), но каждый отдельный хост будет качать не более 4Кб в секунду. Этим правилом очень легко разграничить по скорости разные подсети, использующие один канал.

К примеру, у нас есть две подсети, описываемые office и office1. При этом office не должно иметь никаких ограничений на канал (примем канал за 256Кбит) в целом, но каждый из office не должен качать быстрее 6Кб/с. А office1 - это нехорошие дяденьки и тетеньки с большин гонором, которым всем и 5Кб/с хватит за глаза.

Создаем 2 пула 2го класса и прписываем для них ACL. Затем определяем этим пулам параметры.

delay_parameters 3 -1/-1 6000/6000 - это определение для office (ему отдан номер пула 3)

delay_parameters 4 5000/5000 -1/1 - а это для office1.

В итоге после применения этих правил получаем все, что заказано - первый офис грузит канал как хочет (-1/-1), но никто из сотрудников больше 6Кб/c на нос не получает. А второй офис грузит канал не больше 5Кб/с, а как данные 5Кб/с распределяются между его сотрудниками - не наша головная боль. Пауки в банке, так сказать.

Понятно, что в описание пулов можно заложить время, места и так далее, но конструирование таких правил я оставляю на вас - каждому нужно свое.

Остается еще одна маленькая вещь, мимо которой мы не можем пройти безнаказанно. И эта вещь - реклама. Не знаю, как вас, но меня достали эти разражающе мигающие и переливающиеся баннеры. И если порнуху можно запретить простым прописыванием сайтов в deny-листы, то с баннерами такая ситуация не проходит. То есть проходит, но страницы при этом портятся до безобразия. Но народ умный, он придумал такую вещь, как редиректор. Суть проста - каждый URL, который передается squid'у, первоначально передается редиректору. И тот либо возвращает
прежний URL в случае, если все в порядке, либо возвращает тот, который по его мнению, более правильный. А кто мешает нам перехватывать обращения к баннерам и счетчикам и вместо них подсовывать свою картинку? Никто!. В итоге страницы не портятся безобразными значками о невозможности выкачать картинку, а заполняются прозрачными окошками.

Итак, опять лезем в squid.conf и прописываем туда строку

redirect_program /squid/bin/redirector

где /squid/bin/redirector - путь до выполняемой программы, которая как раз и обеспечивает разбор URL. Ее можно написать на чем угодно, но наиболее предпочтительным является Perl - этот язык как раз предназначен для подобного рода работ.

Итак, вот эта программа.

#!/usr/bin/perl
$0 = 'redirect' ;
$| = 1 ;

@banners = ('reklama\.ru/cgi-bin/banner/',
'anekdot\.ru/cgi-bin/banner/',
..................
'linux\.ru\.net/counter\.ph',
'counter\.allhits\.ru/counter?'
);

while (<>) {
($url, $who, $ident, $method) = /^(\S+) (\S+) (\S+) (\S+)$/ ;
$url = 'http://linuxnews.ru/images/1x1.png'
if grep ($url=~/$_/i, @banners) ;
print "$url $who $ident $method\n" ;
}

Эта программа проста по сути - если данный URL попадает под список banners, то в ответ браузеру возвращается http://linuxnews.ru/images/1x1.png. Как легко догадаться - там лежит картинка размером 1 на 1 пиксел. Везде в описании баннеров и счетчиков стоит размер, поэтому браузеры сами растягивают эту картинку до размеров баннера. Понятно, что адрес можете заменить на свой, но можете оставить и мой - поесле первого обращения прокси закэширует эту картинку и больше к ней обращаться не будет.

Все, все необходимые действия проделаны (надеюсь, вы не забыли поставить аттрибут исполнения на redirector?), теперь просто перезагрузите сквид, очистите кэш браузера и пройдите по сайтам. Особый эффект наблюдается на price.ru - скорость закачки страниц подпрыгивает на очень большую величину.

При этом загрузка машины очень мала - даже я со своей домашней Р150 не замечаю замедления скорости работы. А трафик падает очень сильно - для диалапщиков такой редиректор просто спасение, потому как на некоторых сайтах (не буду показывать пальцем) обьем баннерной рекламы равен обьему полезной информации, а иногда и больше.

В общем, это хорошо. Да, чуть не забыл - полная версия редиректора лежит на http://linuxnews.ru/redirector - я ее обновляю время от времени, поэтому она почти соответствует последним веяниям баннеров (правда для тех сайтов, где народ из моего офиса обычно бывает). Оригинал редиректора был найден в сети, поэтому я никаких прав на него предявить не в состоянии, да и нет желания ;-)

Пользуйтесь на здоровье, вернее на пользу канала.

(с) 2001 Вячеслав Калошин multik@asplinux.ru

Linux.yaroslavl.ru