Эти два правила описывают полный доступ машинам, описываемым acl office, и запрещает доступ машинам, описываемым all. В приведенном примере есть конфликт в описания прав доступа: машины, попадающие под правило all (а по этому правилу все запрещено) не могут использовать Proxy-сервер. Тут в дело вступает порядок просмотра 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 по-прежнему будет иметь возможность соединяться через Proxy сервер;
а если так:
http_access deny vasya http_access allow office http_access deny all ,
то все будет в порядке. Остальные офисные машины не попадают под действие первого правила.
Если в списке нет ни одного правила, то запрос будет отвергнут. Если ни одно правило не сработало, то за основу берется последнее. Если, к примеру, мы заменим предпоследнее правило на http_access allow all, то нашим Proxy-сервером смогут пользоваться абсолютно все (кроме vasya), кто сможет соединиться с портом squid. Так что будьте внимательнее. Но авторы squid постарались: даже если последнее правило будет разрешающим для всех, то запрос будет отвергнут. Это поможет избежать дыр в Proxy-сервере.
На основе этих же списков-правил так же управляется и доступ к другим возможностям Proxy-сервера (см. файл squid.conf, где все расписано).
Правила – правилами, но, предположим, что в сети появились пользователи, которые честно подключаются к серверу и начинают выкачивать гигабайтами запрещенную информацию. При этом занесение этих сайтов в deny-список вызывает их возмущение.
На этот счет придумали много вещей, но самым эффективным остается сокращение канала для таких пользователей: доступ есть, но качается плохо, возразить им нечего – такая ситуация в Internet не редкость.
Итак, давайте разберемся с «траффик-шейпингом» – именно так это называется. В squid же это называется delay-pool. Заметим, что squid при сборке должен быть собран с опцией --enable-delay-pools.
Итак, сначала разберемся, какие есть пулы. Пулы делятся на три класса. Первый, и самый простой, это когда всему acl ограничивается трафик до определенной величины. Второй – когда отдельно ограничивается трафик для одной машины из подсети и для всей подсети. И третий класс – когда ограничивается трафик для отдельных машин, для подсети класса С или меньше и для подсети класса B.
Итак, давайте обыграем ситуацию, когда в сети завелся «дискокачальщик».
delay_pools 1 – у нас всего один пул.
delay_class 1 1 – первый пул первого класса.
delay_access 1 allow vasya
delay_access 1 deny all
В первый пул попадают только машины, описываемые ACL vasya. Остальные работают, как им положено, ведь им доступ к первому пулу запрещен.
delay_parameters 1 800/64000
Вот и все. Теперь файлы и страницы объемом до 64 Кб будут скачиваться на максимальной скорости, а то, что больше этого – на скорости 800 б/c.
Или совсем уж радикальная мера:
delay_parameters 1 800/800 – и «злобный качальщик» все будет качать на скорости 800 б/c.
Но даже в не очень большой сети будут возникать ситуации, когда все хотят что-то качать, в итоге никому ничего не хватает.
Исправляем строчку с delay_pools на delay_pools 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 Кб/c. Этим правилом очень легко разграничить по скорости разные подсети, использующие один канал.
К примеру, у нас есть две подсети, описываемые office и office1. При этом office не должна иметь никаких ограничений на канал (примем канал за 256 Кбит) в целом, но каждый из office не должен качать быстрее 6 Кб/с. А office1 – это пользователи, которым всем и 5 Кб/с хватит.
Создаем два пула второго класса и прописываем для них ACL. Затем определяем этим пулам параметры.
delay_parameters 3 -1/-1 6000/6000 – это определение для office (ему отдан номер пула 3).
delay_parameters 4 5000/5000 -1/1 – а это для office1.
В итоге после применения этих правил получаем все, что заказано – первый офис грузит канал как хочет (-1/-1), но никто из сотрудников больше 6 Кб/c не получает. А второй офис грузит канал не больше 5 Кб/с, но в распределении этих 5 Кб/с между сотрудниками нет никаких правил.
Понятно, что в описание пулов можно заложить и другие параметры, например, время, место доступа и т. д. Остается еще одна маленькая вещь, которую нельзя оставить без внимания. И эта вещь – навязанная реклама через баннеры и другие объекты. Для того, чтобы такую рекламу не пропустить на броузер, каждый URL, который передается squid, первоначально передается редиректору. И тот либо возвращает прежний URL в случае, если все в порядке, либо возвращает тот, который, по его мнению, более правильный. А кто мешает нам перехватывать обращения к баннерам и счетчикам и вместо них подсовывать свою картинку? В итоге страницы можно заполнить прозрачными окошками.
