Описание SQUID прокси-сервера

Squid – это высокопроизводительный кеширующий прокси-сервер для web-клиентов, поддерживающий FTP, gopher и HTTP объекты данных. В отличие от традиционного кеширующего ПО, Squid обслуживает все запросы как один не.блокируемый процесс ввода/вывода. Одним из достоинств, является то, что он хранит кеш не только на жёстком диске, но и часто обрабатываемые объекты держит в оперативной памяти (ОЗУ) системы, среди этих объектов могут присутствовать не только элементы сайтов, но и DNS адреса, чтоп позволяет увеличить скорость поиска сайта в глобальной сети.

Squid потребляет очень скромную часть ресурсов системы, что даёт возможность устанавливать его даже на самые посредственные конфигурации железа. Например, если вы имеете CPU 800Mhz, ОЗУ 512 Mb и жёсткий диск 20Gb, то этого вполне будет достаточно, чтобы он обслуживал >50 клиентов и предоставлять доступ в интернет.

А тот факт, что Squid поддерживает несколько вариантов авторизации (по IP, через базу LDAP, MySQL, NTLM) делает его ещё более привлекательным. Для новичков хочу сразу акцентировать внимание – Squid является HTTP/SSL/FTP прокси сервером! И не более этого! Т.е. пытаться отправить или принять почту через него, не в коем случае нельзя, т.к. он попросту не умеет работать с pop3, imap, smtp протоколами. Для этих целей используем либо NAT (настраиваем проброс портов через iptables), либо делаем связку Exim4+dovecot или Postfix+dovecot.

Ещё одним интересным свойством Squid'a является то, что он умеет работать в режиме каскадный прокси сервер.

Т.е. он может не только брать информацию с интернета, но и сначала опрашивать соседей/родителей, на предмет наличия такой информации у них в кешэ, а только потом принимает решение о загрузки данных, если они отсутствуют, из интернета. На рисунке выше, представлена следующая схема: все пользователи находятся в одной сети, группа 2 выходит в интернет через сервер squid 2, группа 1 выходит в интернет чрез squid 1, то в свою очередь ищет данные в кеше у себя, далее стучится к родителю (parent) за информацией, squid 2 смотрит у себя в кеше, если не находит, то берёт данные из интернета. Сразу наверно возникнет вопрос "а зачем 2 прокси сервера? зачем использовать каскадное проксирование?". Ответов может быть много, во-первых, это прирост производительности, т.к. не 1 сервер трудится, а 2. Во-творых, это даёт возможность реализовывать разные типы авторизации на сервере. Например на squid 2 у нас будет жёсткая аутентификация по ip адресам, а на squid 1 будет прозрачная аутентификация с пропуском в интернет всех желающих. Кстати маленькая заметка – Squid не умеет одновременно работать в прозрачном режиме и в режиме аутентификации. Для тех кто не понял, прозрачная аутентификация – это выход в интернет без манипуляций с настройками в браузере. Этот режим похож на то, как работает NAT. Но в данном случае есть 1 большой недостаток – в прозрачном режиме squid не работает с ssl, это особенность технологии TCP/IP, т.е. на https:// у вас зайти не получится.

Этой возможностью (каскадное проксирование) можно воспользоваться и в случае, если у вас есть 2 провайдера и вы решили не заморачиваться, насчёт того, чтобы выводить разных пользователей через разных провайдеров, через 1 squid, а поставили 2 squid сервера и раскидали пользователей по ним. Например у нас падает интернет на одном из провайдеров и чтобы не бегать по всем клиентам, настройки не изменять, можно просто этот сервер squid, на котором пропал интернет, пустить через рабочий, на время технических работ. И пользователи не заметят, и вам особо ничего сложного делать не придётся, всего пару строк добавить и перезапустить сквид. Но и тут есть 1 недостаток, у вас через SSL данные не будут передаваться, т.к. он, squid, всё равно будет пытаться напрямую выйти в интернет, а не через родителя. Это решается тем, что задаётся жёсткое правило, пускать весь трафик только через родителя. Данный момент подробнее и нагляднее будет рассмотрен в настройке squid.

А теперь приступим к самому интересному! Да да! Это самое интересное в squid'е, – постройка правил. В squid эта система называется ACL (списки контроля доступа от англ. Access Control List), "аклы" настолько гибко настраиваются, что одну и ту же задачу можно решить не то что несколькими способами, а десятками! Всё упирается только в фантазию и уровень развития логического мышления системного администратора.

Общий синтаксис описания правил таков: acl <имя нашего правила> <тип> <значение>

Например нам нужно добавить правило "список всех машин в нашей сети", с условием что наша сеть является 192.0.0.0/255.0.0.0, правило будет выглядеть следующим образом:

acl all src 192.0.0.0/255.0.0.0

Теперь мы можем для all делать либо запрет, либо доступ, либо скорость, либо ресурсы ограничивать.

Вот список важных ACL тип:

acl name src ip-address/netmask  - IP адрес клиента

acl name src addr1-addr2/netmask – диапазон IP адресов клиентов

acl name dst ip-address/netmask – IP адрес URL хоста

acl name arp mac-address – проверяет MAC адрес клиента (работает только под *nix системами, и squid должен скомпилирован с опцией –enable-arp-acl)

acl name srcdomain .site.com – имя хоста клиента

acl name dstdomain .site.com – имя хоста сервера назначения

acl name url_regex [-i] ^https://google.ru – регулярное выражение, вбирающее в себя адрес гугла, со всей его глубиной

acl name urlpath_regex [-i] \.gif$ – регулярное выражение, проверяющее URL путь (в данном примере мы привязываем правило ко всем адресам, на концах которых .gif картинки)

acl name port 80 21 443 – привязываем порты к правилу (обратите внимание, перечисление идёт через пробел)

acl name port 0-81 – указываем диапазон портов

acl name proto HTTP FTP – привязываем правило к протоколу

acl name method GET POST CONNECT – метод соединения (забегая вперёд скажу, что для аськи и других подобных служб, которые должны постоянно в сети висеть, обязательно нужно добавить правило на разрешение соответствующего порта и метода CONNECT)

Опция [-i] указывает на то, чтобы регистр не учитывался.

Данных типов вам будет достаточно, для построения максимально гибкой системы контроля и доступа, но если и этого будет недостаточно, то обратитесь на официальный сайт squid'а www.squid-cache.org

Надеюсь после прочитанного у вас уже появилось желание поскорее установить и настроить squid, но пока не спешите, вас ещё ожидает несколько "вкусностей". А именно, – способы аутентификации в squid. Здесь тоже стоит задуматься, так как выбрать то есть из чего. Для начала посмотрим синтаксис определения типа аутентификации: auth_param <схема> <тип> <программа> <параметры>

Например, у нас есть файл, в котором записаны пользователи и их пароли, по строке на юзверя, можно сделать следующее auth_param basic program /usr/local/libexec/ncsa_auth /squid/users.txt и так-же необходимо добавить 2 дополнительные директивы, это кол-во процессов которые будут заниматься аутентификацией auth_param basic children 5 (слишком мало нельзя, иначе если пользователи хлынут разом, а процессов будет мало, то часть пользователей получат ошибку доступа в ответ) и сообщение, которое будет показано в окне браузера auth_param basic realm Web-proxy . Если сейчас клиент попробует подключиться, то у него появится "дружелюбное" окно, которое спросит имя и пароль, после ввода таковых, squid пойдёт проверять файл, и если там таких не найдёт, то попросит пользователя ввести данные ещё раз. 

Виды аутентификации в SQUID:

LDAP: использует Lightweight Directory Access Protocol

NCSA: использует NCSA-стиль для файла имен пользователей и паролей.

MSNT: использует Windows NT authentication domain.

PAM: использует Linux Pluggable Authentication Modules scheme.

SMB: использует SMB-север типа Windows NT или Samba.

Так-же на просторах интернета встречал и MySQL аутентификацию, но самому её опробовать не приходилось.

Очень важный момент – в squid можно использовать несколько типов авторизации одновременно, и пользователь будет проходить через них, по мере описания таковых в конфиге. Так же можно авторизированных пользователей добавлять к правилам, например acl god proxy_auth REQUIRED запись будет означать, что все авторизированные пользователи будут попадать в правило god.

SQUID умеет не только разграничивать пользователей по уровню доступа, но ещё и умеет ограничивать скорость для разных групп или единичных пользователей. Эта система называется delay_pools,  с помощью которой бы задаём количество "пулов", далее мы указываем какой "пул", к какому классу принадлежит, через delay_class, потом следует перечисление правил, которые могут входить в этот "пул" delay_access или знаком отрицания ! которые исключаются. Но если группа не входит в правила разрешённых, значит она автоматически переходит в правила запрещённых. Кстати, знак отрицания ! можно так-же использовать и при формирования "аклов". Ну и последним описанием идёт определение параметров для пула, который принадлежит одному из классов delay_parameters

В squid'е существовало всего 3 класса, но с 3й версии, появилось ещё 2 новых, к сожалению я не вникал в принцип их работы, поэтому описывать буду только 3 классических класса. Но будьте уверены, этих классов будет достаточно с полна! А кому-то, для малой сети, и вовсе хватит одного 1го класса.

1й класс ограничивает общую скорость для всех хостов входящих в определенную группу. Например:

acl users src 0.0.0.0/0.0.0.0

delay_pools 1

delay_class 1 1

delay_access 1 allow all

delay_parameters 1 60000/120000

для хостов описанных в правиле доступа all, ограничение скорости будет до 58,5 кбайт/с, при этом первые 117 кбайт будут скачиваться на максимальной скорости, это ограничение общее и действует на всех.

2й класс ограничивает общую скорость загрузки и скорость загрузки индивидуальной машины. Если вам так будет проще, то представьте, что пулы, это вёдра, то во 2м классе 1 общее ведро на сеть и внутри него ещё несколько вёдер на каждого пользователя. Т.е. если 1 пользователь забьёт свой канал, то каналы 2х других пользователей будут пусты. Например:

acl users src 192.168.0.1/255.255.255.0

delay_pools 1

delay_class 1 2

delay_access 1 allow users

delay_parameters 1 -1/-1 60000/120000

Получается, что на сеть 192.168.0.1/255.255.255.0 мы даём безграничное ведро (-1/-1 означает, что лимит отсутствует), но для каждого пользователя мы ограничиваем скорость в 58,5 кбайт/с и первые 177 кбайт пользователи получат на максимальной скорости соответственно. Это удобно делать, если у нас есть несколько небольших сетей, в которых есть по десятку компьютеров. Допустим бухгалтерскую сеть вообще не ограничиваем, а вот менеджеров держим в жёстких рамках.

3й класс ограничивает общую скорость загрузки, скорость загузки подсети и скорость загрузки индивидуальной машины.

acl users src 192.168.0.1/255.255.255.0

acl buh src 172.16.0.1/255.255.255.0

delay_pools 1

delay_class 1 3

delay_access 1 allow users !buh

delay_parameters 1 -1/-1 64000/128000 4000/1000

Общая скорость не ограничена, а для сетей описанных в правилах доступа users и buh она ограничена 64000/128000 и мало того, каждый IP в данных сетях ограничен 4000/1000. При этом на IP адрес из правила доступа buh это не распространяется, так как в параметре delay_access перед buh стоит знак отрицания !

Ну и разумеется, после всего это, описания авторизации, правил, пулов, следует последний блок значений, это уровень доступа. Описывается он командой http_acces, применяется для указания каким правилам разрешено ходить и куда ходить. Или наоборот, кому куда нельзя. Так-же как и при работе с "пулами" и "аклами" здесь можно использовать знак отрицания ! , например:

http_access allow buh safe_ports

http_access deny users safe_ports

Т.е. бухгалтерам разрешаем ходить через порты, описанные в ACL для safe_ports, а юзерам запрещаем. Внимание! Порядок следования разрешений имеет значение! Будьте внимательны при составлении правил!

Ну вот в принципе и всё. Базовые понятия о работе и общих свойствах кеширующего прокси-сервера вы теперь знаете, теоретическую часть считаю завершённой, теперь можно приступать пробовать настроить squid на практике, далее выбираете в меню соответствующий раздел и приступайте к изучению.