шесть вещей, которые должен знать новичок-администратор Squid

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

предельное число дескрипторов файлов

Общей проблемой для новичков-пользователей Squid является предельное число дескрипторов файлов. Это связано с тем, что в некоторых операционных системах на один процесс и на всю систему в целом предусмотрены относительно низкие лимиты. В некоторых случаях, чтобы настроить вашу систему перед компиляцией Squid, вы должны выполнить определенные действия.
Дескриптор файла — это просто число, которое представляет открытый файл или сокет. Каждый раз, когда процесс открывает новый файл или сокет, он определяет место для нового дескриптора файла. После закрытия файла или сокета эти дескрипторы используются повторно. Большая часть систем Unix накладывает ограничение на число одновременно открытых дескрипторов файлов. Эти ограничения касаются как одного процесса, так и всей системы.
Сколько дескрипторов файлов требуется Squid? Ответ зависит от количества пользователей, от размера кэша и конкретных функций, которые вы задействовали. Ниже приведены некоторые случаи, при которых в Squid используются дескрипторы файлов:
— соединения по протоколу TCP на стороне клиента;
— соединения по протоколу TCP на стороне сервера;
— запись на диск кэшированных ответов;
— чтение с диска удачных обращений в кэш;
— файлы регистрации.
— связь с процессами внешнего хелпера, такими как редиректоры и аутентификаторы;
— Постоянные (в режиме ожидания) соединения по протоколу HTTP.
Даже если Squid ничего не делает, у него есть некоторое количество дескрипторов, открытых для файлов регистрации и хелперов. В большинстве случаев это число находится в диапазоне между 10 и 25, что, вероятно, не так уж много. Это число возрастает, если у вас много внешних хелперов. Однако как только Squid начинает обслуживание запросов, количество дескрипторов файлов возрастает реально. В самом худшем случае для каждого запроса требуется три дескриптора файлов: для клиентского соединения, соединения с веб-сервером при отсутствии запрашиваемой информации в кэше и для чтения данных из кэша или записи новых, только что запрошенных документов в кэш.
Приемлемое число дескрипторов для кэша Squid с несколькими пользователями равно 256. Для Squid средней занятости оптимальный лимит равен 1024. Очень занятые кэши должны использовать 4096 или более дескрипторов. Нужно помнить только о том, что часто необходимость в использовании дескрипторов файлов на короткие промежутки времени превышает нормальный уровень. Это может случиться во время коротких временных простоев сети или других перерывов в обслуживании.
Чтобы определить предельное число дескрипторов файлов в вашей системе, существует ряд способов. Один из них заключается в использовании встроенных в оболочку команд limit или ulimit.
Для пользователей Bourne Shell (sh, bash):

root# ulimit -n
1024

Для пользователей C Shell (csh):

root# limit desc
descriptors 1024

Если у вас Squid уже скомпилирован и инсталлирован, вы можете просто посмотреть в файле cache.log строку типа этой:

2003/12/12 11:10:54| With 1024 file descriptors available (Есть 1024 дескриптора)

Если Squid обнаружит во время работы нехватку дескрипторов, вы увидите в файле cache.log предупреждение типа этого:

WARNING! Your cache is running out of file descriptors

Если вы увидите предупреждение или узнаете заранее, что вам нужно большее число дескрипторов, вы должны увеличить лимит. Методика увеличения лимита файловых дескрипторов для разных операционных систем разная.

для пользователей Linux

Пользователям Linux надо отредактировать один из заголовочных файлов и настроить один системный параметр через интерфейс /proc. Сначала отредактируете /usr/include/bits/types.h и измените это значение константы __FD_SETSIZE на нужное вам. Затем задайте ядру новый лимит такой командой:

root# echo 1024 > /proc/sys/fs/file-max

И, наконец, перед компиляцией или запуском Squid, чтобы установить лимит процесса, равный лимиту ядра, выполните эту команду:

root# ulimit -Hn 1024

После того как вы таким образом установили лимит, вам нужно переконфигурировать, перекомпилировать и переинсталлировать Squid. Следует заметить также, что эти две команды устанавливают лимит не навсегда. Их нужно выполнять каждый раз при загрузке вашей системы. Вы можете добавить их в ваш сценарий запуска системы.

для пользователей NetBSD/OpenBSD/FreeBSD

В BSD-системах вам нужно будет скомпилировать новое ядро. Файл конфигурации ядра находится в каталоге вида /usr/src/sys/i386/conf или /usr/src/ sys/arch/i386/conf. Там вы найдете файл, возможно с именем GENERIC, к которому следует добавить строку вида:

options   MAXFILES=8192

Для OpenBSD вместо options используйте option. После того как вы закончили конфигурацию, компиляцию и инсталляцию вашего нового ядра, перезагрузите систему. Затем переконфигурируйте, перекомпилируйте и переинсталлируйте Squid.

для пользователей Solaris

Добавьте к вашему файлу /etc/system строку вида:

set rlim_fd_max = 1024

Затем перезагрузите систему, переконфигурируйте, перекомпилируйте и переинсталлируйте Squid.
Более подробную информацию, касающуюся лимитов файловых дескрипторов, можно найти в полном руководстве по Squid, часть3, «Компиляция и инсталляция» или в Squid FAQ, раздел 11.4.

права доступа к файлам и каталогам

Права доступа к каталогам — еще одна проблема, с которой сталкиваются новички. Одна из причин такого затруднения заключается в том, что Squid в интересах безопасности отказывается работать с правами root. Более того, если вы запустите Squid с правами root, он переключается на пользователя по умолчанию nobody, который не имеет никаких особых привилегий. Если вы не хотите использовать в качестве имени пользователя nobody, вы можете выбрать другое с помощью директивы cache_effective_user файла конфигурации.
Некоторые файлы и каталоги должны быть доступны на запись пользователю, под которым выполняется Squid. К ним относятся файлы регистрации, которые, как правило, можно найти в /usr/local/squid/var/logs и кэш-директориях, по умолчанию — в /usr/local/squid/var/cache.
Для примера допустим, что вы используете для Squid имя пользователя “nobody”. После того как отработает инсталляция, вы можете использовать эту команду, чтобы установить доступ к файлам регистрации и кэш:

root# chown -R nobody /usr/local/squid/var/logs
root# chown -R nobody /usr/local/squid/var/cache

Затем вы можете продолжить инициализацию кэша такой командой:

root# /usr/local/squid/sbin/squid –z

Процессы хелпера являются еще одним источником потенциальных проблем доступа. Squid порождает процессы хелпера как пользователя без привилегий, т.е. как nobody. Это обычно означает, что программа хелпера должна иметь права на чтение и выполнение для любого пользователя, например, -rwxr-xr-x. Более того, любые файлы конфигураций или паролей, которые нужны хелперу, должны также иметь соответствующие права на чтение.
Следует заметить, что Unix также требует надлежащих прав на родительские каталоги. Например, если каталог /usr/local/squid принадлежит пользователю root и имеет права доступа -rwxr-x---, то пользователь nobody не сможет получить доступ к какому-либо каталогу, расположенному ниже.Поэтому правильными правами доступа к каталогу /usr/local/squid будут -rwxr-xr-x.
Вам может понадобиться решить проблемы по правам доступа к каталогам из шелла. Если Squid работает как nobody, то потом запускает процесс shell под nobody:

root# su - nobody

(Может быть вам понадовится на время изменить домашний каталог пользователя nobody и программу shell). Затем попытайтесь читать, писать или выполнять те файлы, которые могут быть причиной ваших трудностей. Например:

nobody$ cd /usr
nobody$ cd local
nobody$ cd squid
nobody$ cd var
nobody$ cd logs
nobody$ touch cache.log

управление использованием памяти Squid

Squid склонен к захвату памяти. Он использует память в самых разных целях, одни из которых легче поддаются управлению, чем другие. Используемость памяти является очень важным показателем, т.к. если размер процесса Squid превышает емкость RAM вашей системы, некоторые участки памяти процесса должны быть временно перекачаны на диск. Перекачка, или свопинг, также может иметь место, если у вас есть другие приложения, остро нуждающиеся в памяти и работающие в той же системе. Свопинг очень быстро приводит к снижению эффективности работы Squid.
Существует легкий способ управлять загрузкой памяти Squid с помощью таких стандартных системных инструментов, как top и ps. Вы можете также с помощью администратора кэша или интерфейсов SNMP спросить сам Squid, сколько памяти он использует. Если размер процесса становится слишком большим, вы можете предпринять шаги по его уменьшению. Самая хорошая рекомендация по оптимальной загрузке — это не допускать, чтобы размер процесса Squid превышал 60%-80% от общей емкости вашей RAM.
Одной из наиболее важных областей применения, связанных с загрузкой памяти, является главный индекс кэш. Это такая хэш-таблица, которая для каждого объекта в кэш содержит небольшой объем метаданных. К сожалению, все эти «небольшие» структуры данных в общей сложности составляют большой объем, приводящий к тому, что Squid заполняется миллионами объектов. Единственный способ управлять размером индекса внутренней памяти — это изменить с помощью директивы cache_dir размер кэша на диске. Таким образом, если у вас есть много места на диске, но мало в RAM, область на диске будет недостаточно использованной.
Кэш внутренней памяти Squid также может использовать большие объемы RAM. Там Squid хранит поступающие и недавно извлеченные объекты. Ее размер управляется настройкой директивы cache_mem. Следует заметить, что директива cache_mem влияет только на размер кэша памяти, но не на объем всей памяти Squid.
Squid использует также какой-то объем памяти для различных буферов ввода-вывода. Например, каждый раз, когда клиент делает запрос в Squid по протоколу HTTP, некоторое количество буферов памяти сначала распределяется, а затем позднее освобождается. Squid использует подобные буферы при направлении запросов на веб-серверы, а также при чтении и записи дисковых файлов. В зависимости от объема и типа трафика, поступающего в Squid, эти буферы ввода-вывода могут потребовать много памяти. Вы мало что можете сделать, чтобы управлять использованием памяти в данном случае. Однако вы можете попытаться изменить размер приемного буфера TCP с помощью директивы tcp_recv_bufsize.
Если у вас много клиентов, имеющих доступ к Squid, вы можете обнаружить, что «клиент DB» занимает больше памяти, чем вам бы хотелось. Для IP-адреса каждого клиента, который посылает запросы в Squid, он поддерживает небольшое число регистров. Вы можете немного сократить использование памяти Squid, запретив эту функцию. Просто избавьтесь от “ client_db” в squid.conf.
Другое обстоятельство, которое может помочь, заключается в том, чтобы просто периодически перезапускать Squid, скажем, раз в неделю. По прошествии времени может произойти нечто такое (простой сети, например), что вынудит Squid временно распределить большой объем памяти. Даже если Squid больше не использует эту память, последняя все еще может быть подключена к процессу Squid. Перезапуск Squid позволит вашей операционной системе реально освободить память для других нужд.
Вы можете использовать директиву Squid high_memory_warning, которая предупредит вас, когда размер его памяти превысит определенный предел. Например, добавьте к squid.conf строку подобно этой:

high_memory_warning 400 MB

Тогда, если процесс превысит это значение, Squid во время конфигурации запишет в cache.log и syslog.

ротация файлов регистрации

Во время работы Squid делает записи в разные журналы и файлы регистрации (в народе — лог-файлы или просто логи). Эти файлы будут постоянно расти в объеме, пока вы не примите решение произвести их ротацию. Ротация сводится к процессу закрытия файла регистрации, переименования его и открытия нового файла регистрации. Аналогичным образом большинство систем поступают со своими файлами syslog, такими как /var/ log/messages.
Если вы эти файлы не подвергнете ротации, они, в конечном счете, могут занять все свободное пространство в этом сегменте. Некоторые операционные системы, такие как Linux, не могут поддерживать файлы, превышающие 2 Gb. Когда это происходит, вы получаете сообщение об ошибке "File too large" (файл слишком большой). Squid выразит недовольство и рестартует.
Чтобы избежать подобных проблем, создайте задание cron, которое будет периодически производить ротацию файлов регистрации. Например:

0 0 * * * /usr/local/squid/sbin/squid -k rotate

В большинстве случаев ежедневная ротация файлов регистрации себя оправдывает. Логи не очень загруженного кэша можно подвергать ротации раз в неделю или месяц.
В процессе ротации Squid присоединяет к файлам регистрации цифровые суффиксы. Каждый раз, когда вы запускаете squid -k rotate, цифровой суффикс каждого файла увеличивается на единицу. Таким образом, cache.log.0 становится cache.log.1, cache.log.1 становится cache.log.2 и т.д. Чтобы поддержать ротацию, директива logfile_rotate определяет максимальное число старых файлов. Ротация файлов регистрации не ограничивается просто воздействием на файлы регистрации в /usr/local/squid/var/logs. Она также генерирует для каждого кэш-директория новые файлы swap.state. Однако Squid не хранит старые копии файлов swap.state. Он просто записывает новый файл из индекса внутренней памяти и забывает о старом.

понимание синтаксиса управления доступом

Squid имеет обширный, но до некоторой степени путанный набор команд управления доступом. Самое главное заключается в том, чтобы понять разницу между типами, элементами и правилами списка управления доступом (ACL), и того, как они работают вместе, чтобы разрешать доступ или препятствовать ему.
Squid имеет около 20 разных типов ACL. Они относятся к определенным аспектам запроса или ответа по протоколу HTTP, таким как IP-адрес клиента (тип src), имя хоста веб-сервера (тип dstdomain) и метод запроса по протоколу HTTP (тип method).
Элемент ACL состоит из трех компонентов: типа, имени и одного или более значений, характерных для этого типа. Ниже приведено несколько простых примеров:

acl Foo src 1.2.3.4
acl Bar dstdomain www.cnn.com
acl Baz method GET

Указанный выше элемент с именем Foo должен соответствовать запросу, который поступает от IP-адреса 1.2.3.4. Элемент ACL с именем Bar соответствует URL www.cnn.com. Элемент с именем Baz соответствует запросу GET по протоколу HTTP. Заметим, что мы еще ничего не разрешали или ничему не препятствовали.
Для большинства типов элемент может иметь множество значений, таких как:

acl Argle src 1.1.1.8 1.1.1.28 1.1.1.88
acl Bargle dstdomain www.nbc.com www.abc.com www.cbs.com
acl Fraggle method PUT POST

Элемент ACL с несколькими значениями соответствует запросу, если совпадает какое-либо одно из значений. При сравнении используется логика OR (ИЛИ). Элемент ACL с именем Argle соответствует запросу от 1.1.1.8, от 1.1.1.28 или от 1.1.1.88. Элемент ACL с именем Bargle соответствует запросам на веб-сайты NBC, ABC или CBS. Элемент ACL с именем Fraggle соответствует запросу с методами PUT или POST.
Теперь вы эксперт по элементам ACL, следующим шагом надо упорядочить правила ACL. Смысл их в том, чтобы вы могли сказать, принят запрос или отвергнут. Правила списка доступа ссылаются на элементы ACL по их именам и содержат ключевое слово либо разрешения, либо отказа. Вот несколько простых примеров:

http_access allow Foo
http_access deny Bar
http_access allow Baz

Важно понять, что правила списка доступа проверяются по порядку и что выбор делается, когда находится соответствие. Давайте по вышеприведенному списку посмотрим, что происходит, когда пользователь от 1.2.3.4 делает запрос GET на www.cnn.com. Squid проверяет первым правило доступа элемента Foo. Наш запрос соответствует элементу ACL с именем Foo, т.к. исходный адрес 1.2.3.4, и запрос принимается к исполнению. Остальные правила не проверяются.
А как насчет запроса PUT на www.cnn.com от 5.5.5.5? Этот запрос не соответствует первому правилу. Однако он не соответствует и второму правилу. Это правило списка доступа говорит о том, что запрос должен быть отвергнут, поэтому пользователь получает от Squid сообщение об ошибке.
Что можно сказать о запросе GET на www.cnn.com от 5.5.5.5? Этот запрос не соответствует первому правилу (доступ Foo). Он не соответствует и второму правилу, т.к. www.oreilly.com отличается от www.cnn.com. Но он не соответствует и третьему правилу, потому что метод запроса GET.
Эти простые правила ACL, конечно, не представляют большого интереса. Реальные возможности заключаются в том, что Squid может комбинировать в одном правиле несколько элементов. Если правило содержит несколько элементов, то чтобы оно начало действовать, каждый элемент должен иметь соответствие. Другими словами, для правил списка доступа Squid использует логику AND (И). Рассмотрим такой пример:

http_access allow Foo Bar
http_access deny Foo


Первое правило говорит, что запрос от 1.2.3.4 И на www.cnn.com будет принят. Однако второе правило говорит, что любой другой запрос от 1.2.3.4 будет отвергнут. Эти две строки ограничивают пользователя по адресу 1.2.3.4 посещением только сайта www.cnn.com. Ниже приведен более сложный пример:

http_access deny Argle Bargle Fraggle
http_access allow Argle Bargle
http_access deny Argle

Эти три строки разрешают клиентам Argle (1.1.1.8, 1.1.1.28 и 1.1.1.88) получить доступ к серверам Bargle (www.nbc.com, www.abc.com и www.cbs.com), но не методами PUT или POST. Более того, клиенты Argle не получают доступ к каким-либо другим серверам.
Одна из наиболее распространенных ошибок, которую совершают новички, заключается в составлении правила, которое никогда не будет истинным. Это легко сделать, если забыть, что Squid использует логику AND по правилам и логику OR по элементам. Ниже приведена конфигурация, которая никогда не будет истинной:

acl A 1.1.1.1
acl B 2.2.2.2
http_access allow A B

Причина заключается в том, что не может быть запроса одновременно от 1.1.1.1 и (AND) от 2.2.2.2. Более вероятно, что он должен быть записан как:

acl A 1.1.1.1 2.2.2.2
http_access allow A

Тогда запросы принимаются или от 1.1.1.1 или от 2.2.2.2.
Правила управления доступом могут стать длинными и сложными. Как вы можете знать при добавлении нового правила, где оно должно действовать? Вы должны отдавать предпочтение более конкретным правилам по отношению к менее конкретным. Помните, что правила проверяются по порядку. При добавлении правила мысленно переберите существующие, чтобы понять, где расположить новое правило. Например, допустим, вы хотите отвергнуть запросы на определенный сайт, но разрешить доступ всем другим запросам. Это должно выглядеть примерно так:

acl XXX www.badsite.net
acl All src 0/0
http_access deny XXX
http_access allow All

А если вам нужно сделать исключение для одного пользователя, так чтобы он мог посетить этот сайт? Новый элемент ACL выглядит так:

acl Admin 3.3.3.3

и новое правило должно иметь вид:

http_access allow Admin XXX

Но где оно действует? Поскольку это правило более конкретное, чем правило deny ХХХ, оно должно проверяться первым:

http_access allow Admin XXX
http_access deny XXX
http_access allow All

Если мы поместим новое правило после deny ХХХ, оно даже никогда проверяться не будет. Первое правило будет всегда соответствовать этому запросу, и пользователь не сможет посетить этот сайт.
Когда вы впервые инсталлируете Squid, правила управления доступом будут отвергать каждый запрос. Чтобы все заработало, вам нужно будет добавить элемент и правило ACL для вашей локальной сети. Самый легкий способ заключается в том, чтобы записать исходный IP-адрес элемента ACL для вашей подсети (или подсетей). Например:

acl MyNetwork src 192.168.0.0/24

Затем при помощи squid.conf ищите эту строку:

# INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS

После этой строки добавьте строку http_access по правилу allow:

http_access allow MyNetwork

Как только у вас заработает эта простая конфигурация, вы смело можете перейти к некоторым более продвинутым функциям ACL, таким как прокси-аутентификация на основе имени пользователя.

как не ретранслировать спам

Вам известно о существовании проблемы спама в Интернете, если только вы не закрываете на это глаза. Отправители спама пользуются открытыми ретрансляторами в системе электронной почты. Сегодня из открытых прокси приходит огромное количество спама. Открытый прокси — это такой прокси, который позволяет посторонним делать с его помощью запросы. Если другие пользователи в Интернете получают от вашего прокси электронную почту со спамом, то ваш IP-адрес будет размещен в одном или более различных черных списков. Это неблагоприятно скажется на возможности соединения с другими сайтами Интернета.
Чтобы быть уверенным в том, что подобное никогда с вами не случится, следуйте следующим правилам управления доступом. Во-первых, всегда отвергайте все запросы, которые приходят не из вашей локальной сети. Определите для вашей подсети элемент ACL:

acl MyNetwork src 10.0.0.0/16

Затем разместите запретительное правило где-то в начале ваших правил доступа http_access, которые соответствуют запросам откуда-либо еще:

http_access deny !MyNetwork
http_access ...
http_access ...

Наряду с тем, что такое запретительное правило может остановить посторонних, у него есть и недостатки. Оно не послужит препятствием для своих пользователей, которые намеренно или ненамеренно пытаются продвинуть спам через Squid. Чтобы повысить уровень безопасности, вы должны быть уверены, что Squid никогда не подсоединится к SMTP-порту другого сервера:

acl SMTP_port port 25
http_access deny SMTP_port

На самом деле, кроме SMTP-портов есть много других хорошо известных TCP-портов, с которыми Squid никогда не должна соединяться. По умолчанию squid.conf содержит некоторые правила по адресации. Там вы увидите элемент ACL Safe_ports, который определяет «хорошие» порты. Запретительное правило !Safe_ports гарантирует, что Squid не подсоединится ни к какому «плохому» порту, включая SMTP.

Duane Wessels, перевод Ларисы Семченко.
обсуждение статьи