вызывают три вещи - настройка 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 - второй пул будет второго класса (совпадение номеров
чисто случайно
) - первый - это vasyadelay_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 Вячеслав Калошин [email protected]
