DansGuardian. Настраиваем передачу IP-адреса клиента в Squid

Как показывает читательский отклик, существуют такие, простые на первый взгляд вопросы, которые тем не менее возникают снова и снова. Это свидетельствует о том, что данный момент остался не проработан и решение неочевидно определенной части читателей. Поэтому будет справедливо вернуться к таким вопросам и сделать дополнительные разъяснения. Сегодня мы решили окончательно внести ясность в вопрос о том, как "научить" контент-фильтр Dansguardian передавать прокси-серверу Squid IP-адрес клиента.

Онлайн-курс по устройству компьютерных сетей
На углубленном курсе "Архитектура современных компьютерных сетей" вы с нуля научитесь работать с Wireshark и «под микроскопом» изучите работу сетевых протоколов. На протяжении курса надо будет выполнить более пятидесяти лабораторных работ в Wireshark.

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

Также именно IP-адреса клиентов из логов Squid служат основой для построения статистики любыми анализаторами логов, например, SARG.

Все это прекрасно работает до тех пор, пока мы не установим контент-фильтр Dansguardian, после чего все завязанные на IP-адреса правила перестают работать, а статистика показывает одного единственного клиента с адресом 127.0.0.1. Чтобы понять, что случилось и почему так происходит, давайте рассмотрим следующую схему:

Согласно приведенной схемы клиенты с адресами из диапазона 192.168.31.101 - 192.168.31.199 обращаются к роутеру посылая ему HTTP-запросы и получая в ответ содержимое веб-страниц, при условии, что данное содержимое проходит все установленные администратором фильтры.

Теперь самое время вспомнить о спецификациях протокола HTTP, а именно то, что они не предусматривают передачи адреса клиента в заголовках запроса. Пока Squid был один, он самостоятельно фиксировал адреса обратившихся к нему клиентов, но с появлением в схеме Dansguardian ситуация изменилась.

Так как все клиентские запросы первым обрабатывает контент-фильтр, то именно он может фиксировать реальные адреса клиентов, что он собственно и делает, записывая их в лог. Находящийся за ним Squid получает все запросы от локального процесса (если Dansguardian находится с ним на одном физическом сервере) и не имеет никакой возможности определить истинный источник запроса, поэтому в логе окажется только один адрес - 127.0.0.1 и все основанные на IP-адресах правила перестанут работать.

К счастью разработчики протокола предусмотрели подобную ситуацию и ввели в протокол специальный заголовок X-Forwarded-For, который позволяет передавать в составе запроса адрес клиента. В нашем случае, для исправления ситуации следует настроить Dansguardian на добавление в запрос таких заголовков, а Squid на их обработку, причем сделать это действительно несложно.

В конфигурационном файле Dansguardian /etc/dansguardian/dansguardian.conf найдите и приведите к следующему виду опцию:

forwardedfor = on

Теперь откройте файл конфигурации Squid /etc/squid3/squid.conf и после секции с элементами ACL найдите и раскомментируйте:

follow_x_forwarded_for allow localhost

После чего Dansguardian начнет добавлять к запросам заголовки X-Forwarded-For, а Squid их обрабатывать.

Обратите внимание! Если вы используете старые версии Squid, младше 3.3, то убедитесь, что задан следующий элемент ACL - acl localhost src 127.0.0.1, начиная с версии 3.3 данный элемент является предопределенным и указывать его отдельно не требуется.

Для применения изменений перезапустим службы:

service dansguardian restart
service squid3 restart

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

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