Непосредственно после установки Squid уже поддерживает функции прокси, но принимает соединения только с того компьютера, на который установлен. Для того, чтобы можно было воспользоваться этим сервисом с других компьютеров, необходимо изменить т. н. таблицы управления доступом (Access Control Lists, далее ACL), находящиеся, как и большинство настроек Squid, в файле /etc/squid/squid.conf. Файл этот снабжён подробными комментариями и примерами по всем настройкам в виде комментариев, например, так:

# TAG: некоторая_настройка

Таким же образом там описаны все значения, выставленные по умолчанию. В частности, для того, чтобы Squid принимал соединения из всей внутренней сети, необходимо раскомментировать две строки и подставить в них действительный диапазон адресов вашей сети:

acl our_networks src 192.168.1.0/24 192.168.2.0/24
http_access allow our_networks

Следует иметь в виду, что при обработке запроса на доступ к Squid все строки http_access файла squid.conf просматриваются последовательно сверху вниз до первой строки, соответствующей параметрам запроса. Это означает, что важен порядок следования строк http_access.

При использовании прокси-сервера остаётся некоторая угроза безопасности, связанная с тем, что топология внутренней сети и активность её абонентов не маскируются. Например, в протоколе HTTP используются т. н. заголовки (headers), значения которых заполняются броузерами при отправлении запроса. Squid умеет удалять опасные поля заголовка из запроса при помощи настройки header_access или подменять их значения на другие, заранее заданные, при помощи настройки header_replace. Варианты использования этих настроек приведены в squid.conf в районе TAG: header_access и TAG: header_replace соответственно. Имейте в виду, что из-за удаления и/или подмены полей заголовков может нарушиться связь с некоторыми системами, использующими значение этих полей для организации взаимодействия и авторизации.

Можно вообще не сообщать пользователям сети, что в ней используется прокси-сервер. Если прокси-сервер — одновременно и маршрутизатор, весь сетевой трафик в любом случае его не обойдёт. При этом можно средствами межсетевого экрана все обычные HTTP-запросы к удалённым серверам перенаправлять на вход особым образом настроенного Squid. С внешней стороны это будет выглядеть обычным прокси-сервером, а со стороны пользователя — ничем не будет отличаться от обычной работы в сети. Команда iptables, перенаправляющая HTTP-запросы к внешним серверам на порт Squid может, например, выглядеть так:

# iptables -t NAT -A PREROUTING -d ! адрес_самого_сервера \
	-i внутренний_сетевой_интерфейс -p tcp -m tcp --dport 80 \ 
-j REDIRECT --to-ports 3128

Или так:

# iptables -t nat -A PREROUTING -p tcp -d 0/0 --dport www \
-i внутренний_сетевой_интерфейс -j DNAT \
--to локальный_адрес_на_котором_слушает_прокси:3128

Настройка squid.conf при этом использует обратное проксирование, описанное ниже. Как сказано в документации по Squid, для организации прозрачного прокси достаточно добавить в squid.conf строку

http_port 80 transparent

В Squid существует гибкая схема фильтрации внешних ссылок. С её помощью, например, можно закрыть доступ к определённым сайтам и ресурсам на них, избавиться от навязчивой рекламы (banners), ссылок непристойного содержания и т. п. Содержимое фильтруется с помощью всё тех же ACL и настроек http_access deny, примеры которых приведены в squid.conf. Обратите внимание, что при задании фильтруемого URL или доменного имени сервера можно использовать регулярные выражения, таким образом в одной строке определяя фильтр для целого класса адресов или доменных имён. Подробнее о регулярных выражениях можно прочитать в руководстве regex(7). Запрет доступа к домену baddomain.com, например, можно оформить в виде строк

acl Bad dstdomain baddomain.com
http_access deny Bad

Заметим также, что http_access deny Bad следует помещать перед строками вида http_access allow, в этом случае доступ к любому сайту домена будет закрыт безусловно.

В Squid есть возможность определять различные ACL разным пользователям и/или категориям пользователей. Если для определения того, какой именно пользователь подключается к серверу, недостаточно IP-адреса его компьютера, следует воспользоваться одной из многих схем авторизации, принятых в Squid. Авторизация конфигурируется с помощью тега TAG: auth_param. Посмотреть, какие схемы (программы) авторизации поддерживает Squid, можно в каталоге /usr/lib/squid.

Например, настройка авторизации в LDAP может выглядеть так:

auth_param basic program /usr/lib/squid/squid_ldap_auth -b
ou=People,dc=office,dc=lan -f (uid=%s) -h ldap.office.lan
auth_param basic children 5
auth_param basic realm Squid proxy-caching web server
auth_param basic credentialsttl 2 hours

Информацию по настройке той или иной программы авторизации можно почерпнуть из соответствующих руководств.

Непосредственно после установки сервера он уже выполняет кеширующие функции. Кеширование позволяет не только сэкономить на оплате трафика, но и уменьшить время доступа к ресурсам Интернет. Однако следует понимать, что снижение внешнего трафика возможно только если один и тот же ресурс был запрошен несколькими пользователями на протяжении некоторого промежутка времени. Если пользовательские запросы почти не пересекаются, снижение трафика может быть незначительным.

Кроме того, кеширование неэффективно в ситуации, когда повторный запрос на большинство объектов приходит уже после того, как эти объекты вытесняются из кеша более новыми. Если анализ статистики показывает, что происходит именно это, можно попробовать увеличить объём кешируемой информации. Настройки Squid, отвечающие за размер кеша, приведены в файле squid.conf в разделе, начинающемся словами OPTIONS WHICH AFFECT THE CACHE SIZE.

Наконец, кеширование входного потока данных делает невозможной “справедливую” оплату различными пользователями их собственного трафика. Например, если один пользователь посещает некие сайты по совету другого, то его трафик будет по большей части не выходить за пределы сервера, на котором ресурсы этих сайтов уже — по милости первого пользователя — закешированы.

Некоторые данные (например, очень большие файлы, автоматически изменяемые WWW-страницы, звуки и т. п.) кешировать невыгодно: вероятность повторного запроса в течение “срока годности” низкая, а других объектов вытесняется много. С другой стороны, содержимое некоторых сайтов может понадобиться кешировать в обязательном порядке (например, для ускорения доступа). Эти свойства управляются, как обычно, при помощи ACL и настроек always_direct (без кеширования) и never_direct (обязательное кеширование). Например, чтобы предотвратить кеширование файлов, получаемых по протоколу FTP (это, как правило, разумно), необходимо в соответствующем месте squid.conf раскомментировать строки

acl FTP proto FTP
always_direct allow FTP

Если запрашиваемый ресурс не найден в локальном кеше Squid, он может попытаться запросить его у “вышестоящих” серверов или у “соседей” — вместо того, чтобы обращаться в Интернет. Таким вышестоящим сервером (parent peer) может быть сервер провайдера, а соседом (sibling peer) — сервер абонента, подключённого к тому же провайдеру. Правила передачи объектов кеша и формирования иерархии серверов описаны в документации Squid. Раздел конфигурационного файла, отвечающий за механизм обмена кешем, начинается словами OPTIONS WHICH AFFECT THE NEIGHBOR SELECTION ALGORITHM.

Необходимо знать, что обмен содержимым кеша требует непременной авторизации доступа между серверами (во избежание подлогов и другого вида атак). Все параметры соединения сервера с сервером (настройка cache_peer) записываются в текстовом виде, включая пароли, так что следует строго ограничить доступ к файлу настройки squid.conf.

В режиме accelerate сервер сам принимает извне HTTP-запросы, адресованные, как правило на 80-й порт. Кроме того, необходимо указать имя сервера и порт, на который будут проксироваться запросы. Это можно сделать, например, так

http_port 80 defaultsite=internal.www.com
cache_peer 192.168.1.1 parent 80 0 no-query originserver

Если необходимо как-то ограничить доступ к внутреннему серверу, это легко сделать, применив соответствующие ACL.

Для обратного проксирования нескольких внутренних серверов необходимо, чтобы внешние запросы на сайты с разными доменными именами попадали на вход Squid, который бы ставил в соответствие каждому имени действительный адрес сервера во внутренней сети и перенаправлял бы запрос туда. Делается это с помощью механизма виртуальных хостов. Вот как, например, можно организовать прокси для двух серверов, www1.foo.bar и www2.foo.bar, адреса которых в DNS указывают на машину со Squid-сервером (файл /etc/squid/squid.conf):

http_port 80 defaultsite=www1.foo.bar vhost
hosts_file /etc/hosts

Настройка defaultsite нужна серверу для заполнения HTTP-заголовков. Соответствие доменных имён адресам серверов во внутренней сети разумно получать из стандартного файла /etc/hosts:

10.0.0.1    www1.foo.bar
10.0.0.2    www2.foo.bar

Множественное обратное проксирование имеет важный побочный эффект. В сетях, подключённых к Интернету постоянно, нередки случаи, когда недобросовестные администраторы внутренних сайтов регистрируют их в других доменах и используют их в качестве хостинг-платформ, часто с документами незаконного или нецензурного содержания. Допустим, сайт www1.foo.bar также зарегистрирован как www.verycoolwarez.com, и по этому адресу доступны контрафактные версии программ и т. п. В обычном случае для обнаружения этого факта необходимо анализировать трафик, делать внушение администратору www1.foo.bar и т. д. При использовании обратного проксирования такого вообще не может произойти без договорённости с администратором Squid, то есть без занесения в /etc/hosts!

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

Неаккуратно настроенный прокси-сервер можно использовать для массовой рассылки почты (спама), что осуждается правилами пользования сетью Интернет и может привести к отказу пользователей Сети и администраторов почтовых серверов принимать почту с вашего домена.

В Squid входит утилита кеш-менеджер, служащая для отображения статистики и загрузки сервера. Кеш-менеджер представляет собой cgi-приложение и должен выполняться под управлением сконфигурированного HTTP-сервера. Все настройки кеш-менеджера также производятся в /etc/squid/squid.conf, строки, которые относятся к кеш-менеджеру, обычно включают cachemgr.

При помощи Squid можно ограничить полосу пропускания (“толщину канала”) для пользователей. За это отвечают параметры delay_pools и delay_class. Эта технология позволит вам снизить загрузку канала, например, большими по объёму медиафайлами, и отдать полосу какому-то более приоритетному трафику.

Squid содержит встроенный минисервер запросов DNS. Он выступает как посредник между Squid и внешними DNS-серверами. При запуске Squid производит начальное тестирование доступности DNS и интернет в целом. Это можно отключить, используя опцию -D. Время кеширования удачного DNS-запроса по умолчанию составляет шесть часов.