Понадобилось мне недавно поставить прозрачный прокси-сервер в одной конторе. Выход в интернет там организован через роутер ASUS WL-550g, на котором стояла альтернативная прошивка.
Для тех кто не в теме, поясню, что прозрачный прокси отличается от обычного в первую очередь тем, что в броузерах на клиентских машинах не нужно явно прописывать настройки прокси-сервера. Прозрачный прокси просто перехватывает идущий HTTP-трафик и дальше уже предпринимает с ним разные действия. У пользователя при этом создается ощущение, что он работает в интернете без прокси-сервера.
Вобщем для выполнения этой задачи я установил Debian на отдельный ПК, затем поставил туда проси Squid, Apache и Lightsquid для просмотра статистики. После этого встал вопрос каким образом завернуть весь трафик 80-го TCP порта на комп прокси-сервера.
Самое просто что пришло в голову это прописать на шлюзе что-то типа:
iptables -t nat -A PREROUTING -s localnetwork
-p tcp -dport 80 -j DNAT -to-destination proxy-server-ip:port
Заработало… Весь трафик реально стал заворачиваться на прокси-сервер, вот только в отображаемой Лайтсквиде статистике получился небольшой казус. Все запросы в интернет отправленные с компьтеров сети в статистике стали отображаться как запросы, отправленные непосредственно с локального IP-адреса маршрутизатора. Почему так произошло, ведь DNAT меняет в IP-пакете только адрес назначения? Все очень просто. Общее правило, по которому вся сеть выходила в интернет никуда не делось, а там у нас было прописано примерно вот что:
iptables -t nat -A POSTROUTING -s localnetwork
-j MASQUERADE
На деле получалось так, что в цепочке PREROUTING у нас менялся адрес назначения, а затем, в цепочке POSTROUTING еще и адрес отправителя.
Делаем правильно!
Порывшись в интернете я набрел на доку, в которой написано как наиболее правильно делать перенаправление на прозрачный прокси.
Итак, сначала пишется правило, которое пропускат без изменений весь трафик идущий от прокси-сервера в интернет:
iptables -t mangle -A PREROUTING -j ACCEPT -p tcp -dport 80 -s proxy-server-ip
Трафик идущий в интернет от других компьютеров локальной сети мы маркируем:
iptables -t mangle -A PREROUTING -j MARK -set-mark 3 -p tcp -dport 80
Затем мы создаем правило маршрутизации - весь промаркированный трафик засовываем в новую таблицу 2:
ip rule add fwmark 3 table 2
После этого прописсываем маршрут дл таблицы 2:
ip route add default via proxy-server-ip
dev router-lan-interface
table 2
После этих шагов весь трафик будет заворачиваться на проски-сервер на момент принятия решения о маршрутизации, т.е. не доходя до цепочки POSTROUTING.
Но тут есть один маленький ньюанс, весь трафик с компьютеров локальной сети будет приходить на прокси-сервер на 80й порт, поэтому Squid нужно настраивать на 80-м порту либо делать REDIRECT с 80-го на какой-нибудь 3128. Правило на прокси-сервере будет выглядить примерно таким образом:
iptables -A PREROUTING -t nat -i eth0 -p tcp -dport 80 -j REDIRECT -to-port 3128
Так как 80й порт на прокси-сервере у нас будет в любом случае занят не зависимо от того повесим мы на него Squid или будем делать редирект, не забудте Apache привязать к другому порту, т.к. по умолчанию он тоже висит на TCP 80.
В данной статье приводится пример быстрой настройки кэширующего прокси сервера Squid в Linux Debian 6. Результатом настройки станет возможность выхода в Интернет через данный сервер по протоколам: http, https и ftp.
Сразу оговорюсь, что полученный сервер не является сетевым фильтром и потенциально уязвим для сетевых атак.
Настройка сервера осуществляется на базе ОС Linux Debian 6. Все приводимые ниже команды должны выполняться с правами суперпользователя (root).
Сразу важное предупреждение: авторизация и прозрачный прокси несовместимы! Придется выбирать что-то одно. Второе предупреждение: авторизация через прокси позволит ограничить доступ в Интернет только по HTTP протоколу. Остальные протоколы: FTP, SMTP, POP3 и другие будут спокойно продолжать работать через NAT. Хотя в небольших организациях это не столь критично, наиболее употребляемым (и злоупотребляемым) является именно протокол HTTP, и одной из задач администратора является ограничение доступа сотрудников в интернет именно через браузер.
Если Вы пользуетесь Apteture с загрузкой пакетов из сети, рекомендую перед установкой обновить списки актуальных пакетов:
# apt-get update
Запускаем установку Squid:
# apt-get install squid3
После окончания установки, начинаем редактировать файл конфигурации сквида. Не знаю как вам, лично мне удобнее когда в файле конфига нет ничего лишнего, то есть присутствуют только непосредственно параметры конфигурации. Для этого бекапнем оригинальную конфигурацию сквида (чтоб было где искать описания всех параметров):
cp /etc/squid/squid.conf /etc/squid/squid.conf.original
и выжмем из оригинальной конфигурации всё, не закоментированное:
cat /etc/squid/squid.conf.original | grep -v "^\(#\|$\)" > /etc/squid/squid.conf
В итоге заимеем дефолтный конфигчик без ничего нишнего. Но всё же очень советую кинуть взор в оригинальный конфиг и почитать его на досуге - там очень много интересного!
Ну, наконец, приступим к редактированию:
nano /etc/squid/squid.conf
После установки, требуется небольшая настройка. Открываем в редакторе конфигурационный файл Squid, который должен располагаться в /etc/squid/squid.conf. В этом файле находим строки:
Acl localnet src 10.0.0.0/8
acl localnet src 172.16.0.0/12
acl localnet src 192.168.0.0/16
Эти строки необходимо закоментировать. И добавить свою строку с параметрами собственной локальной сети. Должно получиться так:
# acl localnet src 10.0.0.0/8
# acl localnet src 172.16.0.0/12
# acl localnet src 192.168.0.0/16
acl localnet src 192.168.1.0/24 # Собственная локальная сеть
В последней строке вместо 192.168.1.0/24 нужно подставить параметры Вашей сети.
Чуть ниже комментария # TAG: http_access необходимо найти строку:
Http_access allow localhost
или
http_access allow manager localhost
Сразу после этой строки добавляем строку:
Http_access allow localnet
cache_dir ufs /var/cache/squid 2048 16 256
mkdir -p /var/cache/squid
chmod 755 -R /var/cache/squid
Разрешая тем самым доступ в сеть всем компьютерам из локальной сети. После этого сохраняем файл squid.conf и перезапускаем Squid сервер:
# /etc/init.d/squid restart
Если после рестарта squidа у вас вылезет ошибка (WARNING cache_mem is larger than total disk cache space!) просто уменьшите значение параметра cache_mem 8 MB я поставил 32
Если Вы с конфигурационный файл внесли изменения из ошибок, то Squid должен успешно перезагрузиться. При возникновении ошибки можно узнать из-за чего она произошла в Log-файле: /var/log/squid/cache.log
Настройка обозревателя на работу через Proxy-сервер
В данном варианте настройки наш сервер не может автоматически маршрутизировать сетевые запросы на порт прокси сервера. Поэтому обозревателям нужно указывать явно адрес нашего сервера.
Важно, чтобы прокси сервер в локальной сети имел фиксированный IP-адрес. Предположим, что у Вас это 192.168.1.1. Например для настройки Internet Explorer требуется открыть Сервис-Свойства обозревателя-Подключения-Настройка сети. В открывшемся окне поставить галочку в поле Использовать прокси-сервер для локальных подключений. Поставить галочку на Не использовать прокси-сервер для локальных адресов. В поле Адрес ввести IP-адрес нашего прокси сервера: 192.168.1.1. В поле Порт ввести порт, применяемый Squid по-умолчанию: 3128.
После этих настроек Ваш обозреватель будет выходить в сеть через наш новый прокси-сервер. В других обозревателях настройка аналогичная приведенной выше для Microsoft Internet Explorer.
Порт прокси-сервера можно поменять по своему усмотрению в файле /etc/squid/squid.conf. Он задан в строке:
http_port 3128 transparent
Заключение
Установка и настройка кэширующего прокси сервера на базе Squid это всего лишь первый этап в создании производительного шлюза в Интернет. Чуть позже я расскажу как настроить «Прозрачный прокси сервер», Firewall и как можно вести статистику посещений пользователями сайтов пользователями локальной сети.
Очень важно правильно настроить iptables. Второй вариант чуть ниже, мне он больше по душе
На этом шаге я предлагаю Вам создать скрипт настройки, так как он пригодится как универсальное средство.1 # vim ./setiptables.sh
#!/bin/bash
LAN=$1
WAN=$2
IP=$3
GW=$4
iptables -t nat -A PREROUTING -i $LAN -p tcp --dport 80 -j DNAT --to $IP:3128
iptables -t nat -A PREROUTING -i $WAN -p tcp --dport 80 -j REDIRECT --to-port 3128
iptables -t nat -A POSTROUTING -j MASQUERADE
iptables -A FORWARD -i $WAN -o $LAN -s $GW/24 -p tcp -m multiport --dport 443,21,22 -j ACCEPT
echo "net.ipv4.ip_forward = 1" > /etc/sysctl.conf
sysctl -w net.ipv4.ip_forward=1
Мы обозначили переменные (для удобства), 3 правила для таблицы NAT и 1 для FORWARD.
Порты 443,21,22 пускаем в обход прокси сервера.
Помимо настроек iptables, в этом скрипте, мы включаем форвардинг пакетов.
Запускаем так:1
# sh ./setiptables.sh eth0 eth1 192.168.100.1 192.168.100.0
6) Настроим автозагрузку натсроек iptables.
Сохраням настройки iptables.
# mkdir -p /usr/local/iptables && iptables-save > /usr/local/iptables/session.ipt
Добавляем команду авотзапуска в /etc/rc.local (мне нравится Perl но тут кому как).
# perl -i -pe "print "iptables-restore < /usr/local/iptables/session.ipt\n" if $. == 2" /etc/rc.local
Также не забываем про форвардинг пакетов
# perl -i -pe "print "sysctl -w net.ipv4.ip_forward=1\n" if $. == 3" /etc/rc.local
Второй вариант настройки firewall iptables
Включим в системе форвардинг. В файле /etc/sysctl.conf раскомментируем строчку
net.ipv4.ip_forward=1
Итак, на текущий момент мы имеем полностью сброшенные настройки файрвола (iptables).
Сбрасываем цепочки:
$ sudo iptables -F
$ sudo iptables -F -t nat
Запрещаем все входящие и разрешаем все исходящие и форвардинг:
sudo iptables -P INPUT DROP
sudo iptables -P OUTPUT ACCEPT
sudo iptables -P FORWARD ACCEPT
Разрешаем принимать ответ на УЖЕ установленный соединени:
sudo iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
Разрешаем loopback-трафик:
sudo iptables -A INPUT -i lo -j ACCEPT
Разрешаем весь трафик с нашей внутренней сети (возьмем подсеть 222):
sudo iptables -A INPUT -s 192.168.222.0/24 -i eth1 -j ACCEPT
И, залог прозрачности! Перенапрявляем весь исходящий http-трафик (на порт 80) на порт сквида 3128:
iptables -t nat -A PREROUTING -s 192.168.222.0/24 -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 3128
iptables -t nat -A POSTROUTING -s 192.168.222.0/24 -o eth0 -j SNAT --to-source 192.168.56.39
Проверяем на клиенте интернет. Напомню, что если прокси указывать не обязательно, шлюз выставить необходимо!
Однако, после первой же перезагрузки, мы поймем, что все наши старания ушли впустую.
Научим же их выживанию!
Итак, сохраним всё то, чем мы тут занимались:
iptables-save > /etc/firewall.conf
У меня с судо этот финт не получился (хотя в теории вроде должен…), потому можно сделать влогинившись в рута полностью (su) и запустив команду, но без sudo.
А теперь создадим скрипт, заставляющий ifupdown воскрешать наш файрвол:
nano /etc/network/if-up.d/00-iptables
Впишем в него следующее:
#!/bin/sh
iptables-restore < /etc/firewall.conf
Выставим права на исполнение:
chmod +x /etc/network/if-up.d/00-iptables
В целом настройка прозрачного прокси сервера закончена, но чтобы логи были читаемы, нам наобходимо отключить поддержку ipv6 (из за того что ipv6 у нас не настроен на адаптере будет много warnings).
Отключаем IPv6 если кто не использует
Предлагаю опять же сделать скрипт чтобы не запутаться.
nano ./ipv6disable.sh
#!/bin/bash
perl -i -pe "print "alias net-pf-10 ipv6 off\n" if $. == 17" /etc/modprobe.d/aliases.conf
perl -i -pe "print "alias net-pf-10 off\n" if $. == 18" /etc/modprobe.d/aliases.conf
perl -i -pe "print "alias ipv6 off\n" if $. == 19" /etc/modprobe.d/aliases.conf
echo 1 | tee /proc/sys/net/ipv6/conf/all/disable_ipv6
echo "blacklist ipv6" | tee -a /etc/modprobe.d/blacklist.conf
STR=$(cat /boot/grub/grub.cfg | sed -n "67p")
STR=${STR}" ipv6.disable=1"
sed "67d" /boot/grub/grub.cfg > /boot/grub/grub.cfg.backup
cp /boot/grub/grub.cfg.backup /boot/grub/grub.cfg
sed -i 67i\ "$STR" /boot/grub/grub.cfg
В общих чертах что в этом скриптике происходит:
Сперва отключаем пожжержку ipv6 в модулях ядра.
Далее указываем маркер в /proc на не использование ipv6.
И в 67 строке /boot/grub/grub.cfg дописываем параметр ipv6.disable=1.
Такая канитель с tee и sed нужна для того чтобы сохранить настройки /boot/grub/grub.cfg, так как там устройства обозначаются не по /dev/sd* и по UUID.
Хотя все всегда можно дописать ручками.
Теперь нам надо прикрутить squidguard
Итак, половина работы уже сделана, теперь осталось установить пакет SquidGuard и настроить его. Для установки пишем в терминале из под пользователя root (права root в Debian GNU/Linux можно получить командой su, в Ubuntu перед командами пишем sudo):
apt-get install squidguard
После установки скачаем черные списки blacklists комадной wget из терминала (внимание, размер файла 24 Мб!):
wget -c my_blacklists.tar.gz
И распакуем его в каталог, где должны распологаться базы SquidGuard (необходимы права администратора):
tar zxvf my_blacklists.tar.gz -C /var/lib/squidguard/db
В результате распаковки появится каталог /var/lib/squidguard/db/my, содержащий множество подкаталогов разных категорий со списками доменов и адресов нежелательных сайтов. Этот список был составлен нами на основе трёх чёрных списков, загруженных с сайтов http://www.squidguard.org , http://www.shallalist.de и http://www.urlblacklist.com . В результате наш список содержит более 3-х миллионов сайтов.
Теперь необходимо настроить связку Squid и SquidGuard и подключить к ним чёрные списки. Для этого в файл squid.conf дописываем следующие строки, открыв файл в редакторе nano с правами администратора:
nano /etc/squid/squid.conf
Добавляем строки в конец файла:
Redirector_bypass on
redirect_program /usr/bin/squidGuard
redirect_children 1
mv /etc/squid/squidGuard.conf /etc/squid/squidGuard.conf_original
Скачиваем файл конфигурации squidGuard.conf с нашего сайта командой wget в терминале:
wget -c squidGuard.conf
Копируем его на место старого файла (с правами администратора):
cp squidGuard.conf /etc/squid/squidGuard.conf
После копирования файла конфигурации инициируем конвертирование текстовых чёрных списков, которые вы скачали и распаковали, в формат баз данных Berkeley DB (команда будет выполняться некоторое время - нужно дождаться полного окончания), выполнив команду от администратора:
squidGuard -d -C all
Если всё сделано правильно, то после команды в терминале будет выдаваться множество сообщений о создании новых файлов баз, и в конце их череды вы увидите что-то подобное:
2012-03-16 12:51:53 squidGuard 1.4 started (1331887787.768)
2012-03-16 12:51:53 db update done
2012-03-16 12:51:53 squidGuard stopped (1331887913.657)
Что скажет об успешном завершении создании баз черных списков. Далее задаём права сервера Squid на файлы баз, выполнив команду с правами администратора:
chown -R proxy:proxy /var/lib/squidguard/db/
И рестартуем сервер Squid выполнив в Debian от root:
/etc/init.d/squid3 restart
После рестарта в результате совместной работы Squid и SquidGuard будет работать перенаправление с нежелательных сайтов на сайт . Вместо неё вы можете поставить любую другую страничку, изменив адрес последней строки файла конфигурации /etc/squid/squidGuard.conf.
Изменение записей в списках доменов и URL
Пример. Рядом с файлом domains.db в папке /var/lib/squiguard/db/направление создаём файл domains.diff. В него заносим строку или несколько строк, по одной на каждую запись:
Сайт (что означает вычеркнуть этот домен из базы)
или +sysadmin
-komi.ru (что означает добавить этот домен в базу)
Даём команды:
(обновить базы db из файлов diff. В логах squidguard"а можно посмотреть сколько добавилось/убылось.)
$ squid3 -k reconfigure
(перечитать настройки без перезапуска.)
Файл domains.diff удалять, или стирать из него записи, не надо. При глобальном обновлении баз этот файл ещё пригодится. И при многократном обновлении не происходит дублирования записей в БД.
Вы можете создавать свои правила редиректов, добавляя или исключая категории нежелательных сайтов. К сожалению, стопроцентной защиты невозможно получить, т.к. новые сайты с нежелательным содержанием появляются постоянно. Даже если и постоянно обновлять списки blacklists. Если вам требуется сильная защита, то SquidGuard можно настроить на работу с белым списком разрешенных сайтов, запретив всё остальное - но тогда будет совсем ограниченный набор сайтов.
И остался один момент! Поставим статистику кто что куда и почему, по имени sarg
apt-get install sarg
Она потянет за собой целую братию пакетов, и немудрено, ибо для показа результатов ему необходим веб-сервер.
Подгоняем конфигурацию (/etc/squid/sarg.conf) под себя. Вот главные строчки, на которые следует обратить внимание:
Access_log /var/log/squid/access.log
...
output_dir /var/www/squid-reports
...
charset UTF-8
Создаем последний каталог, ежели его нет.
Запускаем сарж (неплохо б было его запуск пихануть в крон, здесь я не буду это описывать… пока что)
Ура! Заходим изнутри сети на наш сервер, любуемся отчетами по адресу http://IP_SERVER/squid-reports/
Все ребята готово. Будут вопросы спрашивайте, помогу чем смогу.
Squid — это мощный пакет, реализующий проксирование проходящих через него запросов, имеет огромный набор возможностей. В локальной сети чаще всего его используют как прозрачный кэширующий прокси. Настроим по порядку 3 основные возможности squid.
1. Для начал устанавливаем squid (для Debian 6)
Apt-get install squid3
2. Файл с настройка squid.conf лежит в /etc/squid3/. Содержит он около 5,5 тысяч строк. Но не все так страшно, основная масса этого файла — это подробные комментарии к настройкам. Как удобнее внести изменения в файл выбирать Вам. Можно избавиться от всего лишнего в файле таким способом
# переходим в папку squid cd /etc/squid3 # делаем резервную копию файла с настройками cp squid.conf squid.conf_backup # получаем из squid.conf_backup чистый файл с настройками без комментариев в squid.conf cat squid.conf_backup | egrep -v "^#|^$" > squid.conf
и получить «голый» файл с настройка, следующего содеражания
Acl manager proto cache_object acl localhost src 127.0.0.1/32::1 acl to_localhost dst 127.0.0.0/8 0.0.0.0/32::1 acl SSL_ports port 443 acl Safe_ports port 80 # http acl Safe_ports port 21 # ftp acl Safe_ports port 443 # https acl Safe_ports port 70 # gopher acl Safe_ports port 210 # wais acl Safe_ports port 1025-65535 # unregistered ports acl Safe_ports port 280 # http-mgmt acl Safe_ports port 488 # gss-http acl Safe_ports port 591 # filemaker acl Safe_ports port 777 # multiling http acl CONNECT method CONNECT http_access allow manager localhost http_access deny manager http_access deny !Safe_ports http_access deny CONNECT !SSL_ports http_access allow localhost http_access deny all http_port 3128 hierarchy_stoplist cgi-bin ? coredump_dir /var/spool/squid3 refresh_pattern ^ftp: 1440 20% 10080 refresh_pattern ^gopher: 1440 0% 1440 refresh_pattern -i (/cgi-bin/|\?) 0 0% 0 refresh_pattern . 0 20% 4320
Останется внести лишь необходимые изменения в строках. Второй вариант — это редактировать весь файл без его чистки. Что тоже довольно просто если уметь пользоваться поиском в редакторе vi. В этом случае у Вас в помощь останутся много полезных комментариев к настройкам.
Для поиска текста в редакторе vi нажимаем клавишу «/». Если Вы находитесь в режиме редактирования, нужно выйти из него для передачи команд редактору нажатием на «Esc». Получаем такую последовательность действий: «/» > «вводим поисковое слово» > «Enter».
Теперь редактируем файл, делаем основные настройки. Если нужных строк нет, то добавляем их или раскоментируем.
Vi /etc/squid3/squid.conf # Разрешаем доступ к прокси только из нашел сети acl localnet src 172.16.0.0/24 http_access allow localnet http_access allow localhost # По умолчанию порт работы прокси 3128 # Так как у нас прокси будет прозрачным - указываем это # а так же адрес интерфейса с портом на котором будет работать прокси # на этот же порт будут перенаправляться запросы в iptables http_port 172.16.0.1:3128 transparent
3. Обеспечиваем кэширование запросов
# Установка директории кэша и его настройка # ufs - способ кэширования файлов на диске # /var/spool/squid3 - папка кэша # 5000 - размер кэша в мегабайтах # 16 - количество папок 1 уровня в кэше # 256 - количество папок 2 уровня в кэше cache_dir ufs /var/spool/squid3 5000 16 256 # ограничим минимальный размер кэшируемого файла, чтобы облегчить работу жесткому диску # либо можно потерять весь смысл кэша, если он будет медленно работать minimum_object_size 2 KB # ограничиваем и максимальный размер maximum_object_size 61440 KB
4. Squid, сконфигурированный по умолчанию, добавляет к http-запросу несколько своих заголовков. При этом, в первых двух заголовках передается клиентский ip (или даже несколько ip, в случае цепочки прокси). Если нам это ни к чему, ну например, не хотим светить внутренние ip своей локалки, то сделать squid анонимным очень просто
Via off forwarded_for delete
После завершения всех настроек, стоит проверить анонимность запросов на страничке http://checker.samair.ru Если все сделано правильно, то результатом будет надпись «Resume: You are using high-anonymous (elite) proxy».
На этом внесение изменений в файл закончены. В конечном итоге squid.conf должен выглядеть так
Acl manager proto cache_object acl localhost src 127.0.0.1/32::1 acl to_localhost dst 127.0.0.0/8 0.0.0.0/32::1 acl localnet src 172.16.0.0/24 # RFC1918 possible internal network acl SSL_ports port 443 acl Safe_ports port 80 # http acl Safe_ports port 21 # ftp acl Safe_ports port 443 # https acl Safe_ports port 70 # gopher acl Safe_ports port 210 # wais acl Safe_ports port 1025-65535 # unregistered ports acl Safe_ports port 280 # http-mgmt acl Safe_ports port 488 # gss-http acl Safe_ports port 591 # filemaker acl Safe_ports port 777 # multiling http acl CONNECT method CONNECT http_access allow manager localhost http_access deny manager http_access deny !Safe_ports http_access deny CONNECT !SSL_ports http_access allow localnet http_access allow localhost http_access deny all http_port 172.16.0.1:3128 transparent hierarchy_stoplist cgi-bin ? cache_dir ufs /var/spool/squid3 5000 16 256 minimum_object_size 2 KB maximum_object_size 61440 KB coredump_dir /var/spool/squid3 refresh_pattern ^ftp: 1440 20% 10080 refresh_pattern ^gopher: 1440 0% 1440 refresh_pattern -i (/cgi-bin/|\?) 0 0% 0 refresh_pattern . 0 20% 4320 via off forwarded_for delete
Для применения настроек останавливаем squid
Service squid3 stop
Подготавливаем директорию кэша squid
Squid3 -z
Запускаем прокси
Service squid3 start
Если Вы не делали изменения настроек связанных с кэшем прокси, то можно выполнить одну единственную команду. Настройки будут приняты автоматически без перезапуска squid.
Squid3 -k reconfigure
5. Остается лишь настроить прозрачность прокси. Это обеспечивает незаметную для пользователей локальной сети работу через прокси, т.е. нет необходимости настраивать пользователям программы для работы с прокси. Прозрачность обеспечивается простым перенаправлением http запросов с 80 порта на порт прокси сервера посредством фаервола iptables и включением режима прозрачного прокси в самом squid. Изменения в настройках squid мы сделали выше. Добавляем к правилам iptables еще одну строку:
Iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 3128
Обязательно в параметре указывайте нужный интерфейс на котором будет работать прокси: -i eth0. Это избавит Вас от проблем с доступом к web серверу из интернета при наличии более одного активного интерфейса, если таковой будет в будущем на этом сервере. А так же ради безопасности прокси.
Доброго времени, уважаемые читатели и гости! С данной статьи я начну описание работы кэширующего прокси-сервера SQUID . Эта статья в большинстве своем будет вводная теоретическая.
Что такое proxy-сервер и что такое squid
Начну с основ. squid является кэширующим прокси сервером для HTTP, FTP и др. протоколов. Прокси сервер для HTTP - это программа, выполняющая HTTP-запросы от имени клиентской программы (будь то браузер или другой софт). Proxy может быть кэширующим или не кэширующим . Кэширующий, соответственно, сохраняет все запросы в какое-либо хранилище для более быстрой отдачи клиентам, а не кэширующий - просто транслирует HTTP, ftp или другие запросы. Ранее, кэширование трафика позволяло добиться довольно значительной экономии трафика, но в настроящее время с ростом скоростей интернета это немного утеряло актуальность. Прокси серверА можно выстраивать в иерархии для обработки запросов. При этом, прокси серверА взаимодействуют между собой по протоколу ICP .
Squid разработан и может работать на большинстве операционных систем (как unix, так и windows). Лицензируется под лицензией GNU GPL. Способен обрабатывать и кэшировать HTTP, FTP, gopher, SSL и WAIS (убрано в 2.6) запросы, а так же DNS. Наиболее частые запросы хранит в оперативной памяти. На текущий момент существуют 2 стабильные версии squid : 2.7 и 3.1 . С отличиями можно ознакомиться в ссылках в конце статьи. Все зависимости при установке из пакетов у них одинаковые. Конфигурационный файл версии 2 совместим с версией 3, но в 3 версии добавлены новые параметры. В статье я буду рассматривать версию squid3 . Стоит так же заметить, что если устанавливать squid3 , то он свои конфигурационные файлы будет держать в /etc/squid3 , а так же логи по умолчанию в squid3 лежат в каталоге /var/log/squid3/ , а не /var/log/squid/ , как "любят считать" многие анализаторы логов.
Кучу раз упомянуто слово "кэширование ". А что же это, собственно, такое - кэширование ? Это способ хранения запрошенных из Интернет объектов на сервере, находящемся ближе к запрашивающему компьютеру нежели исходный. Интернет-объект это файл, документ или ответ на обращение к какому-либо сервису предоставляемому в Интернет (например, FTP, HTTP, или gopher). Клиент запрашивает интернет-объект из кеша прокси-сервера; если объект ещё не кеширован, то прокси-сервер получает объект (либо от узла сети указанного по запрошенному адресу URL, либо от родительского или соседнего кеша) и доставляет его клиенту.
Режимы работы прокси-сервера Squid
Прокси-сервер Squid может работать в следующих трех основных режимах:
Прозрачный режим
В этом режиме HTTP соединение осуществляемое клиентами перенаправляется на прокси-сервер без их ведома или явной конфигурации. В этом режиме не требуется настройка клиентов. Недостатки данного способа : необходима конфигурация NAT и перенаправления трафика, аутентификация клиентов не работает, не перенаправляются FTP и HTTPS запросы.
Аутентифицирующий режим
Для работы в этом режиме клиенты должны быть настроены для работы с прокси-сервером (в настройках соединения должен быть прописан адрес прокси-сервера). Может выполняться аутентификация и авторизация клиентов через Kerberos, Ldap, NTLM, IP и Radius. Возможно построение взаимодействия с серверами Microsoft Active Directory путем аутентификации клиентов – членов домена, используя протокол Kerberos, и последующей авторизации членов групп домена используя LDAP в прозрачном режиме (пользователь вводит свой пароль только при регистрации в домене). Для авторизированных групп возможно применение различных настроек контроля доступа и QoS (delay pools).
Обратный прокси-сервер
Прокси-сервер кэширует исходящие данные. Обратный прокси-сервер Squid получает данные у HTTP сервера от имени клиента и передает их обратно клиенту (например, в Интернет). Этот режим позволяет осуществить:
- Использование кэширования, которое снижает нагрузку на HTTP сервера;
- Распределение нагрузки между HTTP серверами;
- Маскировку HTTP серверов и их характеристик;
- Предотвращение web атак на сервера.
Схемы режимов работы SQUID
|
transparent режим |
обратный режим |
режим аутентификации |
На приведенных схемах зелеными стрелками обозначены потоки проксируемого трафика. Движение данных потоков в Linux чаще всего регулируется силами и настройками браузера. Кроме того, очень часто, функции маршрутизатора и прокси выполняет одна машина.
Установка SQUID
Перед установкой и настройкой squid необходимо и убедиться, что машина, на которой будет работать squid имеет доступ во внешнюю сеть и клиенты, которые будут использовать данный прокси имеют доступ к данной машине. Установка прокси-сервера squid как и другого ПО в Linux возможна различными способами, описанными в статье . Я затрону способ установки из репозитория в Debian. Итак, для установки squid необходимо установить пакет squid3, для этого выполнить вот такую команду:
Gw ~ # aptitude install squid3 Следующие НОВЫЕ пакеты будут установлены: libltdl7{a} squid-langpack{a} squid3 squid3-common{a} 0 пакетов обновлено, 4 установлено новых, 0 пакетов отмечено для удаления, и 0 пакетов не обновлено. Необходимо получить 2 157 kB архивов. После распаковки 10,3 MB будет занято. Хотите продолжить? y Получить:1 http://ftp.ru.debian.org/debian/ squeeze/main libltdl7 i386 2.2.6b-2 Получить:2 http://ftp.ru.debian.org/debian/ squeeze/main squid-langpack all 20100628-1 Получить:3 http://ftp.ru.debian.org/debian/ squeeze/main squid3-common all 3.1.6-1.2+squeeze2 Получить:4 http://ftp.ru.debian.org/debian/ squeeze/main squid3 i386 3.1.6-1.2+squeeze2 Получено 2 157 kБ в 9с (238 kБ/с) Выбор ранее не выбранного пакета libltdl7. (Чтение базы данных... на данный момент установлено 41133 файла и каталога.) Распаковывается пакет libltdl7 (из файла.../libltdl7_2.2.6b-2_i386.deb)... Выбор ранее не выбранного пакета squid-langpack. Распаковывается пакет squid-langpack (из файла.../squid-langpack_20100628-1_all.deb)... Выбор ранее не выбранного пакета squid3-common. Распаковывается пакет squid3-common (из файла.../squid3-common_3.1.6-1.2+squeeze2_all.deb)... Выбор ранее не выбранного пакета squid3. Распаковывается пакет squid3 (из файла.../squid3_3.1.6-1.2+squeeze2_i386.deb)... Обрабатываются триггеры для man-db ... Настраивается пакет libltdl7 (2.2.6b-2) ... Настраивается пакет squid-langpack (20100628-1) ... Настраивается пакет squid3-common (3.1.6-1.2+squeeze2) ... Настраивается пакет squid3 (3.1.6-1.2+squeeze2) ... Creating Squid HTTP proxy 3.x spool directory structure 2012/02/15 21:29:41| Creating Swap Directories Restarting Squid HTTP Proxy 3.x: squid3Creating Squid HTTP Proxy 3.x cache structure ... (warning). 2012/02/15 21:29:43| Creating Swap Directories .
Как видно, при установке пакета, была попытка создания каталога кэша , но т.к. он не настроен, то вывалилось предупреждение. Так же, squid добавлен в автозагрузку, запущен и принимает подключения на всех интерфейсах . Но т.к. он не настроен, доступ к интернет-страницам через сервер ограничен. Конфиг сквида расположен в /etc/squid3/squid.conf и состоит из более чем 5,5 тысяч строк и синтаксис его практически не отличается от конфига любого другого сервиса. Бросаться менять какие-то настройки срезу - не стоит. Потом не разгребете. Давайте рассмотрим конфиг, который нам предлагается по умолчанию без комментариев и пустых строк:
Gw ~ # grep -v ^# /etc/squid3/squid.conf | grep -v ^$ acl manager proto cache_object acl localhost src 127.0.0.1/32::1 acl to_localhost dst 127.0.0.0/8 0.0.0.0/32::1 acl SSL_ports port 443 acl Safe_ports port 80 # http acl Safe_ports port 21 # ftp acl Safe_ports port 443 # https acl Safe_ports port 70 # gopher acl Safe_ports port 210 # wais acl Safe_ports port 1025-65535 # unregistered ports acl Safe_ports port 280 # http-mgmt acl Safe_ports port 488 # gss-http acl Safe_ports port 591 # filemaker acl Safe_ports port 777 # multiling http acl CONNECT method CONNECT http_access allow manager localhost http_access deny manager http_access deny !Safe_ports http_access deny CONNECT !SSL_ports http_access allow localhost http_access deny all http_port 3128 hierarchy_stoplist cgi-bin ? coredump_dir /var/spool/squid3 refresh_pattern ^ftp: 1440 20% 10080 refresh_pattern ^gopher: 1440 0% 1440 refresh_pattern -i (/cgi-bin/|\?) 0 0% 0 refresh_pattern . 0 20% 4320
Как видно, в конфигурации по умолчанию, прокси-сервер работает и разрешает обращения только с адресов 127.0.0.0/8. Следует внимательно просмотреть весь список и закомментировать строки с портами не нужных или не используемых сервисов. Более полное понимание данного конфига будет после прочтения следующих разделов. Т.о. если мы запустим консольный браузер lunx с указанием на наш прокси, то сможем увидеть заданную страницу:
Gw ~ # # запускаем бреузер с указанием страницы ya.ru: gw ~ # http_proxy=http://127.0.0.1:3128 lynx ya.ru Идет поиск "ya.ru" сначала gw ~ # # в логе видим обращение к заданной странице: gw ~ # cat /var/log/squid3/access.log 1329527823.407 110 127.0.0.1 TCP_MISS/200 9125 GET http://ya.ru/ - DIRECT/93.158.134.203 text/html
Некоторыепараметры в конфигурационом файле squid могут применяться несколько раз (например acl). Некоторые параметры, особенно имеющие одно значение могут использоваться только один раз. При этом, при использовании такого параметра 2 и более раз - будет использовано последнее значение. Например:
Logfile_rotate 10 # Несколько значений - кончное будет равно 5 logfile_rotate 5
Управление squid
Параметры, с которыми был собран squid Вашего дистрибутива можно посмотреть командой squid3 -v. Например, в Debian squeezу squid собран с параметрами, приведенными ниже:
Prefix=/usr - префикс для других ключей: --mandir=${prefix}/share/man - каталог хранения man-страниц --libexecdir=${prefix}/lib/squid3 - каталог с исполняемыми модулями (в том числе и хелперы) --sysconfdir=/etc/squid3 - каталог хранения конфигурации --with-logdir=/var/log/squid3 - каталог хранения журналов и мн. др...
Настройка squid
Описание настроек squid3 начну с основных настроек , которые желательно произвести при настройке любой конфигурации прокси-сервера. Конфиг сквида расположен в /etc/squid3/squid.conf , это основной конфигурационный файл, в котором содержатся все настройки. (В дистрибутивах Debian и RedHat так же при запуске просматриваются параметры из стартовых файлов настроек /etc/default/squid3 и /etc/sysconfig/squid3 , соответственно). Так же, я упоминал, что там более 5 тысяч строк и что сразу рваться настраивать что-то не разобравшись - не стоит. Синтаксис конфига squid3 классический: строки с # - это комментарии, параметры представляют собой строки "параметр значение ", возможно использование . Конфигурационный файл разбит на разделы для удобства, но важно помнить, что разбор параметров производится "сверху вниз" в порядке очередности. Так же, с помощью параметра include можно подключать внешние конфигурационные файлы.
По умолчанию разрешение имени узла, на котором работает Squid, происходит при помощи gethostname(), в зависимости от установок DNS, он иногда не может однозначно определить имя, которое будет фигурировать в журналах и выводах об ошибках “Generated … by server.com (squid/3.0.STABLE2) ”. Для корректной записи имени хоста, необходимо это имя (FQDN??) занести в параметр:
Visible_hostname myproxy
По умолчанию, squid принимает подключения на всех интерфейсах. Если у нас сервер одним из сетевых интерфейсов смотрит во внешний мир, то желательно ограничить подключения только на интерфейсе локальной сети (допустим, 10.0.0.10/24). За это отвечает параметр http_port :
Http_port 10.0.0.10:3128
Как работают данные параметры можно увидеть в следующем листинге:
Gw ~ # # проверяем работу демона до настройки: gw ~ # netstat -antp | grep squ tcp 0 0 0.0.0.0:3128 0.0.0.0:* LISTEN 25816/(squid) gw ~ # # внесенные изменения: gw ~ # grep ^http_port /etc/squid3/squid.conf http_port 10.0.0.10:3128 gw ~ # # перечитываем измененный конфиг gw ~ # /etc/init.d/squid3 reload Reloading Squid HTTP Proxy 3.x configuration files. done. gw ~ # # проверяем работу с измененным конфигом: gw ~ # netstat -antp | grep squ tcp 0 0 10.0.0.10:3128 0.0.0.0:* LISTEN 25816/(squid)
Как видно, теперь демон работает только на интерфейсе заданной сети. Стоит так же отметить, что новые версии squid (<3.1) поддерживают задание нескольких параметров http_port. При этом, у разных параметров могут быть указанны дополнительные ключи такие как intercept, tproxy, accel и др., например:
Gw ~ # grep ^http_port /etc/squid3/squid.conf http_port 10.0.0.10:3128 http_port 10.0.0.10:3129 tproxy
Данные параметры задают режи работы прокси-сервера. Например tproxy (старый синтаксис - transparent) задает режим . Данные режимы достойны отдельных статей и в будущем возможно будет рассмотрены.
Теперь необходимо настроить клиентский компьютер и пользоваться интернетом. Но по умолчанию, доступ разрешен только с локалхоста и при попытке доступа к веб пользователь получит ошибку "Доступ запрещен". В логе /var/log/squid3/access.log будет примерно такое сообщение:
1329649479.831 0 10.0.1.55 TCP_DENIED/403 3923 GET http://ya.ru/ - NONE/- text/html
Для того, чтобы клиенты локальной сети могли работать, необходимо настроить разрешения с помощью списков контроля доступа .
Настройка доступа squid
Фактически настройка доступа заключается в описании объекта доступа через параметр acl , а затем разрешении или запрете работы описанному объекту acl при помощи параметра “http_access” . Простейший формат данных настроек имеет следующий вид:
Acl имя_списка тип_отбора характеристики_типа_отбора
где acl - параметр описывающий список контроля доступа , имя которого задается значением имя_списка . Имя чувствительно к регистру букв. тип_отбора задает тип, которому будет соответствовать заданная далее характеристика_типа_отбора . Данная характеристика может принимать такие часто используемые значения, как src (от source) - источник запроса, dst - адрес назначения, arp - МАС-адрес, srcdomain и dstdomain - доменное имя источника и назначения соответственно, port - порт, proto - протокол, time - время и многие другие . Соответственно, значение характиристики_типа_отбора будут формироваться в зависимости от типа_отбора .
Можно указывать несколько строк acl с одинаковыми именами и типами_отбора, в таком случае, данные acl будут объеденены в один список с логической операцией ИЛИ. Например:
Acl site dstdomain site.com acl site dstdomain site.org # аналогичен записи: acl site dstdomain site.com site.org
Словами это звучит так: списку доступа с именем site принадлежат все запросы, отправленные на сайт site.com ИЛИ site.org. Кроме того, имена_спаска чувствительны к регистру, то есть acl site и acl Site это 2 разных списка доступа.
Когда списки доступа сформированы, при помощи параметра http_access разрешаем или запрещаем доступ указанному ACL. Общий формат вызова такой:
Http_access allow|deny [!]имя_списка
где, http_access - параметр задающий последующее правило разрешения (allow ) или запрещения (deny ) доступ, указанному далее имени_списка . При этом, необязательный восклицательный знак инвертирует значение имени списка. То есть при восклицательном знаке значение имени_списка будет звучать как все, кроме тех, кто в принадлежит данному списку . Кроме того, можно задавать несколько списков через пробел, тогда доступ будет разрешен при условии принадлежности ко всем заданным спискам. При этом, все разрешающие правила необходимо указывать до запрещающего ВСЁ правила:
Http_access deny all
Может возникнуть резонный вопрос: зачем задавать данное правило, если мы, например, разрешим доступ к сквиду только избранным acl? Ведь остальные, кто не попадают в данный acl итак "проходят мимо"... Все просто. По-умолчанию, squid использует разрешающее/запрещающее правило противоположное последнему. Например:
# у нас есть единственное разрешеющее правило для некоторого acl user: http_access allow user # если при доступе к squid, клиент не попал в этот acl, то к нему будет применено действие deny. # А если у нас есть два правила http_access allow user http_access deny user2 # и клиент не входит ни в acl user, ни в acl user2, то к нему применится allow. # То есть действие противоположное последнему http_access deny user2
Это, как говориться - основы основ. Давайте рассмотрим простой пример. Предположим, у нас есть 2 сети 10.0.1.0/24 и 10.0.0.0/24, а так же хост 10.0.4.1, которым необходимо разрешить доступ к интернету. Для разрешения доступа необходимо создать описание нового списка доступа в секции "ACCESS CONTROL" файла squid.conf:
Acl lan src 10.0.1.0/24 10.0.0.0/24 acl lan src 10.0.4.1
Для бОльшего удобства, можно задать эти правила в отдельном файле, указав путь к нему в место характеристики_типа_отбора . Вот:
Gw ~ # # создадим отдельный каталог для хранения списков доступа gw ~ # mkdir /etc/squid3/acls/ gw ~ # # занесем наши подсети и хосты в отдельный файл gw ~ # vim /etc/squid3/acls/lan.acl gw ~ # cat /etc/squid3/acls/lan.acl 10.0.1.0/24 10.0.0.0/24 10.0.4.1 gw ~ # # опишем созданный файл в конфиге (путь необходимо заключить в кавычки) gw ~ # grep lan.acl /etc/squid3/squid.conf acl lan src "/etc/squid3/acls/lan.acl"
Разрешим созданному списку доступа lan доступ в интернет и скажем сквиду перечитать конфигурационный файл:
Gw ~ # grep lan /etc/squid3/squid.conf | grep acce http_access allow lan gw ~ # service squid3 reload Reloading Squid HTTP Proxy 3.x configuration files. done.
Подводя маленький итог данному разделу, в двух словах можно сказать, что acl идентифицирует Web запрос, а http_access разрешает или запрещяет идентифицированный запрос. Теперь наши локальные клиенты с радостью пользуются интернетом, предварительно настроив браузер!
Настройка параметров кэша squid
Важным моментом настройки squid является настройка параметров кэширования в squid . Место размещения кэша задается параметром cache_dir в squid.conf. Формат параметр следующий:
Cache_dir тип путь размер L1 L2
где, тип - это алгоритм формирования кэша, может быть: ufs (unix file system), aufs (async ufs), diskd (внешние процессы для избежания блокировки squid на дисковом вводе/выводе). Рекомендуется использовать ufs , хотя некоторые хвалят aufs . Путь - задает место размещения кэша в файловой системе (должен существовать и иметь права доступа на запись для пользователя, под которым работает squid - обычно proxy). Размер - задает максимальный размер, после которого кэш начнет очищаться. В сети существует множество холиваров по этому параметру. Идеальный размер кеша - от 2 до 10 ГБ в зависимости от числа клиентов. Приблизительно 1 ГБ кеша на каждые 100 тысяч запросов/день. Я придерживаюсь значения в 5 Гб. В Squid каждый кешируемый объект располагается в отдельном файле, сами файлы не сваливаются в одно место, а используется двухуровневая иерархия каталогов. Количество каталогов 1 и 2 уровней и определяют параметры L1 и L2 . Эти значения можно оставить по умолчанию. Но для ориентирования в ситуации приведу цитату с bog.pp.ru:
Эксперимент показал, что при кэше в 700 МБ используется только 2 директории первого уровня. То есть для при стандартной структуре директорий кеша в него "с комфортом" влезает миллион объектов (9 GB), если их больше, то надо увеличить число директорий верхнего уровня
Можно использовать несколько cache_dir . Это положительно сказывается на производительности, особенно, если разместить кэш на разных дисках. Еще больше ускорить работу кэша можно, разместив кэш в tmpfs. Для каждого параметра cache_dir можно в разделе options определить параметр read-only (только чтение) и max-size (максимальный размер объекта).
Максимальный размер объекта в кэше определяется параметром maximum_object_size , значение по умолчанию - 4 Мб. Я данное значение увеличил до 60 Мб, т.к. сотрудникам в локальной сети часто приходится скачивать однотипные файлы до указанного размера:
Maximum_object_size 61440 KB
Аналогично? есть и параметр minimum_object_size отвечающий за минимальный размер объекта, по умолчанию его значение “0” то есть отключен. Я рекомендую значение этого параметра увеличить до 2-3 Кб, что снизит нагрузку на диск при поиске маленьких объектов.
Объем ОЗУ , используемый сквидом задается в параметре cache_mem , значение по умолчанию 256 Мб (в версии 3.1). Данное значение я оставил по умолчанию. Менять это значение стоит лишь в том случае, если сквид вас об этом попросит в логах. После данных изменений, необходимо перезапустить сквид, при этом будет создана структура каталогов:
Gw ~ # service squid3 start Starting Squid HTTP Proxy 3.x: squid3Creating Squid HTTP Proxy 3.x cache structure ... (warning). 2012/02/19 22:58:21| Creating Swap Directories 2012/02/19 22:58:21| /var/spool/squid3 exists 2012/02/19 22:58:21| Making directories in /var/spool/squid3/00 2012/02/19 22:58:21| Making directories in /var/spool/squid3/01 2012/02/19 22:58:21| Making directories in /var/spool/squid3/02 2012/02/19 22:58:21| Making directories in /var/spool/squid3/03 2012/02/19 22:58:21| Making directories in /var/spool/squid3/04 2012/02/19 22:58:21| Making directories in /var/spool/squid3/05 2012/02/19 22:58:21| Making directories in /var/spool/squid3/06 2012/02/19 22:58:21| Making directories in /var/spool/squid3/07 2012/02/19 22:58:21| Making directories in /var/spool/squid3/08 2012/02/19 22:58:21| Making directories in /var/spool/squid3/09 2012/02/19 22:58:21| Making directories in /var/spool/squid3/0A 2012/02/19 22:58:21| Making directories in /var/spool/squid3/0B 2012/02/19 22:58:21| Making directories in /var/spool/squid3/0C 2012/02/19 22:58:21| Making directories in /var/spool/squid3/0D 2012/02/19 22:58:21| Making directories in /var/spool/squid3/0E 2012/02/19 22:58:21| Making directories in /var/spool/squid3/0F .
Много интересных вопросов и ответов на них по использованию кэша и памяти squid"ом описано . На этом, можно считать типовое решение по настройке прокси-сервера законченным.
Пример настройки прозрачного прокси squid
Что есть прозрачный прокси ? Это режим работы прокси сервера, когда клиент не настраивается на работу через прокси и посылает запросы в сеть по протоколу HTTP, как если бы клиент браузер работал напрямую с веб-сервером. При этом, силами (в linux - ) исходящие запросы на HTTP направляются на порт, на котором запущен прокси. Прокси-сервер же, в свою очередь, преобразовывает HTTP запросы в запросы протокола прокси-сервера и посылает ответы клиенту, как веб сервер. Т.о. для клиента прозрачно происходит взаимодействие с прокси-сервером.
Важно понимать и знать! Данный метод поддерживает только HTTP протокол , и не поддерживает gopher, FTP или другое проксирование. А так же, Squid не умеет одновременно работать в прозрачном режиме и в режиме аутентификации.
Для настройки прозрачного режима, необходимо:
1. Задать прозрачный режим в настройках прокси. Это делается в параметре http_port , например:
Http_port ip:port transparent
2. Завернуть пользователей соответствующим правилом на нужный порт силами iptables:
Iptables -t nat -A PREROUTING -i имя_входящего_интерфейса -s подсеть_локльной_сети -p tcp --dport 80 -j REDIRECT --to-port порт_squid, пример: iptables -t nat -A PREROUTING -i eth1 -s 10.0.0.0/24 -p tcp --dport 80 -j REDIRECT --to-port 3128
Все. Можно наслаждаться завернутыми и ничего не подозревающими пользователями на наш прокси-сервер.
Траблешуттинг
В первую очередь, диагностика работы squid заключается в просмотре журналов , расположенных в /var/log/squid3 . Большинство проблем решается данным способом. Если это не помогло решить проблему, то переключив демона в дебаг режим командой squid3 -k debug проблему будет найти проще. Собственно, что из себя представляет лог сквида? Файлы логов содержат различную информацию о загрузке и производительности Squid. В log пишутся кроме информации о доступе, /preеще и системные ошибки и информация о потреблении ресурсов, таких, например, как память или дисковое пространство.
Формат log файлов Squid представляет собой строку из значений, разделенных одним или несколькими пробелами:
Время.мс время_отклика ip_src Squid_req_status/HTTP_status byte_snd метод URL user squid_her_status/ip_dst MIME
- время - время в формате unix (Количество секунд от 00:00 1970.01.01)
- мс - миллисекунды с точностью до 3х знаков
- время_отклика - время отклика, миллисекунд
- ip_src - IP адрес источника
- Squid_req_status - статус запроса у squid (например, TCP_HIT для ранее кешируемых объектов, TCP_MISS если запрашиваемый объект взят не из локального кеша, UDP_HIT и UDP_MISS то же для братских запросов)
- HTTP_status - статус http протокола (200 для удачных, 000 для UDP запросов, 403 для перенаправлений, 500 для ошибок)
- byte_snd - передано, байт в ответ включая HTTP заголовок
- метод - метод запроса GET или POST
- URL - запрошенный url-адрес
- user - имя авторизованного пользователя
- squid_her_status - статус иерархии squid - Результат запросов к братским/родительским кешам
- ip_dst - IP адрес запрашиваемого узла
- MIME - mime-type
Рассмотрим на примере:
1329732295.053 374 10.0.1.55 TCP_MISS/200 1475 GET http://www.youtube.com/live_comments? - DIRECT/173.194.69.91 text/xml
Как видно, запрос сделан в 1329732295.053, ответ удаленного сервера составил 374 мс, хост, запросивший страницу имеет IP 10.0.1.55, запрошенный объект был передан не из локального кэша (TCP_MISS), код ответа сервера - 200, клиенту передано 1475 байт методом GET, был запрошен URL http://www.youtube.com/live_comments?, имя пользователя не определено, объект был получен напрямую от сервера с IP 173.194.69.91, был передан текст, т.к. mime - text/xml. Вот.
Некоторые заключительные моменты о squid3
В статье я рассмотрел основные принципы работы прокси сервера, а так же, базовые настройки, позволяющие реализовать простейший кэширующий сервер, а так же организовать работу squid в прозрачном (transparent) режиме. Squid поддерживает несколько вариантов авторизации (по IP, через LDAP, MySQL, NTLM и др.), возможности ограничения пропускной способности канала и контроля доступа к ресурсам интернет. Работу сквида с методами различной авторизации и примеры контроля трафика я рассмотрю в следующих статьях.
Для начала представим, что у нас есть обычная сеть, выходящая в интернет через один шлюз (прокси-сервер Squid установлен здесь же). Предположим, IP-адрес шлюза 192.168.1.1 . Все остальные компьютеры в сети получают настройки IP по DHCP. Компьютеры в сети разные, Windows XP/7, Ubuntu, да моло ли еще какие. За всеми не углядишь. Но мы должны считать трафик, ускоряя при этом доступ в интерент, должны контролировать (хотя бы от "дурака") доступ в интернет и пр. Squid обладает широкими возможностями по логированию, ограничению доступа и пр. Поэтому нам нужно, чтобы все компьютеры в сети не могли миновать нашего прокси-сервера Squid. Поэтому нам надо в любом случае направить (завернуть, пробросить) запрос клиентских компьютеров только через прокси-сервер Squid.
Настройка переадресации портов
При обращении клиентов локальной сети к внешним сайтам Squid должен прозрачно для клиента перехватить запрос и обработать его согласно своим правилам - решить, какой контент отдать, логировать ли активность пользователя, можно ли вообще этому пользователю выходить в интернет. Наша задача - сделать так, чтобы на самом клиенте не надо было бы делать никаких настроек броузеров. Клиент просто подключился к локальной сети и уже работает через наш прокси-сервер и НИКАК иначе. Т.е. даже если кто-либо захочет обойти наш прокси, без хитростей ему уже не обойтись.
Переадресация портов в FreeBSD
Если на нашем шлюзе установлена FreeBSD и брандмауэр по-умолчанию - IPFW, то для выполнения этой задачи мы должны на шлюзе установить переадресацию (проброс) портов:
# Redirect to local proxy
/sbin/ipfw add 0170 fwd 127.0.0.1,3128 tcp from 192.168.1.0/24 to any 80
- 0170 - номер правила (в вашем случае может быть любой).
- fwd 127.0.0.1,3128 - куда будем направлять пакеты, - в нашем случае нашему любимому Squid, запущенному на порту 3128 на шлюзе, - ...
- from 192.168.1.0/24 - ... отправленные компьютерами локальной сети...
- to any 80 - ... на какой-либо сайт в интернете
Теперь внимание! Это правило нужно добавить ДО того, как правила NAT (Network Address Translation) получат этот запрос. Объясню немного неакадемично: что делает NAT? В нашем случае NAT изменяет адрес источника (заменяет локальный IP клиента на внешний IP шлюза и запоминает, от какого внутреннего клиента был запрос. Для того, чтобы Squid обработал запрос от клиента, ему не нужно ничего преобразовывать - он и сам с этим справится. Поэтому Squid должен получить пакет в первозданном виде и сам решить, что делать дальше.
К тому же NAT и Squid - все-таки разные вещи, и пакет, адресованный, скажем к 2.3.4.5:80 , не содержит информации, как попасть в Squid (на порт 3128 шлюза). И пакет будет обрабатываться только средствами NAT. Squid пакет так и не увидит. Поэтому наша задача - просто отдать Squid-у тот пакет, который отправил броузер пользователя. Объясню на примере части конфига ipfw:
Cmd="ipfw -q add" $skip="skipto 5000" pif="xl1" #внешний интерфейс... # Redirect to local proxy $cmd 0170 fwd 127.0.0.1,3128 tcp from 192.168.1.0/24 to any 80 # NAT $cmd 0200 divert natd ip from any to any in via $pif # Allow keep-state statement. $cmd 0201 check-state # POP3/POP3S $cmd 0325 $skip tcp from any to any 110 out via $pif setup keep-state $cmd 0326 $skip tcp from any to any 995 out via $pif setup keep-state # WWW (HTTP/HTTPS/..) $cmd 0350 $skip tcp from any to any 80 out via $pif setup keep-state $cmd 0352 $skip tcp from any to any 443 out via $pif setup keep-state # This is skipto location for outbound stateful rules $cmd 5000 divert natd ip from any to any out via $pif ...
В конфиге выше запрос открыть сайт сначала обрабатывается правилом 0170 , которое заворачивает запрос в Squid. Squid (как и любая другая программа) также выполняет требования брандмауэра - только для него правило 0170 не действует, а вот правило 0350 разрешает Squid отправить запрос в интернет. Для того, чтобы выходить в интернет без Squid, необходимо закоментировать правило 0170 . В этом случае Squid не получит ничего, а все запросы броузеров из локальной сети будут обрабатываться правилом 0350 .
Переадресация портов в Linux
Если на нашем шлюзе установлена Linux и , то вышеуказанная команда будет выглядеть так:
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 3128
где eth0 - внутренний интерфейс.
В остальном смысл переадресаций и пр. аналогичен тому, как это объяснялось для ipfw . Разнятся только правила постороения конфигурационных файлов ipfw и iptables . Пример правил iptables можно изучить .
С этим разобрались. Теперь надо дать указание Squid о том, что он должен обрабатывать пакеты, изначально на него не направленные. Переходим к включению режима прозрачности Squid.
Прозрачный Squid в squid.conf
Теперь дело осталось за малым - настроить Squid в режим невидимки, т.е. принимать автоматически перенаправленные пакеты и обрабатывать их. В разных версиях Squid за это отвечали разные команды. Настройка Squid версии 2.6.* выглядит так:
http_port 127.0.0.1:3128 transparent # Squid работает в прозрачном режиме
Внимательно просмотрите конфигурационный файл squid.conf на предмет дубликатов директив - я потратил два часа времени, обратился на форум за помощью с "нестандартной проблемой", в то время как просто не обратил внимание на то, что первой строкой у меня включался обычный режим работы Squid:
http_port 3128 # Squid работает в обычном режиме
Практически все. Перезапустите Squid, примените правила брандмауэра с добавленной командой перенаправления портов - теперь любой компьютер локальной сети, выходя через наш шлюз в интернет, не сможет миновать нашего ставшего прозрачным для всех Squid. А теперь попробуйте настроить прокси на каком-нибудь компьютере - компьютер не должен получить выход в интернет. Вроде все. Если есть вопросы или советы - комментарии приветствуются, особенно учитывая, что настройка прозрачного Squid и проброс портов вообще "больная" тема на форумах.
Плюсы и минусы
Из плюсов можно отметить абсолютную уверенность, что все запросы на 80 порт (стандартный для веб) будут обработаны Squid-ом. Соответственно, будут логи, статистика для шефа и отсутствие необходимости бегать и руками все настраивать.
Из минусов можно отметить:
- невозможность (по-крайней мере, простым способом) авторизовать пользователей для доступа в интернет;
- если вдруг "упадет" Squid, то доступ к сайтам прекратится. Поэтому админу нужно или быть уверенным, что все будет ОК, или иметь возможность удаленно изменить конфиг брандмауэра, или написать скрипт, автоматом проверяющего, висит ли Squid на порту 3128, и если нет, то запускающего его.
Настройка Squid в прозрачном режиме завершена. Вот теперь - все.
