Идем по-порядку.
1)
а) Для начала, подготовимся к сборке пакетов:
apt-get install git fakeroot checkinstall build-essential devscripts patch
apt-cache policy squid3
apt-get build-dep squid3
apt-get build-dep libecap2
apt-get install libssl-dev libgnutls28-dev
Не забудьте перейти в ту папку, где вы будете собирать исходники, чтобы не загадить себе Хоум.
б) Далее скачаем Libressl:
wget http://ftp.openbsd.org/pub/OpenBSD/LibreSSL/libressl-2.1.6.tar.gz
tar -xzvf libressl-2.1.6.tar.gz
cd libressl-2.1.6
в) А теперь собираем:
./configure
make
checkinstall --pkgname libressl --pkgversion 2.1.6
2) Теперь можно установить Libressl:
dpkg -i libressl_2.1.6-1_amd64.deb
ldconfig
После установки необходимо настроить использование LibreSSL по-умолчанию:
mv /usr/bin/openssl /usr/bin/openssl-1
update-alternatives --install /usr/bin/openssl openssl /usr/bin/openssl-1 10
update-alternatives --install /usr/bin/openssl openssl /usr/local/bin/openssl 50
update-alternatives --config openssl
Проверим, получилось ли поставить Libressl:
openssl version
LibreSSL 2.1.6
Если выхлоп консоли похожий, то все получилось. Идем дальше.
3) На очереди Libecap.
а) Необходимо отредактировать sources.list, включив туда исходники из ветки testing (это необходимо, так как нам нужно компилировать новый libecap, который в свою очередь необходим для сборки Squid):
deb-src http://ftp.de.debian.org/debian/ testing main contrib non-free
Обновим кеш пакетов:
apt-get update
А теперь скачаем из Testing нужные исходники:
apt-get source libecap3/testing
Далее соберем libecap:
cd libecap-1.0.1/
dpkg-buildpackage -us -uc -nc -d
б) Удалим старье, и установим новье:
apt-get purge libecap2
libecap3_1.0.1-2_amd64.deb
libecap3-dev_1.0.1-2_amd64.deb
4) Подобрались к компиляции самого Squid'a.
а) Качаем
wget http://www.squid-cache.org/Versions/v3/3.5/squid-3.5.8.tar.gz
Распакуем:
tar -xf squid-3.5.8.tar.gz
cd squid-3.5.8
б) Качаем патч для bio.cc, и патчим:
wget -O bug-4330-put_cipher_by_char-t1.patch http://bugs.squid-cache.org/attachment.cgi?id=3216
patch -p0 -i bug-4330-put_cipher_by_char-t1.patch
» patching file src/ssl/bio.cc
5) А этот этап один из самых ответственных. Необходимо сконфигурировать Squid с нужными опциями. В предыдущей статье использовался файл debian/rules, но компилировать Squid в этой инструкции мы будем с помощью make, и создавать пакеты будем с помощью checkinstall. Поэтому опций будет побольше. И вот какие:
./configure --build=x86_64-linux-gnu --prefix=/usr --includedir=${prefix}/include --mandir=${prefix}/share/man --infodir=${prefix}/share/info --sysconfdir=/etc --localstatedir=/var --libexecdir=${prefix}/lib/squid --srcdir=. --disable-maintainer-mode --disable-dependency-tracking --disable-silent-rules --datadir=/usr/share/squid --sysconfdir=/etc/squid --mandir=/usr/share/man --enable-inline --disable-arch-native --enable-async-io=8 --enable-storeio=ufs,aufs,diskd,rock --enable-removal-policies=lru,heap --enable-delay-pools --enable-cache-digests --enable-icap-client --enable-follow-x-forwarded-for --enable-auth-basic=DB,fake,getpwnam,LDAP,NCSA,NIS,PAM,POP3,RADIUS,SASL,SMB --enable-auth-digest=file,LDAP --enable-auth-negotiate=kerberos,wrapper --enable-auth-ntlm=fake,smb_lm --enable-external-acl-helpers=file_userip,kerberos_ldap_group,LDAP_group,session,SQL_session,unix_group,wbinfo_group --enable-url-rewrite-helpers=fake --enable-eui --enable-esi --enable-icmp --enable-zph-qos --enable-ecap --disable-translation --with-swapdir=/var/spool/squid --with-logdir=/var/log/squid --with-pidfile=/var/run/squid.pid --with-filedescriptors=65536 --with-large-files --with-default-user=proxy --enable-ssl --enable-ssl-crtd --with-openssl --enable-linux-netfilter 'CFLAGS=-g -O2 -fPIE -fstack-protector-strong -Wformat -Werror=format-security -Wall' 'LDFLAGS=-fPIE -pie -Wl,-z,relro -Wl,-z,now' 'CPPFLAGS=-D_FORTIFY_SOURCE=2' 'CXXFLAGS=-g -O2 -fPIE -fstack-protector-strong -Wformat -Werror=format-security'
Будьте предельно внимательны. Нас больше интересуют, как и в предыдущей статье, три опции: --enable-ssl, --enable-ssl-crtd, --with-openssl. Остальные опции можете изменять в соответствие с вашими предпочтениями (если хотите их менять, обязательно прочитайте документацию по конфигурированию).
6) Теперь мы добрались до компилирования.
а) Компилируем.
make
б) Неоднозначный этап. Необходимо создать директории /usr/share/squid/ и /usr/share/squid/icons, иначе следующий этап не выполнится из-за отсутствия этих папок (почему checkinstall их сам не создает, я не разбирался, к сожалению):
mkdir -p /usr/share/squid/icons
в) А теперь создаем установочные пакеты:
checkinstall --pkgname squid --pkgversion 3.5.8
7) Мы подходим к финалу. Устанавливаем Squid:
dpkg -i squid_3.5.8-1_amd64.deb
8) Пробуем запустить squid:
systemctl start squid
И видим большую ФИГУ! Надо же… Пробуем по-старинке:
service squid start
И тоже видим большую ФИГУ. Почему? Потому что checkinstall не включил в пакет файлы сервиса Squid. Не беда. Создадим сами нужный сервис systemd:
touch /etc/systemd/system/squid.service
nano /etc/systemd/system/squid.service
Со следующим содержимым:
## Copyright (C) 1996-2015 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.
##
[Unit]
Description=Squid Web Proxy Server
After=network.target
[Service]
Type=simple
ExecStart=/usr/sbin/squid -sYC -N
ExecReload=/bin/kill -HUP $MAINPID
KillMode=process
[Install]
WantedBy=multi-user.target
Включим созданный сервис
systemctl enable squid
9) Да, вы правы, это еще не все. Так как мы компилировали полностью оригинальные исходники (за исключением патча на bio.cc), конфигурационные файлы у нас установились вида squid.conf.default, mime.conf.default и т.п. Конечно же, Squid о них и не слышал. Переименуем их в Squid'очитаемый вид:
cp /etc/squid/squid.conf.default /etc/squid/squid.conf
cp /etc/squid/mime.conf.default /etc/squid/mime.conf
cp /etc/squid/cachemgr.conf.default /etc/squid/cachemgr.conf
cp /etc/squid/errorpage.css.default /etc/squid/errorpage.css
10) И это еще не все=) Необходимо вручную создать папку для логов Squid'a и назначить ей соответствующие права:
mkdir /var/log/squid
chown proxy /var/log/squid
11) И вот он — финальный этап. Запуск Squid'a и проверка статуса сервиса!
systemctl start squid
systemctl status -l squid
? squid.service - Squid Web Proxy Server
Loaded: loaded (/etc/systemd/system/squid.service; enabled)
Active: active (running) since Пт 2015-12-04 23:32:04 YEKT; 2min 41s ago
Main PID: 590 (squid)
CGroup: /system.slice/squid.service
+-590 /usr/sbin/squid -sYC -N
L-591 (logfile-daemon) /var/log/squid/access.log
дек 04 23:32:04 squidX64 squid[590]: Max Swap size: 0 KB
дек 04 23:32:04 squidX64 squid[590]: Using Least Load store dir selection
дек 04 23:32:04 squidX64 squid[590]: Current Directory is /
дек 04 23:32:04 squidX64 squid[590]: Finished loading MIME types and icons.
дек 04 23:32:04 squidX64 squid[590]: HTCP Disabled.
дек 04 23:32:04 squidX64 squid[590]: Pinger socket opened on FD 16
дек 04 23:32:04 squidX64 squid[590]: Squid plugin modules loaded: 0
дек 04 23:32:04 squidX64 squid[590]: Adaptation support is off.
дек 04 23:32:04 squidX64 squid[590]: Accepting HTTP Socket connections at local=[::]:3128 remote=[::] FD 14 flags=9
дек 04 23:32:05 squidX64 squid[590]: storeLateRelease: released 0 objects
Если выхлоп консоли выглядит похоже, а точнее в нем нет ошибок и обязательно присутствует строка «Active: active (running)», то вы успешно установили себе Squid с поддержкой прозрачного проксирования HTTPS! Поздравляю!
Если не хочется ничего компилировать, то можете скачать архив с готовыми deb пакетами (x64 версия!). Если будете устанавливать из готовых пакетов, то вам нужны будут шаги: 2, 3(б), 7, 8, 9, 10, 11.
Также хочу отметить, что checkinstall позволяет создавать пакеты rpm, и вы можете этим воспользоваться. Единственное, нужно все пакеты собирать с помощью checkinstall, но я думаю, проблем с этим не будет, так как основное и самое сложное уже собрано именно checkinstall'ом.
Конфигурационный файл Squid'a с нужными директивами, описание работы и т.п. читайте в предыдущей статье!
Спасибо Татьяне Илларионовой и разработчикам Squid'a за помощь в создании данного рецепта!
UPD 11.12.15: По просьбе пользователя nikitasius проверил Cloudflare. Товарищ nikitasius писал в комментариях:
Видимо для сайтов, которые за Cloudflare такая система корректно работать не будет…Так вот, проверил. Добавил один из его доменов из Cloudflare в черный список блокировки HTTPS, на него браузер не заходит, но на другие домены, которые прописаны в сертификате, браузер спокойно заходит. Так что, проверка Cloudflare пройдена
У них как правило пачка доменов в сертификатах.
В случае, если example.com находится в одном сертификате с freepron.cum, кальмар сработает на freepron, если последний в локальном бане, так?
UPD 14.12.15: спешу поделиться с коллегами отличной новостью! Я нашел способ заставить работать новые версии Squid'а без особых танцев с бубном! Необходимо, чтобы у клиентов и в настройках Squid'а были одинаковые DNS! В моем случае, на шлюзе с Кальмаром крутится Bind. Назначил клиентам именно его, и Кальмару директивой:
dns_nameservers 127.0.0.1
UPD 16.12.15: Пакеты для Centos!
Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.
Комментарии (56)
petro25
09.12.2015 15:52Даное решение позволяет фильтровать определенные страницы на wikipedia.org?
Например разрешить доступ на Wikipedia, но запретить доступ на uk.wikipedia.org/wiki/HTTPS?
Клиентский браузер не ругается на сертификат?
nagibat0r
09.12.2015 15:56Прочтите предыдущую статью, все будет ясно.
Так как для блокировки используется данные из sni_info (конкретно server_name), то заблокировать отдельные страницы не получится. Браузеры на сертификат не ругаются, так как это не является MITM-атакой! Сертификат не трогается и не подменяется.petro25
09.12.2015 16:01Squid подключается к HTTPS ресурсу, получает его сертификат, и может «посмотреть» некоторые данные о ресурсе, в частности имя сервера, которое нам как раз и нужно для блокировки!
Значит он здесь может посмотреть адрес сервера и полный URL к запрашиваемой странице? Или только адрес сервера(домен)?nagibat0r
09.12.2015 16:08Только адрес сервера, судя по документации на оф.сайте
petro25
09.12.2015 16:10Ясно, большое спасибо. Меня именно это и интересовало.
nagibat0r
09.12.2015 16:13+1Не за что! Я думаю, вскоре найдется способ блокировки отдельных страниц. Это уже сделано, в принципе. Только режим работы Кальмара должен быть НЕ прозрачным. Меня же интересовала тема именно прозрачного проксирования HTTPS
nikitasius
09.12.2015 16:15Наверное вопрос глупый, но: имя сервера он берет просто потому, что подключается к этому самому серверу или из данных сертификата?
nagibat0r
09.12.2015 16:21+1Имя сервера он получает из сертификата. Процесс очень несложный. Кальмар представляется клиентом, «открывает» ресурс, получает сертификат и смотрит sni_info, откуда берет server_name. Как показано в предыдущей статье
acl blocked ssl::server_name "/etc/squid/blocked_https.txt"
создается специальная директива, где мы прописываем пусть к файлу с заблокированными доменами (.google.ru .avito.ru, к примеру). Если данные server_name из sni_info совпадают с доменами из списка, то происходит блокировка, т.е. терминирование соединения
ssl_bump terminate blocked
А если не совпадает, тогда Кальмар ничего не делает, и передает клиенту соединение без подмены сертификата, т.е. без MITM-атакиnikitasius
09.12.2015 16:31Видимо для сайтов, которые за Cloudflare такая система корректно работать не будет…
У них как правило пачка доменов в сертификатах.
В случае, если example.com находится в одном сертификате с freepron.cum, кальмар сработает на freepron, если последний в локальном бане, так?nagibat0r
09.12.2015 16:37+1Получается, что да. Если заблокировать, к примеру, mail.ru, то перестает работать Аська, так как у них же она и располагается. Хотя надо проверить
nikitasius
09.12.2015 16:37кальмар сработает на freepron, если последний в локальном бане
и freepron утащит с собой example.com так как они в одном сертификате?
kafeman
09.12.2015 17:01А если дополнительно использовать SNI?
nagibat0r
09.12.2015 18:19так вся эта система на SNI и завязана!
kafeman
09.12.2015 18:30+1Но вы писали:
Имя сервера он получает из сертификата. Процесс очень несложный. Кальмар представляется клиентом, «открывает» ресурс, получает сертификат и смотрит sni_info, откуда берет server_name.
В варианте с SNI никаких connection probe делать не нужно. И сертификат парсить тоже. Вы просто извлекаете из перехватываемых пакетов имя хоста, которое передается в открытом виде (без шифрования).
У меня сейчас нет под рукой Wireshark'а, но можете проверить сами.
UPD: Не до конца дочитал тот кусок, который сам же и процитировал.
получает сертификат и смотрит sni_info, откуда берет server_name
Я не знаком со сквидом, но почему нельзя было посмотреть содержимое sni_info сразу, без запроса сертификата? И не будет проблем, о которых писал nikitasius.nagibat0r
09.12.2015 18:40Я знаю, как устроены пакеты. И каким же образом Вы хотите в Squid'e это провернуть? Боюсь, что это выходит за рамки данной статьи. К тому же, я считаю, что легче использовать SNI в самом Кальмаре. Результат тот же самый! SNI — это некая информация, которая доступна во время процесса handshake, т.е. рукопожатия. А handshake предусматривает получение клиентом сертификата. Зачем перехватывать какие-то пакеты, если Кальмар итак уже получил SNI_INFO
kafeman
09.12.2015 18:50Я исхожу из того, что мы пытаемся сейчас решить следующую проблему:
В случае, если example.com находится в одном сертификате с freepron.cum, кальмар сработает на freepron, если последний в локальном бане, так?
В случае, если вы перехватите запрос пользователя, то вы сможете узнать, какой ресурс был запрошен на самом деле: freepron.com или example.com.
В случае, если вы сделаете запрос сами, вы лишь узнаете, что это либо freepron.com, либо example.com.
Либо я вас не правильно понял.nagibat0r
09.12.2015 18:55+1Вопрос товарища nikitasius еще нужно проверить, так как я не сталкивался с такими сертификатами. Но Ваше утверждение требует глобального вмешивания в трафик пользователя, что является потенциальной дырой в безопасности. К тому же, я еще раз повторюсь, не представляю, как это все сделать в связке с Кальмаром. Если есть реальная идея, с удовольствием посмотрю
kafeman
09.12.2015 18:59Как я уже сказал, у меня сейчас нет возможности поснифить свой трафик. Вот первая попавшаяся картинка из Google. Суть в том, что имя запрашиваемого хоста можно получить в открытом виде.
Насколько я понял по сайту Squid, последний так и делает.
UPD: Торопился и не туда ответил. Это ответ на комментарий nagibat0r выше.nagibat0r
09.12.2015 19:02можно, оно и не шифруется, но Squid итак смотрит именно эту информацию. Поэтому смысла парсить трафик не вижу.
kafeman
09.12.2015 19:15Похоже, мы говорим с вами об одном и том же, просто на разных уровнях абстракции. Вы мне про конфиг Squid, а я вам про сам алгоритм, который, как оказалось, Squid и использует. На этом предлагаю дискуссию прекратить. За статью вам в любом случае +.
P.S. Смотрю, вы тоже не туда ответили. Если вы отвечали на тот комментарий с синим заголовком, который появился при автообновлении, то это похоже на баг habrahabr.Опять UPD: Нет, просто мы с вами создали слишком длинную ветку :-)nagibat0r
09.12.2015 20:05+2А я и хотел донести, что Кальмар и использует этот алгоритм) Дискуссия длинная получилась, да=)
kafeman
09.12.2015 18:54+1Прочитал документацию, вопрос отпал. Squid не делает своих запросов, а лишь частично передает запросы клиента до тех пор, пока не сможет получить имя хоста.
Таким образом, проблем с двумя доменами при такой конфигурации быть не должно.nagibat0r
09.12.2015 18:55+1вот я и склоняюсь к этому, просто не до конца понял документацию по этому вопросу. Завтра протестирую
Sleuthhound
09.12.2015 20:27А почему Вы используете старую версию libressl, когда доступна уже 2.3.2?
Буквально вчера я с последней libressl собирал squid 3.5.12 нс debian 8.2 x64 — проблем со сборкой через dpkg-buildpackage не возникло. Правда добиться работы в прозрачном режиме не удалось с первого напрыга, а т.к. был первый час ночи то я пошёл спать. На днях ещё повоюю с версией 3.5.12
Вопрос в другом, если Вы контактировали с разработчиками squid то как они обьясняют нестабильность работы версий после 3.5.12?nagibat0r
09.12.2015 20:40Потому что именно эта версия протестирована и работает стабильно. А насчет остальных не уверен.
По поводу нестабильности новых версий Squid. Разработчики именно этот вопрос уже три раза оставляли незакрытым. Оставлял багтреки, но разработчики просто переставали отвечать там.Sleuthhound
09.12.2015 21:31Любопытная вещь с squid 3.5.12, собрал его с опциями (--enable-ssl --enable-ssl-crtd --with-openssl), но при squid -k parse выводит
2015/12/09 22:48:56| Took 0.00 seconds ( 0.00 entries/sec).
FATAL: Unknown SSL option 'NO_SSLv3'
Squid Cache (Version 3.5.12): Terminated abnormally.
и то же самое на NO_SSLv2
куда девались эти опции? по документации http://www.squid-cache.org/Versions/v3/3.5/cfgman/http_port.html они должны быть.
на SINGLE_DH_USE ругани нет
посмотрел diff между 3.5.10 и 3.5.12, там ничего криминального нет по вырезанию этих опций, в общем загадка.
что более интересно, без NO_SSLv2 и NO_SSLv3 все прекрасно работает и ограничение по https тоже, старые баги с https://mail.ru и некоторыми другими сайтами которые наблюдались на squid 3.5.10 исчезли, остается вопрос производительности и не начнет ли валиться squid 3.5.12 когда к нему полезут 50-100 человек, собственно это я выясню завтра в течении дня запустив фильтрацию на выборочной группе пользователей из офиса.nagibat0r
09.12.2015 21:32режим работы прокси — прозрачный?
Sleuthhound
10.12.2015 07:15Да, прозрачный.
В общем 3.5.12 не готов пока для прозрачного проксирования https, возникают какие-то глюки. То странички по https открываются очень долго, и как правило в результате не открываются вообще, причем выборочно на разных разделах одного и того же сайта по https.
nagibat0r
09.12.2015 21:35Вообще, пообщавшись по почте с некоторыми разработчиками, удалось кое-что выяснить. Они «что-то сломали там», еще когда сделали 3.5.9. И никто не обращал внимания. Теперь, чтобы исправить, необходимо много переписывать, дабы не потерять текущий функционал, а добавилось его немало. В частности меня интересует, что с версии 3.5.9 в логи при прозрачном проксировании попадают не просто ip адреса HTPS ресурсов, а имена доменов.
d7s2di
10.12.2015 15:17Как-то не красиво выглядит использование checkinstall'a и сгенеренные им недопакеты ( особенно, если планируется их передавать куда-то дальше локалхоста), проще такой самосбор выносить в /opt, мне думается.
А вообще, стоит пользоваться специально предназначенными для таких вещей инструментами, например, набором devscripts, в частности uupdate. Делается это как-то так:
apt-get build-dep squid3 apt-get source squid3 wget http://www.squid-cache.org/Versions/v3/3.5/squid-3.5.8.tar.gz cd squid* uupdate --upstream-version 3.5.8 ../squid-3.5.8.tar.gz debuild -i -us -uc -b dpkg -i ../*3.5.8*deb
И это будут нормальные пакеты с деревом зависимостей. Там же можно наложить дополнительные патчи и указать директивы сборки.nagibat0r
10.12.2015 15:48Ну да, в прошлой статье именно так я и делал. Так что ничего нового) А я написал в статье, что этот способ не работает по причине отсутствия «дебианезированных» исходников 3.5.7
d7s2di
10.12.2015 15:52Кхм-кхм. Собственно для отсутствия «дебианезированных» исходников более новой версии, и существует uupdate, «дебианизирующий» новую версию на основе старой дистрибутивной.
nagibat0r
10.12.2015 15:53Кхм кхм, а как Вы, собственно, хотите сделать uupdate с версии 3.5.10 до 3.5.8 (не опечатка)?
Вы, вероятно, не совсем поняли. В репозитории. как я и написал, отсутствуют нужные исходники. А есть 3.5.10, которая нам не подходит. Подходит только 3.5.8, и никакая другая!nagibat0r
10.12.2015 15:58точнее подходит именно для способа из первой статьи версия исходников из репозитория только 3.5.7 (для обновления до 3.5.8). Если взять версию постарше, например 3.5.4, то обновление произойдет некорректно, и компиляция не пройдет. Проверено
d7s2di
10.12.2015 16:05> uupdate с версии 3.5.10 до 3.5.8 (не опечатка)?
$apt-cache policy squid3 squid3: Установлен: (отсутствует) Кандидат: 3.4.8-6+deb8u1 Таблица версий: 3.4.8-6+deb8u1 0 500 http://security.debian.org/ jessie/updates/main amd64 Packages 3.4.8-6 0 500 http://mirror.yandex.ru/debian/ jessie/main amd64 Packages
На самом деле, нужно будет грохнуть версия-зависимые патчи и, по-хорошему, поправить rules с учетом пожеланий к сборке.nagibat0r
10.12.2015 16:07я провел над этим делом три дня, но так и не заставил собраться нормальные пакеты этим способом, плюс были проблемы именно в архитектуре х64. Поэтому checkinstall стал более простым способом. К тому же, позволяет rpm генерировать. Недостатки, которые в статье описаны, связаны с правилами сборки. Надо просто покурить их, пока нет возможности, болею
d7s2di
10.12.2015 16:22+1Тогда выздоравливайте. Я checkinstall недолюбливаю из-за его неприятной особенности: он не собирает пакет с последующей установкой, а отслеживая происходящие изменения на файловой системе, уже генерит пакет. И действие dpkg -i здесь уже излишне.
Соответственно, если checkinstall споткнется и вывалится с ошибкой, то помойку придется вычищать руками или надеяться на работспособность make uninstall. И наша операционная система начинает превращаться в слаку.
Потому куда правильнее делать
./configure --prefix=/opt/`basename $(pwd)`
Перенос содиржимого opt'a на другую машину куда менее болезнен, чем порожденных чекинсталлом недопакетов.
Ну это я так, побухтеть. На одной из прошлых работ вдоволь накушался вкривь и вкось собранного непонятно как и чем непотребства.nagibat0r
10.12.2015 19:42почитал, усвоил кое что, спасибо. На самом деле, с чекинсталлом я ранее дело имел редко, потому что я по тем же причинам его недолюбливаю=) просто пришлось из-за того, что я писал выше. Самое идеальное — найти репозиторий, хоть где, где есть «дебианизированные» исходники squid 3.5.7, но я не нашел. Был бы несказанно рад, если кто-то все таки его найдет
ArjLover
11.12.2015 03:00Существуют ли какие-то аналогичные решения магистрального масштаба?
Ну и конечно интересно как от этой блокировки защититься? А то что-то оружие блокировки стало последнее время побеждать.nagibat0r
11.12.2015 17:061) что Вы имеете в виду под словами «магистральный масштаб»?
2) защита от блокировки — использовать другой прокси, к примеру, выставив вручную настройки в браузере. Но я, например, в своей конторе запретил использование сторонних прокси и DNS, и порты у нас открыты только определенные. Система работает уже несколько месяцев, пока не было случаев обхода
k3NGuru
14.12.2015 08:58В очередной раз спасибо за статью!
Но хотелось бы узнать, как грамотно настроить данный прозрачный Squid, если не делать его шлюзом по умолчанию. Так как в качестве шлюза стоит роутер.nagibat0r
14.12.2015 11:29Не за что. Если Вы хотите иметь прозрачный прокси, то он должен быть обязательно шлюзом для Ваших ПК, иначе Вас прокси пускать не будет. Статически — пожалуйста, хоть в другую подсеть его убирайте.
Dimonyga
17.12.2015 09:12Смотря что за шлюз, если это cisco — используйте WCCP. Если это не циско — заворачивать роут-мапами. Если это Linux роутер — используйте DNAT, но при его использовании наверное придется отказаться от tproxy так как нужно разделять трафик уже прошедший через squid и еще не прошедший. Хотя при наличии 2-х интерфейсов в squid — и этот вопрос решаемый.
nagibat0r
14.12.2015 16:26+2Ребята, читаем!
UPD 14.12.15: спешу поделиться с коллегами отличной новостью! Я нашел способ заставить работать новые версии Squid'а без особых танцев с бубном! Необходимо, чтобы у клиентов и в настройках Squid'а были одинаковые DNS! В моем случае, на шлюзе с Кальмаром крутится Bind. Назначил клиентам именно его, и Кальмару директивой:
dns_nameservers 127.0.0.1
. После чего все успешно заработало. Проверено на Squid 4.0.3, собрана БЕЗ Libressl!
Прошу протестировать
wmlex
16.12.2015 11:00Вот пакеты: Squid, Libressl, Libecap для CentOS 7.2.
Cобирал вот отсюда
Libressl
Squid
Squid собран с патчем bio.cc. Libressl я не ставил, у меня работает и без него, и не применял ключ --enable-ssl, так как в этой статье про него ничего нет.
squid-3.5.8-4.el7.centos.x86_64.rpm
squid-debuginfo-3.5.8-4.el7.centos.x86_64.rpm
squid-helpers-3.5.8-4.el7.centos.x86_64.rpm
libecap-1.0.0-3.el7.centos.x86_64.rpm
libecap-devel-1.0.0-3.el7.centos.x86_64.rpm
Если будут проблемы с openssl вот пакеты libressl
libressl-2.3.0-1.el7.awel.libre.x86_64.rpm
libressl-libs-2.3.0-1.el7.awel.libre.x86_64.rpm
nikitasius
Положу в копилку допила «детского файрвола». Сейчас всякая всплывающая зараза имеет https сертификаты.
nagibat0r
Да, это верно. Тем более, что получить сертификат бесплатно сейчас не особо и сложно