Настройка прокси-сервера Squid с множеством IP-адресов
Предположим, у сервера имеется несколько IP адресов — на одном интерфейсе или на разных — не важно.
Задача: использовать разные внешние IP адреса в зависимости от того, к какому порту прокси-сервера происходит обращение.
Итак, как вы можете видеть, на моём тестовом сервере 5 IP адресов, 1 IPv4 адрес и 4 IPv6 адресов:
Смотрите также:
Для решения указанной задачи содержимое файла /etc/squid/squid.conf следующее:
При обращении к странице https://w-e-b.site/ip/ показывается IP адрес клиента, сделавшего запрос. Проверим:
Теперь сделаем обращение к указанной странице через порты прокси-сервера от 24000 до 24003:
Как вы можете видеть, каждый раз выводится разный IPv6 адрес — в соответствии с тем, который из них привязан к определённому порту прокси-сервера.
Как вы думаете, какой IP адрес выведет следующая команда?
Напомню, что к порту 24004 привязан IPv4 185.117.153.79. Если ваш ответ «185.117.153.79», то вы ошибаетесь.
Выведено: 2a02:f680:1:1100::3d61 — это тот же самый IPv6 адрес, который используется по умолчанию.
Причина в том, что на самом деле привязка происходит не к IP адресу как к таковому, а к сетевому интерфейсу, на котором настроен данный IP. Кстати поэтому можно делать привязку и по MAC-адресу. При этом Squid работает следующим образом: если есть техническая возможность (локальный сервер и удалённый хост имеют IPv6 адреса), то по умолчанию используется именно IPv6.
У сайта w-e-b.site есть IPv4 и IPv6 адреса, Squid делает DNS запросы пытаясь получить A и AAAA записи, и если у удалённого хоста есть IPv6 адрес, то используется именно он. Чтобы подключиться к IPv6, сервер также должен использовать IPv6, поэтому выбирается один из доступных IPv6, а не привязанный к порту IPv4.
Можно ли было бы при привязке порта к IPv4 использовать именно IPv4 соединение даже если доступно IPv6? Технически для этого нет преград, но авторы Squid не сделали такой опции. Но вариант использовать IPv4 также есть, правда, не столь удобный.
Смотрите также руководство по настройке Squid: Как создать и настроить прокси-сервер Squid
Записки IT специалиста
Технический блог специалистов ООО»Интерфейс»
Перед многими системными администраторами встает вопрос ограничения доступа пользователей к тем или иным ресурсам сети интернет. В большинстве случаев в ресурсоемкой и сложной контент фильтрации нет необходимости, вполне достаточно URL-списков. Реализовать такой метод вполне возможно средсвами прокси-сервера squid не привлекая стороннего ПО.
Метод «черных» и «белых» списков идеально подходит для ограничения доступа к ресурсам, адреса которых заранее известны, но по какой-либо причине являются нежелательными, например социальные сети. По сравнению с контентной фильтрацией такой способ имеет множество недостатков, но с другой стороны он гораздо проще в реализации и требует гораздо меньше вычислительных ресурсов.
Эффективность данного метода следует рассматривать с точки зрения поставленной задачи, так если требуется заблокировать для сотрудников соцсети и ряд развлекательных ресурсов, на которых они проводят больше всего времени, то фильтрация по URL-спискам способна полностью решить эту проблему. В тоже время такая фильтрация окажется малоэффективной, если нужно ограничить доступ к любым ресурсам определенного содержания.
В дальнейшем мы будем подразумевать, что читатель обладает начальными навыками администрирования Linux. Также напомним, что все приведеные ниже команды следует выполнять от супрепользователя.
и приступим к его заполнению. При указании URL следует использовать RegExp синтаксис, мы не будем подробно останавливаться на этом вопросе, так как это выходит за рамки статьи, подробнее с правилами RegExp можно ознакомиться здесь. Для примера заблокируем популярные соцсети:
Обратите внимание, точка в RegExp является служебным симоволом и поэтому должна быть экранирована символом \ (обратный слеш).
В конфигурационном файле squid (/etc/squid/squid.conf) создадим acl список, в который включим хосты или пользователей, для которых будет производиться фильтрация.
В нашем случае фильтрация включена для всех хостов в диапазоне адресов 10.0.0.100-199, т.е. мы будем фильтровать интернет только для определенной группы пользователей.
Затем подключим наш список:
Теперь перейдем в секцию правил и перед правилом
Сохраним изменения и перезапустим squid:
Попробуем посетить сайт из списка, если все сделано правильно, то вы увидите сообщение squid о запрете доступа к данному ресурсу.
В дальнейшем вы можете дополнять списки, не забывая каждый раз после этого перезапускать squid.
Рассмотрим немного иную ситуацию, требуется фильтровать интернет для всех, кроме определенной группы. В этом случае создадим acl для исключенных пользователей:
и изменим запрещающее правило следующим образом:
Также вы можете использовать несколько URL-списков и списков доступа, гибко регулируя доступ для разных групп пользователей.
Вернемся к регулярным выражениям. Допустим, что нам нужно заблокировать не ресурс целиком, а его часть, тогда составим строку таким образом, чтобы она обязательно содержала нужную часть адреса, например строка:
Заблокирует доступ к социальной сети Мой мир, но не будет препятствовать доступу к Майл.ру.
В качестве строки можно использовать не только доменное имя, но и его часть. Так если мы внесем в список простую строку
то это приведет к блокировке всех ресурсов, у которых данное сочетание входит в доменное имя, т.е. и mail.ru и hotmail.com. Поэтому к составлению списков, особенно содержащих короткие простые сочетания, нужно подходить осторожно.
Рассмотрим простой, но показательный пример. Допустим нужно заблокировать известный сайт auto.ru и его поддомены. Если мы, не долго думая, напишем
То вместе с требуемым порталом будут заблокированы все сайты имеющие данное сочетание в имени, например abc-auto.ru. Есть о чем задуматься. Если с поддоменами все просто, достаточно написать
и все что содержит точку перед искомым адресом будет заблокировано, то с основным доменом сложнее, самое время вспомнить про полный формат адреса:
Теперь будут заблокированы только адреса начинающиеся с http://auto.ru, конструкция (www\.)? обозначает, что префикс www c точкой могут быть, а могут не быть. Зато другие сайты, содержащие auto.ru будут нормально открываться.
Напоследок рассмотрим еще одну ситуацию, как сделать, чтобы на заблокированом сайте были доступны некоторые страницы. Например, страничка компании в Вконтакте или вы хотите обезопасить определенные адреса от случайного попадания под фильтр в будущем. Для этого следует добавить к системе «белый» список. Создадим файл списка:
внесем в него нужные адреса, для примера разблокируем страничку Вконтакте новостного портала Утро.ру:
и добавим правило перед запрещающим, в итоге должно получиться:
Так как разрешающее правило расположено раньше, то указанные в «белом» листе ресурсы будут доступны, несмотря на то, что будут попадать под правила «черного».
Как видим, технология URL-фильтрации по спискам при помощи squid очень проста и позволяет в кратчайшие сроки ограничить доступ к нежелательным ресурсам, ниже приведен набор используемых нами списков, которыми вы можете воспользоваться.
Squid список ip адресов
Схема контроля доступа в Squid достаточно развита и тяжела для понимания некоторым людям. Она состоит из двух различных компонентов: элементов ACL, и списков доступа. Список доступа состоит из директивы allow или deny и указанных вслед за ней элементами ACL.
элементы ACL
Замечание: Информация, представленная здесь верна для версии 2.4.
Не все элементы ACL могут быть использованы со всеми видами списков доступа (описаны ниже). К примеру, snmp_community предназначено для использования тольско совместно с snmp_access. Типы src_as и dst_as используются только в списках доступа cache_peer_access.
Некоторые элементы ACL могут вносить задержки в работу кеша. Например, использование src_domain и srcdom_regex требует обратного преобразования клиентского IP. Это преобразование вносит некоторую задержку в обработку запроса.
Каждый элемент ACL обозначается уникальным именем. Имя элемента ACL содержит список значений. Когда проверяется совпадения для некольких значений используется логическое И. Другими словами, элемент ACL совпал когда совпало одно из значений.
Вы не можете указывать одинаковое имя для двух различных типов элементов ACL. Это вызовет синтаксическую ошибку.
Вы можете присваивать различные значения одному и тому же ACL в разлинчых строках. Squid объеденит их в один список.
Списки доступа
Правило списка доступа состоит из слова allow или deny, с последующим указанием списка имен элементов ACL.
Список доступа состоит из одного или более правил списков доступа.
Правила списков доступа проверяются в порядке их объявления. Поиск по по списку прекращается как только одно из правил совпадает.
Если правило содержит несколько элементов ACL, используется логическое ИЛИ. Другими словами, все элементы ACL, указанные в этом правиле должны совпасть, чтобы правило сработало. Это значит, что есть возможность написать правило, которое никогда не сработает. К примеру, номер порта никогда не может быть равен 80 И 8000 одновременно.
10.2 Как мне разрешить моим клиентам использовать кеш?
Объявите ACL, описывающий IP-адреса клиентов. К примеру: Далее разрешите доступ этим клиента при помощи списка http_access:
10.3 Как мне настоить Squid, чтобы он не кешировал определенный сервер?
10.4 Как мне организовать ACL списка запрета?
Предположим, к ппримеру, что вы желаете избавить пользователей от доступа к рецептам.
10.5 Как мне блокировать доступ к кешу определенны пользователям и группам?
Ident
Вы можете использовать ident lookups чтобы разрешить доступ к вашему кешу определенным пользователям. Это потребует запуска процесса ident server на клиентской машине(ах). В вашем конфигурационном файле squid.conf вам необходимо будет написать нечто подобное:
Proxy Authentication
В Squid вер.2 аутентификация производится через внешний процесс. Информацию как настроить это см. в разделе Configuring Proxy Authentication.
10.6 А у вас есть CGI-программа, позволяющая пользователям менять свой пароль доступа к прокси?
Pedro L Orso переделал htpasswd от Apache в CGI-скрипт, называемый chpasswd.cgi.
10.7 Есть ли способ осуществлять поиск ident только для определенного хоста и сравнивать результат со списком пользователей в squid.conf?
Если вы используете ACL типа user в squid conf, то Squid будет выполнять ident lookup для каждого клиентского запроса. Другими словами, Squid-1.1 выплоняет ident поиск для всех запросов или не выполняет вообще. Объявление ACL типа user включает поиск ident, вне зависимости от значения ident_lookup.
Однако, хотя запросы ident выплоняются для каждого запроса, Squid не ожидает их завершения, если ACL того не требует. Взгляните на следующую конфигурацию: Запросы, пришедшие с 10.0.0.1, будут разрешены немедленно, т.к. не указано пользователя для этого хоста. Однако запросы с 10.0.0.2 будут разрешены только после завершения поиска ident и если установлено, что имя пользователя kim, lisa, frank или joe.
10.8 Типичные ошибки
Логическое И/ИЛИ
К примеру, следующая конфигурация контроля доступа никогда не будет работать: Для того, чтобы запрос был разрешен, он должен совпасть и с acl «ME» И acl «YOU». Это невозможно, т.к. IP-адрес в данном случаю может совпасть либо с одним либо с другим acl. Это должно быть заменено на: Такая конструкция тоже должна работать:
перепутанные allow/deny
Я перечитал несколько раз мой squid.conf, поговорил с коллегами, почитал FAQ и документацию по Squid Docs и никак не могу понять почему следующее не работает.
Я успешно подключаюсь к cachemgr.cgi с нашего web-сервера, но хотелось бы использовать MRTG для мониторинга различных параметров нашего прокси. Когда я пытаюсь использовать ‘client’ или GET cache_object с машины, на которой работает проски, то всегда получаю «доступ запрещен».
Приведенная здесь задача состоит в том, чтобы разрешить запросы кеш-менеджера с адресов localhost и server и запретить все остальные. Такая политика описывалась правилом:
To implement the desired policy correctly, the access rules should be rewritten as Если вы используете miss_access, не забывайте также добавить правило miss_access для кеш-менеджера:
Различия между src и srcdomain типами ACL.
Для типа ACL srcdomain Squid делает обратное преобразование клиентского IP-адреса и проверяет соответствие результата домену, описанному в строке acl. Для типа ACL src Squid вначале преобразует имя хоста в IP-адрес и только потом сравнивает с клиентским IP. Тип ACL src предпочтительнее, чем srcdomain т.к. он не требует преобразования адреса в имя при каждом запросе.
10.9 Я установил собственные контроли доступа, но они не работают! Почему?
В squid.conf включите отладку для секции 33 на уровне 2. К примеру: Потом перезапустите Squid.
Теперь, ваш cache.log должен содержать строку для каждого запроса, которая поясняет запрещен или резрешен запрос и с каким ACL он совпал.
Если это не дало вам достаточно информации, чтобы избавиться от проблемы, вы можете также включить детальную отладку процесса обработки ACL Перезапустите Squid.
Теперь ваш cache.log должен содержать детальную трассировку всего процесса контроля доступа. Будте внимательны, на каждый запрос будет по несколько несколько строк.
10.10 Прокси-аутентификация и братские кеши
Proxy A посылает ICP-запрос на Proxy B о объекте, Proxy B отвечает ICP_HIT. Proxy A перенаправляет HTTP-запрос к Proxy B, но не проходит аутентификация, а посему HTTP GET для Proxy A завершается неудачно.
Поэтому вы должны разрешить братским кешам опрашивать друг друга без прокси-аутентификации. Это просто выполнить указав список ACL братских кешей прежде списков доступов в строках http_access. К примеру:
10.11 Какой самый простой способ запретить все адреса назаначения кроме одного?
10.13 Squid не распознает мой поддомен
Есть хитрая проблема с контрольм доступа, основанным на имени домена, когда один элемент ACL является является поддоменом другого элементаy. К примеру, взляните на такой списко:
Проблема в том, что нелья сказать, что co.us больше чем, равно или меньше чем boulder.co.us.
К примеру, если вы утверждаете, что co.us МЕНЬШЕ чем fff.co.us, то аглоритм поиска по Splay-дереву может никогда не обнаружить совпадения co.us для kkk.co.us.
Аналогично, если вы говорите, что co.us БОЛЬШЕ чем fff.co.us, то алгоритм поиска по Splay-дереву может никогда не обнаружить совпадения co.us для bbb.co.us.
Суть в том, чт овы не можете указать значение, которое являетсяподдоменом другого значения. Squid-2.2 сообщит вам, если обнаружит подобное условие.
10.14 Почему Squid запрещает доступ к некоторым портам?
Есть два сопсоба фильтрации по номерам портов: либо разрешить определенные порты, либо запретить определенные порты. По умолчанию Squid использует первый вариант. Вот ACL-лы, которые присутсвуют по улолчанию в squid.conf: Указанная выше конфигурация блокирует запросы номер порта в URL которых не совпадает со списком. Разрешен список стандартных портов для HTTP, FTP, Gopher, SSL, WAIS, а также непривелигерованых портов.
Загляните в файл /etc/services вашей системы, чтобы получить полный список портов и протоколов.
10.15 А Squid поддерживает использование базы данных типа mySQL для хранения списков ACL?
Замечание: Информация верна для версии 2.2.
Нет, не поддерживает.
10.16 Как мне разрешить доступ к определенному URL только с одного адреса?
Этот пример разрешает доступ к special_url только для special_client. Любому другому клиенту доступ к special_url запрещен.
10.18 Как мне разрешить некоторым пользователям использовать кеш только в определенное время?
10.19 Проблемы с IP ACL-ми, содержащими сложные маски
Замечание: представленная здесь информация верна для версии 2.3.
Следующий ACL дает противоречивый или неожиданный результат: Причина в том, что IP-список доступа помещается в структуру данных в виде «splay»-дерева. Это дерево треубет сортировки ключей. Когда вы указываете сложную или нестандартную маску (255.0.0.128), это приводит к неверной работе функции сравнивающей пару адрес/маска.
При этом, конечно, вам придется переписать ваши правила http_access.
10.20 Могу ли я устанавливать ACL-лы, основанные на MAC-адресах, а не на IP?
Да, для некторых операционных систем. В Squid этоназывается «ARP ACLs» и поддерживается на Linux, Solaris и возможно для BSD вариантов.
ЗАМЕЧАНИЕ: Squid может определить MAC-адрес клиента только для свое подсети. Если клиент находится в другой подсети, Squid не сможет найти его MAC-адрес.
Если всеоткомпилировалось, вы можете добавить несколько строк ARP ACL в ваш squid.conf:
10.21 Отладка ACL
10.22 Могу ли я органичить количество соединений для клиента?
Да, используйте ACL типа maxconn совместно с http_access deny. К примеру:
Учитивая вышеописанную конфигурацию, когда клиент чей IP-адрес находится в сети 1.2.3.0/24 попытается установить 6 или более соединений за одни раз, Squid вернет сообщение о ошибке. Пока вы не используете возможности deny_info, сообщение о ошибке будет звучать как «access denied.»
Заметьте, что ACL типа maxconn достаточно специфичен из-за использования сравнения «мешьше чем». ACL считается совпавшим, когда количество установленных соединений больше величины, которую вы указали. Исходя из этого вы врядли захотите использовать ACL типа maxconn в http_access allow.
Заметьте также, что вы вы должны объявлять maxconn совместно с типом пользователя (ident, proxy_auth) раньше, чем объявляется тип по IP-адресу.
10.23 Я пытаюсь запретить доступ к foo.com, но это не срабатывает.
10.24 Я хочу изменить или создать собственное сообщение о ошибке.
Вы можете изменять существующие сообщения об ошибках как описано в Customizable Error Messages. Вы также можете создавать новые сообщения о ошибках и использовать их совместно с опцией deny_info.
Далее, установите следующий контроль доступа:
Для системного администратора
Настройка Squid для чайников
ВСТУПЛЕНИЕ
Многие администраторы сталкиваются с проблемой разумного использования времени и канала для выхода в сеть Интернет, задумываются о возможности экономии времени и денег, об ограничении скорости для отдельных видов файлов или личностей, в конце концов об экономии всего, что связано с теми или иными аспектами выхода в глобальную сеть.
Я, с помощью этой статьи, попытаюсь наглядно и доходчиво объяснить о настройках самого распространенного прокси сервера – прокси сервера Squid.
НАЧАЛЬНЫЕ НАСТРОЙКИ SQUID ДЛЯ ДОСТУПА ПОЛЬЗОВАТЕЛЕЙ
Мы не будем вдаваться в процесс установки прокси сервера Squid, а перейдем сразу к его настройке.
Самое элементарное, что нам после установки следует сделать, так это разрешить доступ пользователям нашей локальной сети. Для этого служат параметры http_port, http_access. Кроме этого, мы заведем acl (список контроля доступа) для нашей локальной сети.
И так, http_port нам нужен постольку, поскольку наш прокси сервер Squid должен обслуживать только компьютеры нашей локальной сети и быть невидимым для внешнего мира, дабы исключить возможность “плохим людям” внешней сети воспользоваться нашим каналом или трафиком, а в случае, если будут обнаружены “дыры” в коде прокси сервера
Squid, воспользоваться ими.
Параметр http_access используется для разрешения или запрещения доступа к определенным ресурсам, определенным адресам либо с определенных адресов, к определенным сайтам, по определенным протоколам, портам и всему тому, что непосредственно указано с помощью Acl (списков контроля доступа).
Таблица N 1. Некоторые подсети.
|Диапазон адресов |Полная форма |Краткая форма
192.168.0.1-192.168.0.254 192.168.0.0/255.255.255.0 192.168.0.0/24
192.168.20.1-192.168.20.254 192.168.20.0/255.255.255.0 192.168.20.0/24
192.168.0.1-192.168.254.254 192.168.20.0/255.255.0.0 192.168.20.0/16
10.0.0.1-10.254.254.254 10.0.0.0/255.0.0.0 10.0.0.0/8
Предположим, что у Вас сеть с адресами от 192.168.0.1 до 192.168.0.254, тогда добавим новый Acl (см. таблицу N1):
acl LocalNet src 192.168.0.0/24
Предположим, что у Вас прокси сервер Squid расположен по адресу 192.168.0.200 на порту 3128, тогда пишем в файле конфигурации:
Следующим нашим действием будет запрет использования нашего прокси сервера, кроме как пользователями нашей локальной сети:
http_access allow LocalNet
http_access deny all
В данном случае слово allow является разрешением, а слово deny запрещением, то есть мы разрешаем доступ к прокси серверу Squid с адресов нашей локальной сети и запрещаем доступ всем остальным.
Будьте внимательны, указывая http_access, так как Squid использует их в порядке указания Вами.
ИЗУЧАЕМ ACL (СПИСКИ КОНТРОЛЯ ДОСТУПА)
Система управления доступом в прокси сервере Squid является очень гибкой и обширной. Она состоит из элементов со значениями и списков доступа c указанием allow (разрешение) или deny (запрещение).
Формат Acl следующий:
acl имя элемент список
Формат списка доступа:
http_access указание имя_acl
Мы рассмотрим некоторые элементы, которые позволяет использовать прокси сервер Squid, конечно же с примерами:
* acl имя src список
С помощью этого элемента (src) мы указываем IP-адрес источника, то есть клиента от которого пришел запрос к нашему прокси серверу.
В следующем примере мы разрешим Васе Пупкину (Pupkin) и отделу программирования (Progs) доступ к нашему прокси серверу, а всем остальным запретим:
acl Progs src 192.168.0.1-192.168.0.9
acl Pupkin src 192.168.0.10
http_access allow Progs
http_access allow Pupkin
http_access deny all
* acl имя dst список
Данный элемент (dst) указывает IP-адрес назначения, то есть IP-адрес того сервера, доступ к которому желает получить клиент прокси сервера.
В следующем примере мы запретим Васе доступ к подсети 194.67.0.0/16 (к примеру, в ней находится тот же aport.ru):
acl Net194 dst 194.67.0.0/16
http_access deny Pupkin Net194
* acl имя dstdomain список
С помощью этого элемента (dstdomain) мы указываем домен, доступ к которому желает получить клиент прокси сервера.
В следующем примере мы запретим Васе доступ к варезным сайтам nnm.ru и kpnemo.ru:
В случае, если будет необходимо указать домен источника, то используйте srcdomain.
* acl имя [-i] srcdom_regex список
* acl имя [-i] dstdom_regex список
Данные элементы отличаются от srcdomain и dstdomain лишь тем, что в них используются регулярные выражения, которые в данной статье мы не рассматриваем, но пример всё-таки приведём:
* acl имя [-i] url_regex список
С помощью этого элемента (url_regex) мы указываем шаблон регулярного выражения для URL.
Пример указания файлов с расширением avi, начинающихся на слово sex:
В случае, если Вы желаете указать шаблон только для пути URL, то есть исключая протокол и имя хоста (домена), то используйте urlpath_regex.
Пример для указания музыкальных файлов:
* acl имя_acl port список
Указание номера порта назначения, то есть порта, к которому желает подключится клиент нашего прокси сервера.
Как пример, запретим всем использование программы Mirc через наш прокси
сервер:
Acl Mirc port 6667-6669 7770-7776
http_access deny all Mirc
* acl имя_acl proto список
Указание протокола передачи.
Как пример, запретим вышеупомянутому Васе использование протокола FTP через наш прокси сервер:
acl ftpproto proto ftp
http_access deny Pupkin ftpproto
* acl имя_acl method список
Указание метода http запроса клиентом (GET, POST).
Возьмем ситуацию, когда следует запретить Васе Пупкину просматривать его почту на сайте mail.ru, но при этом разрешить прогуливаться по сайту без запретов, то есть запретить Васе возможность войти в свой почтовый ящик через форму входа на сайте:
ОГРАНИЧЕНИЯ ПОЛЬЗОВАТЕЛЕЙ
Достаточно часто в нашей стране возникает ситуация, что канала доступа в глобальную сеть Интернет на всех пользователей не хватает и возникает желание дать каждому по максимуму, но при этом не дать каналу “загнуться” из-за любителей позагружать файлы.
Средства прокси-сервера Squid позволяют этого добится несколькими путями:
ОГРАНИЧЕНИЯ ПО ВРЕМЕНИ
граничить пользователей по времени можно следующим образом:
acl имя time дни чч:мм-ЧЧ:ММ
При этом чч:мм должно быть меньше чем ЧЧ:ММ, то есть можно указать с 00:00-23:59, но нельзя указать 20:00-09:00.
Давайте запретим всё тому же Васе иметь доступ в сеть Интернет с 10 до 15 часов каждый день:
acl TimePupkin time 10:00-15:00
http_access deny Pupkin TimePupkin
Если хочется разрешить Васе пользоваться программой Mirc с 13 до 14 часов, то пишем:
acl TimePupkin time 13:00-14:00
http_access allow Pupkin TimePupkin Mirc
http_access deny Pupkin Mirc
А что делать, если необходимо запретить или разрешить в определенные дни недели? Squid также позволяет это сделать, к примеру с 13 до 14 в понедельник и в воскресенье:
acl TimePupkin time MS 13:00-14:00
Как видите, ничего сложного в этом нет.
ОГРАНИЧЕНИЯ ПО СКОРОСТИ
Регулировка скорости в прокси сервере Squid осуществляется с помощью пулов. Пул – это своего рода бочонок с пивом, в который пиво постоянно заливают до краёв, а клиенты наливают в свои стаканы или иные ёмкости для дальнейшего внутреннего потребления по мере надобности через свои персональные краны.
Пулы регулируются с помощью трех параметров: delay_class, delay_parameters, delay_access. Количество пулов указывается с помощью параметра delay_pools.
Пулы могут быть трёх классов:
delay_pools количество_объявленных_пулов
delay_access номер_пула действие имя_acl
действие может быть allow (разрешить) и deny (запретить). При этом, данный пул действует на тех, кому он разрешен и не действует на тех, кому он запрещен. В случае, если указано allow all, а затем deny Pupkin, то на Пупкина данный класс всё-равно подействует, т.к. IP-адрес Пупкина объявленный в acl Pupkin, входит в список адресов acl all. Имейте это
ввиду.
delay_class номер_пула класс_пула
delay_parameters номер_пула параметры
параметры отличаются в зависимости от класса пула:
для первого класса:
delay_parameters 1 байт_на_всю_сеть
для второго класса:
delay_parameters 1 на_всю_сеть на_клиента
для третьего класса:
delay_parameters 1 на_всю_сеть на_подсеть на_клиента
Для примера, у нас канал на 128 Кбит (в среднем 15 Кбайт в секунду) и мы желаем Васе (Pupkin) дать всего 4 Кбайта/сек (на все про всё один маленький бокальчик), отделу программирования (Prog) дать всего 10 Кбайт/сек и на каждого всего по 5 Кб/сек (всего два бокальчика), всех остальных ограничить в 2 Кбайта/сек на каждого и 10 Кб/сек на всех, а файлы mp3 (media) ограничить в 3 Кбайта в секунду на всех (на всю бочку пива такой маленький кран). Тогда пишем:
Часто возникает вопрос, а как лучше всего использовать столь малый канал, чтобы он автоматически делился между всеми теми, кто в данный момент что-либо загружает? На этот вопрос имеется однозначный ответ – средствами прокси сервера Squid этого сделать не возможно, но всё-таки кое-что предпринять можно:
Таким образом мы выделяем на всю нашу сеть и на подсети максимальный канал (-1 означает неограниченность), а каждому пользователю даем скорость максимум в 5 Кб/сек после того, как он скачает на максимальной скорости первые 15 Кбайт документа. Таким образом клиент не съест весь канал, но достаточно быстро получит первые 15 Кбайт.
ОПТИМИЗИРУЕМ КЕШИРОВАНИЕ ОБЪЕКТОВ В SQUID
Существует множество типов файлов, которые обновляются не достаточно часто, чтобы позволить прокси серверу реагировать на заголовки от вебсерверов о том, что данный объект не подлежит кешированию либо он был на удивление только что изменён. Это довольно частая ситуация.
Для разрешения таких ситуаций призван параметр refresh_pattern в файле настроек прокси-сервера Squid, но полностью с формулами и т.п. мы его рассматривать не будем.
refresh_pattern [-i] строка МИНВ процент МАКСВ параметры
Данный параметр используется для того, чтобы определить возраст объекта (считайте файла) в кеше, следует ли его обновлять или нет.
МИНВ (минимальное время) – время в минутах, когда объект, имеющийся в кеше считается свежим.
МАКСВ (максимальное время) – максимальное время в минутах, когда объект считается свежим.
Параметры – это один или несколько следующих параметров:
– override-expire – игнорировать информацию об истечении свежести объекта
и использовать МИНВ.
– override-lastmod – игнорировать информацию о дате изменения файла и
использовать МИНВ.
– reload-into-ims – вместо запроса клиентского запроса “не кешировать
документы” (no-cache) посылать запрос “Если изменен с”
(If-Modified-Since)
– ignore-reload – игнорировать запросы клиентов “не кешировать документы”
(no-cache) или “перезагрузить документ” (reload).
И так, мы подошли к самом главному. Ну, так какие же типы файлов реже всех обновляются? Как правило, это разнообразные музыкальные файлы и картинки.
Установим свежесть объектов, для этого для картинок и музыкальных файлов укажем, скажем так для примера, целых 30 дней (43200 минут):
Показанные Выше настройки лишь пример, для того, чтобы была понятна суть. Теперь можете проверить эффективность своего прокси сервера, она уж точно возрастет.
ЗАКЛЮЧЕНИЕ
Прокси сервер Squid не является одним лишь распространенным прокси сервером, существуют и другие. Но как показывает статистика, большинство используют именно этот прокси сервер, но при этом всё равно у многих
начинающих возникают проблемы с настройкой. С помощью этой статьи я попытался хоть немного раскрыть для обширных
масс некоторые функции прокси сервера Squid.
