Прозрачные прокси. Типы прокси и их различия. Что такое прозрачный прокси-сервер

Не многие пользователи знают что такое прозрачный прокси сервер squid, для чего нужен сквид, его преимущества и недостатки. Сейчас мы рассмотрим каждый вопрос по отдельности и постараемся вникнуть в тему.

Негативные стороны прозрачного прокси:

В прозрачном режиме, не работает с SSL. Это значит, что вы не сможете зайти на сайт с адресом https://... в режиме аутентификации может работать на протоколах HTTP, SSL, FTP.
Не умеет работать сразу в двух режимах: аутентификации и прозрачном - доступ в интернет без всяких настроек, логинов и прочего. Режим аутентификации - когда пользователю необходимо ввести логин/пароль или другие настройки, предусмотренные администратором.
Не умеет работать с почтовыми серверами POP3, SMTP, IMAP. Вы не сможете принять или отправить почту через прокси сквид.

Режим - каскадный прокси

Как уже упоминалось выше, squid может сохранять информацию в ОЗУ компьютера, к которой в случае необходимости можно вернуться за доли секунды. При поиске информации, каскадный прокси позволяет обращаться ко всем группам сети только в случае ее отсутствия. Осуществляется поиск в интернете. Бесспорно, удобная и полезная функция.

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

В данной статье приводится пример быстрой настройки кэширующего прокси сервера 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/
Все ребята готово. Будут вопросы спрашивайте, помогу чем смогу.

Tutorial

Привет, хабровчане! Я думаю, многие в последнее время столкнулись с проблемами доступа к нужным ресурсам из-за попыток Роском позора надзора заблокировать Телеграм. И я думаю, комментарии тут излишни. Факт - эти ресурсы ни в чем не виноваты, но они заблокированы. Проблемы возникли с Viber, ReCaptcha, GoogleFonts, Youtube и др. (кроме самого телеграма). Это случилось и в моей организации, причем некоторые невинные сервисы нужны нам как воздух. В какое-то время решалось все использованием прокси серверов, но они были нестабильны или вовсе отключались (их также блокировал наш великий и могучий РКН).

После прочтения кучи статей, пришла идея научить Squid пускать отдельные URL через Tor. Использовать ли такой метод, решать вам. Но скажу, что после реализации пропали все проблемы, которые были до этого. Кому интересно, идем под кат.

Зачем это?

Статья написана исключительно в целях помощи тем, кто неправомерно страдает от тотального бреда, который творится у нас в стране. Также она ориентирована на тех, кому нужен именно «прозрачный» Squid с HTTPS без подмены сертификатов и возможностью отслеживания посещений как по HTTP так и по HTTPS, поскольку статья по сути является продолжением статьи, так как здесь я предлагаю исправление давнего бага, который не позволял видеть в логах доменные имена https ресурсов и не позволял использовать более новые версии Squid. Ну а также просто для тех, кому интересно использование Squid.

Какие преимущества?

Неограниченные возможности масштабирования
Относительная легкость в поддержке и администрировании
Если это важно, то можно предоставлять анонимный доступ на указанные в списке ресурсы (хоть это и не тема статьи, но анонимность предоставляется «искаропки»
Стабильность. При использовании нескольких сервисов Tor (разные конфиг файлы) их можно подключить к Squid, и получить round robin.
Абсолютная бесплатность. Навсегда.

Я ничего не знаю, Squid\Tor медленный, пойду и подниму VPS с VPN за бугром

Поздравляю! Вы действительно решили, что Роскомнадзор доставил вам неудобства, и вам же еще за это платить, чтобы выйти из положения? Ок. Можете смело пропускать статью, и поднимать VPN туннели. Кстати, VPN успешно блокируется. Легко. И в свете последних событий, я подскажу, что в скором времени никто не сможет использовать VPS для обхода блокировок на уровне закона. И плюс ко всему, ваш VPS может так же угодить в блокировку «просто потому что рядышком сидит телеграм». Tor не заблокируется, никак. Если его настроить с obfs, то никогда и нигде (тема, пожалуй, для отдельной статьи, так как в этой obfs не рассматривается). И сколько нужно будет поднимать таких VPS с VPN? Как это обслуживать? Здесь же решение легче в разы, надежное, и при желании, вполне скоростное, к тому же бесплатное. Так что прежде чем вводить в заблуждение других читателей, пожалуйста, еще раз обдумайте все + и - VPS с VPN, и только после этого утверждайте, что Squid+Tor - это тормознутое, ненадежное решение.

Tor заблокируют! В Китае, вон, уже заблокирован

Нет. Нет. И еще раз нет. В Китае Tor работает при настроенном obfs. Прекрасно работает. Нет в Мире способа заблокировать Tor. Даже Китаю с его мощностями, умами и финансами не удалось это сделать.

Tor медленный! А если работать через obfs, то вообще жуть!

Обратитесь к оф.документации и куче статей в Интернете, где описывается, как сделать так, чтобы скорость была на приличном уровне. И опять же, настроив таким образом несколько копий Tor с разными конфигами, их можно пристроить к Squid и получить round robin.

Итак, для начала немного теории. Как мы все знаем, Tor - это не HTTP-прокси, его нельзя сделать прямым peer для нижележащего Squid"а. Он предоставляет SOCKS-проксирование (конечно же, не только, но нам нужно именно это). Чтобы нам поженить Tor со Squid, нужно что-то, что могло бы играть роль проводника от Tor к Squid и обратно. И конечно же, дамы и господа, это Privoxy. Как раз таки он способен быть прямым peer, и отправлять все далее в Tor.

Было, как я уже говорил, прочтено куча статей, но ни одна не подходила мне. Попалась вот эта статья, но и она мне не совсем подходила, так как мне не нужен bump. Вообще, все имеющиеся статьи, практически все, подразумевают либо бамп, либо только http, а в моем случае нужно и HTTPS, и splice, и прозрачность. Также видал вот это и , но там совсем другие подходы. Свои плюсы и минусы. Я выбрал для себя именно связку Squid + Tor.

Я уже писал о том, как сделать прозрачный Squid с проксированием HTTPS без подмены сертификатов. И конечно же, я попробовал реализовать идею на нем. Но меня ждало разочарование. HTTP запросы прекрасно уходили в TOR, а вот HTTPS нет. Проблема не очень-то и известная, и я узнал у одного из разработчиков, что это недостаток старых версий Squid. Но в ходе экспериментов было найдено решение - Squid 3.5.27, в котором исправлен данный баг + красивые доменные имена в логах (https), вместо ip адресов. Но и тут меня ждали несколько разочарований, о которых речь пойдет ниже. Но всё, как говорится, допиливается напильником.

Итак, исходные данные:

Debian Stretch (9) x86 (в х64 не пробовал)
Сорцы Squid 3.5.23 из репозитория
Свеженькие сорцы Squid с оф.сайта
OpenSSL
Libecap3
Privoxy
Прямые руки и много кофе с печеньками

Собирать Squid ручками или ставить готовые пакеты (ссылки ниже), решать вам. Если вы думаете, что я впендюрил в них блекджек и ш… вирусы, то компильте сами. Также компилировать нужно, если у вас дистрибутив другой (если Убунта, то поставите). Собирать мы будем версию Squid 3.5.23, которая на момент написания статьи валяется в репозитории Stretch , повысив ее до свежих исходников 3.5.27 с оф.сайта. В отличие от моей первой статьи про HTTPS+Squid, собирать будем без Libressl.

Итак, подготовимся к сборке:

Apt-get install fakeroot build-essential devscripts apt-get build-dep squid3 apt-get install libecap3 apt-get install libecap3-dev apt-get install libssl1.0-dev apt-get install libgnutls28-dev

ВАЖНО!

Очень важно ставить именно libssl1.0-dev, а не другую версию, иначе Squid будет либо лагать, либо не соберется вовсе из-за непонятных ошибок

Apt-get source squid3
Качаем именно этот архив с исходниками Squid:

Wget -O squid-3.5.27-2018.tar.gz http://www.squid-cache.org/Versions/v3/3.5/squid-3.5.27-20180318-r1330042.tar.gz
Переходим в каталог исходников Squid и обновляем исходники до новоскаченных сорцов:

Cd squid3-3.5.23/ uupdate -v 3.5.27-2018 ../squid-3.5.27-2018.tar.gz
Переходим в новоиспеченный каталог с обновленными исходниками:

Cd ../squid3-3.5.27-2018
Добавляем в debian/rules опции для компиляции:

Enable-ssl \ --enable-ssl-crtd \ --with-openssl

Совет

Можете, кстати, вырубить ненужные вам опции, это ускорит компиляцию

Дальше нужно пропатчить исходники вот таким патчем:

client_side_request.patch --- src/client_side_request.cc Thu Aug 18 00:36:42 2016 +++ src/client_side_request.cc Mon Sep 19 04:41:45 2016 @@ -519,20 +519,10 @@ // note the DNS details for the transaction stats. http->request->recordLookup(dns); - if (ia != NULL && ia->count > 0) { - // Is the NAT destination IP in DNS? - for (int i = 0; i < ia->count; ++i) { - if (clientConn->local.matchIPAddr(ia->in_addrs[i]) == 0) { - debugs(85, 3, HERE << "validate IP " << clientConn->local << " possible from Host:"); - http->request->flags.hostVerified = true; - http->doCallouts(); - return; - } - debugs(85, 3, HERE << "validate IP " << clientConn->local << " non-match from Host: IP " << ia->in_addrs[i]); - } - } - debugs(85, 3, HERE << "FAIL: validate IP " << clientConn->local << " possible from Host:"); - hostHeaderVerifyFailed("local IP", "any domain IP"); + debugs(85, 3, HERE << "validate IP " << clientConn->local << " possible from Host:"); + http->request->flags.hostVerified = true; + http->doCallouts(); + return; } void
Для чего он нужен? Я объясню. Когда я писал первую статью про peek and splice, я говорил что более новые версии не работают, и это было так, и вот как раз таки этот патч исправляет ту самую проблему, которая заключалась в том, что Squid выборочно рвет HTTPS соединения, с интересным сообщением в cache.log:

SECURITY ALERT: Host header forgery detected on ... (local IP does not match any domain IP)
Дело в том, что на одном хосте что-то резолвится в один IP, на соседнем иногда в другой, на самом Squid в третий, т.к. существует кеш DNS и обновляется он не синхронно. Squid не находит соответствия ip-домен в своём кеше (потому что обновил свой кеш немного раньше или позже) и прерывает соединение. Вроде как, защита, но в наше время это считается нормальным (round-robin DNS). Разработчики перестраховались. И нам это не нужно совершенно! Тем, кто скажет, что данный патч, возможно, несет в себе угрозу безопасности, я отвечу, что по поводу этого патча я консультировался с Юрием Воиновым, который имеет непосредственное отношение к команде разработчиков Squid. Никакой угрозы здесь нет!

Итак, файлик для патча создали, код кинули, надо пропатчить:

Patch -p0 -i client_side_request.patch
Далее необходимо отменить применение одного патча при компиляции (иначе получите ошибку, что этот патч применить невозможно, так как он уже применен). Идем в debian/patches/series и закомментим там 0003-SQUID-2018_1.patch , поставив перед ним знак # :

Dpkg-buildpackage -us -uc -nc
Установим squid-langpack

Apt-get install squid-langpack
и установим свеженькие пакеты

Dpkg -i squid-common_3.5.27-2018-1_all.deb dpkg -i squid_3.5.27-2018-1_i386.deb dpkg -i squid3_3.5.27-2018-1_all.deb
Если apt матерится на зависимости, сделайте

Systemctl disable squid
и создать systemd сервис в директории /etc/systemd/system (файл сервиса есть в исходниках, и полностью скопирован сюда)

Cat /etc/systemd/system/squid3.service ## Copyright (C) 1996-2018 The Squid Software Foundation and contributors ## ## Squid software is distributed under GPLv2+ license and includes ## contributions from numerous individuals and organizations. ## Please see the COPYING and CONTRIBUTORS files for details. ## Description=Squid Web Proxy Server After=network.target Type=simple ExecStart=/usr/sbin/squid -sYC -N ExecReload=/bin/kill -HUP $MAINPID KillMode=process WantedBy=multi-user.target
Включим его
systemctl enable squid3.service

Установим tor, privoxy

Apt-get install tor privoxy
Конфиг Tor я лично вообще не трогал, а вот конфиг Privoxy можно привести к такому виду:

Listen-address 127.0.0.1:8118 toggle 0 enable-remote-toggle 0 enable-remote-http-toggle 0 enable-edit-actions 0 forward-socks5t / 127.0.0.1:9050 . max-client-connections 500
Почти готово. Перейдем в каталог /etc/squid , кое-что там изменим. Создадим pem файлик, необходимый для splice:

Openssl req -new -newkey rsa:1024 -days 365 -nodes -x509 -keyout squidCA.pem -out squidCA.pem
И приведем squid.conf к следующему виду:

Acl localnet src 192.168.0.0/24 # Ваша локалка 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 acl SSL method CONNECT #Укажем DNS для Squid. Крайне рекомендую использовать одинаковые DNS тут и у клиентов dns_nameservers 77.88.8.8 # Список доменов, которые нужно пустить через Tor acl rkn url_regex "/etc/squid/tor_url" http_access deny !Safe_ports http_access deny CONNECT !SSL_ports http_access allow localhost manager http_access deny manager http_access allow localnet http_access allow localhost http_access deny all icp_access deny all htcp_access deny all #прозрачный порт указывается опцией intercept http_port 192.168.0.1:3128 intercept options=NO_SSLv3:NO_SSLv2 #также нужно указать непрозрачный порт, ибо если захотите вручную указать адрес #прокси в браузере, указав прозрачный порт, вы получите ошибку доступа, поэтому нужно #указывать непрозрачный порт в браузере, если конечно такое желание будет, к тому же в логах #сыпятся ошибки о том, что непрохрачный порт не указан=) http_port 192.168.0.1:3130 options=NO_SSLv3:NO_SSLv2 #и наконец, указываем HTTPS порт с нужными опциями https_port 192.168.0.1:3129 intercept ssl-bump options=ALL:NO_SSLv3:NO_SSLv2 connection-auth=off cert=/etc/squid/squidCA.pem sslproxy_cert_error allow all sslproxy_flags DONT_VERIFY_PEER #укажем правило со списком блокируемых ресурсов (в файле домены вида.domain.com) acl blocked ssl::server_name "/etc/squid/blocked_https.txt" acl step1 at_step SslBump1 ssl_bump peek step1 #терминируем соединение, если клиент заходит на запрещенный ресурс ssl_bump terminate blocked ssl_bump splice all # Никогда не пускать напрямую домены, указанные в списке РКН never_direct allow rkn # Указываем прокси, куда отправлять домены из списка, в нашем случае - Privoxy cache_peer 127.0.0.1 parent 8118 0 no-query no-digest default cache_peer_access 127.0.0.1 allow rkn cache_peer_access 127.0.0.1 deny all sslcrtd_program /usr/lib/squid/ssl_crtd -s /var/lib/ssl_db -M 4MB coredump_dir /var/spool/squid 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 logfile_rotate 4 pid_filename /var/run/squid.pid
Список url_regex имеет примерно такой вид (список дан для примера!):

Zenway\.ru \.*google\.com \.*viber\.* \.amazon\.com \.fbcdn\.net \.slack\.* media\.api\.viber\.com* static\.viber\.com* secure\.viber.* \*.cloudfront\.net fonts\.gstatic\.com med-edu\.ru

Прозрачный прокси-сервер, также известный как перехватывающий прокси-сервер или принудительный прокси-сервер, является сервером, который перехватывает исходящую информацию в сети до того, как она попадает в Интернет, без какой-либо конфигурации на клиентском компьютере. В отличие от явных прокси, которые требуют конфигурации на основе программного обеспечения, прозрачные прокси требуют только серверной конфигурации, что означает, что они могут использоваться в сети без ведома конечного пользователя. Эти серверы часто используются для оптимизации баланса нагрузки или содержимого фильтра. Многие школы и рабочие места используют этот прокси-сервер.
Как явный прокси-сервер, прозрачный прокси-сервер может повысить производительность сети с помощью процесса, известного как кеширование. Данные хранятся локально по первому запросу, что позволяет обрабатывать последующие запросы намного быстрее. В сети с использованием прозрачного прокси-сервера все запросы с клиентских компьютеров проходят через один хост, поэтому хост может хранить большую часть часто запрашиваемых данных локально, сохраняя необходимость передачи данных через Интернет. Когда выполняется большое количество веб-запросов — например, во многих школьных или бизнес-сетях — кэширование может сэкономить много времени и пропускной способности.

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

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