Настраиваем squid | ||
| Сети > Для новичка Общая настройка сквида чаще всего не вызывает сложностей. Сложности обычно вызывают три вещи — настройка 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 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 maxconn number — Это правило сработает, если клиент сделат больше number запросов к кешу. acl req_mime_type mime-type1 — правило, срабатывающие при аплоаде файлов клиентом. Заметье, АПЛОАДЕ, а не скачивании. Я конечно, некоторые описания ACL пропустил (большей частью по незнанию, что они значат), но большинство необходимых в повседневной жизни я описал. Думаю, мо вам этого тоже будет достаточно. Если не достаточно — то добро пожаловать на просмотр squid.conf — там все описано, правда, по английски. Итак, давайте создадим правила обычной сети. acl all src 0.0.0.0/0.0.0.0 all — правило, описывающий все машины и office — описывающий все машины в подсети 192.168.1. http_access allow office эти два правила описывают полный доступ машинам, описываемый acl office и запрещает доступ машинам, описываемым all. Как же так — спросите вы — как могут машины использовать прокси-сервер, если они попадают под правило all — а этому правилу запрещено? Тут в дело вступает порядок просмотра ACL — они просматриваются в порядке обьявления, и если сработало одно правило, то другие уже не просматриваются. К примеру, если мы введем в дополнение ACL и расположим правила так: http_access allow office то машина с ip-адресом 192.168.1.100 по прежнему будет иметь возможность ходить через прокси-сервер. а если так: http_access deny vasya То все будет в порядке. Остальные офисные машины не попадают под действие первого правила. Если в списке нет ни одно правила, то запрос будет отвергнут. Если не одно правило не сработало, то за основу берется последнее. Если, к примеру, мы заменим предпоследнее правило на http_access allow all, то нашим прокси-сервером смогут совпользоваться абсолютно все (кроме vasya), кто сможет соедениться с портом squid. Так что будьте аккуратнее. Но авторы squid постарались — даже если последнее правило будет разрешающим всем все, то запрос будет отвергнут. Это поможет избежать дыр в прокси-сервере. На основе этих же списков правил так же управляется и доступ к другим возможностям прокси — опять отсылаю вас к файлу squid.conf, где все расписано. Но правила-правилами, но у вас в сети завелись пользователи, которые честно подключаются к серверу и начинают выкачивать гигабайтами какую-нибудь гадость. При этом занесение этих сайтов в deny-список вызывает их возмущение и капание начальству на предмет того, что на этих серверах находится очень важная для процветания фирмы информация. Ну кто из администраторов не встречался с такими? На этот счет придумали много вещей, но самой эффективной остается ужимание канала для таких пользователей — доступ есть, но качается плохо — возразить им нечего — такая ситуация в интернете не редкость. Итак, давайте разберемся с траффик-шейпингом — именно так эта штука называется. В squid же эта вещь носит название delay-pool. Замечу, что squid при сборке должен быть собран с опцией —enable-delay-pools. Итак, сначала разберемся, какие есть пулы. Пулы делятся на 3 класса. Первый, и самый простой, это когда всему acl зарезается трафик до определенной величины. Второй — когда отдельно зарезается трафик для одной машины из подсети и для всей подсети. И третий класс — когда зарезается трафик для отдельных машин, для подсети класса С или меньше и для подсети класса B. Не понятно? Сейчас разьясню. Итак, давайте обыграем ситуацию, когда у нас в сети завелся «дискокачальщик». delay_pools 1 — у нас всего 1 пул. В первый пул попадают только машины, описываемые 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 — второй пул будет второго класса (совпадение номеров чисто случайно delay_access 2 allow office во второй пул попадают только машины с 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 " ;
}
Эта программа проста по сути — если данный URL попадает под список banners, то в ответ браузеру возвращается http://linuxnews.ru/images/1×1.png. Как легко догадаться — там лежит картинка размером 1 на 1 пиксел. Везде в описании баннеров и счетчиков стоит размер, поэтому браузеры сами растягивают эту картинку до размеров баннера. Понятно, что адрес можете заменить на свой, но можете оставить и мой — поесле первого обращения прокси закэширует эту картинку и больше к ней обращаться не будет. Все, все необходимые действия проделаны (надеюсь, вы не забыли поставить аттрибут исполнения на redirector?), теперь просто перезагрузите сквид, очистите кэш браузера и пройдите по сайтам. Особый эффект наблюдается на price.ru — скорость закачки страниц подпрыгивает на очень большую величину. При этом загрузка машины очень мала — даже я со своей домашней Р150 не замечаю замедления скорости работы. А трафик падает очень сильно — для диалапщиков такой редиректор просто спасение, потому как на некоторых сайтах (не буду показывать пальцем) обьем баннерной рекламы равен обьему полезной информации, а иногда и больше. В общем, это хорошо. Да, чуть не забыл — полная версия редиректора лежит на http://linuxnews.ru/redirector — я ее обновляю время от времени, поэтому она почти соответствует последним веяниям баннеров (правда для тех сайтов, где народ из моего офиса обычно бывает). Оригинал редиректора был найден в сети, поэтому я никаких прав на него предявить не в состоянии, да и нет желания Пользуйтесь на здоровье, вернее на пользу канала. |
||
) — первый — это vasya| Комментарии | ||
