10.8 Типичные ошибки

Логическое И/ИЛИ

Вы возможно уже заметили (и были разочарованы), что фактически вы не можете комбинировать контроли доступа при помощи конструкций ``и'', ``или.'' Эти операции уже встроены в схему контроля доступа, это одна из основополагающих вещей, которую вы должны усвоить.

• Все элементы, указанные в данном acl объединяются при помощи логического "ИЛИ".

• Все элементы, указанные в access объединяются при помощи логического "И". т.к. http_access and icp_access.

К примеру, следующая конфигурация контроля доступа никогда не будет работать:

acl ME src 10.0.0.1

acl YOU src 10.0.0.2

http_access allow ME YOU

Для того, чтобы запрос был разрешен, он должен совпасть и с acl ``ME'' И acl ``YOU''. Это невозможно, т.к. IP-адрес в данном случаю может совпасть либо с одним, либо с другим acl. Это должно быть заменено на:

acl ME src 10.0.0.1

acl YOU src 10.0.0.2

http_access allow ME

http_access allow YOU

Такая конструкция тоже должна работать:

acl US src 10.0.0.1 10.0.0.2

http_access allow US

перепутанные allow/deny

Я перечитал несколько раз мой squid.conf, поговорил с коллегами, почитал FAQ и документацию по Squid Docs и никак не могу понять, почему следующее не работает.

Я успешно подключаюсь к cachemgr.cgi с нашего web-сервера, но хотелось бы использовать MRTG для мониторинга различных параметров нашего прокси. Когда я пытаюсь использовать 'client' или GET cache_object с машины, на которой работает прокси, то всегда получаю "доступ запрещен".

acl manager proto cache_object

acl localhost src 127.0.0.1/255.255.255.255

acl server src 1.2.3.4/255.255.255.255

acl all src 0.0.0.0/0.0.0.0

acl ourhosts src 1.2.0.0/255.255.0.0

http_access deny manager !localhost !server

http_access allow ourhosts

http_access deny all

Приведенная здесь задача состоит в том, чтобы разрешить запросы кеш-менеджера с адресов localhost и server и запретить все остальные. Такая политика описывалась правилом:

http_access deny manager !localhost !server

Проблема состоит в разрешении запроса, правило доступа не срабатывает. К примеру, если IP-адрес источника localhost, тогда ``!localhost'' - ложь и правило доступа не срабатывает, Squid продолжает проверять другие правила. Запросы к кеш-менеджеру с адреса server работают, т.к. server находится в подсети ourhosts, сработает второе правило и запрос будет разрешен. Это значит также, что любой запрос кеш-менеджера из ourhosts будет разрешен.

Чтобы необходимая политика работала корректно, правила доступа должны быть переписаны следующм образом

http_access allow manager localhost

http_access allow manager server

http_access deny manager

http_access allow ourhosts

http_access deny all

Если вы используете miss_access, не забывайте также добавить правило miss_access для кеш-менеджера:

miss_access allow manager

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

Различия между src и srcdomain типами ACL.

Для типа ACL srcdomain Squid делает обратное преобразование клиентского IP-адреса и проверяет соответствие результата домену, описанному в строке acl. Для типа ACL src Squid вначале преобразует имя хоста в IP-адрес и только потом сравнивает с клиентским IP. Тип ACL src предпочтительнее, чем srcdomain, т.к. он не требует преобразования адреса в имя при каждом запросе.