Ведущий сисадмин, тыжпогромист
0,0
рейтинг
9 декабря 2015 в 15:13

Администрирование → «Прозрачный» Squid с фильтрацией HTTPS ресурсов без подмены сертификатов (х86, х64 — универсальная инструкция) tutorial

Всем привет! Прошлая статья про прозрачное проксирование HTTPS с помощью Squid'a была вполне успешной. Приходило по почте множество отзывов об успешной установке данной системы. Но также и поступали письма с просьбами о помощи. Проблемы были вполне решаемыми. Но не так давно обратилась ко мне одна коллега с просьбой о помощи в установке этой системы на х64 архитектуре (Debian). Тут мы озадачились. Во-первых, оказалось, что прошлая статья непригодна для этого по причине отсутствия нужных исходников в репозитории Debian (там теперь 3.5.10). Найти нужные в первой статье Debian'овские исходники не удалось, а checkinstall выдавал странные ошибки. Во-вторых, хотелось более универсального решения, которое бы без проблем работало и на х64, и на х86, и (по-возможности) на других дистрибутивах. Решение было найдено. Получилось небольшое дополнение к предыдущей статье + некоторые уточнения. Данная инструкция позволяет скомпилировать как х86, так и х64 версии Squid'a и создать соответствующие пакеты. Инструкция будет разбита на несколько пунктов и подпунктов. Если интересно, идем под кат:
Идем по-порядку.
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.
а) Качаем последний самый работающий снэпшот 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


Заголовок спойлера
Да, все верно, получился всего один файл, в то время как в предыдущей статье их было несколько, как и принято в Debian.


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


Заголовок спойлера
На самом деле, этот самый сервис есть в архиве с исходниками Squid'a. По каким причинам Checkinstall его не включил в пакет, не известно.


Включим созданный сервис
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
           └─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 такая система корректно работать не будет…
У них как правило пачка доменов в сертификатах.
В случае, если example.com находится в одном сертификате с freepron.cum, кальмар сработает на freepron, если последний в локальном бане, так?
Так вот, проверил. Добавил один из его доменов из Cloudflare в черный список блокировки HTTPS, на него браузер не заходит, но на другие домены, которые прописаны в сертификате, браузер спокойно заходит. Так что, проверка Cloudflare пройдена

UPD 14.12.15: спешу поделиться с коллегами отличной новостью! Я нашел способ заставить работать новые версии Squid'а без особых танцев с бубном! Необходимо, чтобы у клиентов и в настройках Squid'а были одинаковые DNS! В моем случае, на шлюзе с Кальмаром крутится Bind. Назначил клиентам именно его, и Кальмару директивой:
dns_nameservers 127.0.0.1
. После чего все успешно заработало. Проверено на Squid 4.0.3, собрана БЕЗ Libressl!


UPD 16.12.15: Пакеты для Centos!

UPD 25.04.16: Просьба для тех, кто тестировал х64 сборку написать, все ли работает. Есть сообщения о глюках, в частности сильная нагрузка на ЦП после истечении некоторого времени и последующий сегфолт. Сам проверить пока-что не могу
Для тех, кто думает, что это MITM =)
В опросе последний пункт конечно же шуточный=) Если ВНИМАТЕЛЬНО прочитать предыдущую статью, то сразу станет ясно, что никакой атаки на пользователя нет, так как не происходит подмены сертификатов!!!
Вы уже установили Squid c прозрачным проксированием HTTPS?

Проголосовало 212 человек. Воздержалось 95 человек.

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

Никита Парфенович @nagibat0r
карма
24,0
рейтинг 0,0
Ведущий сисадмин, тыжпогромист
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Спецпроект

Самое читаемое Администрирование

Комментарии (68)

  • +1
    Положу в копилку допила «детского файрвола». Сейчас всякая всплывающая зараза имеет https сертификаты.
    • 0
      Да, это верно. Тем более, что получить сертификат бесплатно сейчас не особо и сложно
  • 0
    Даное решение позволяет фильтровать определенные страницы на wikipedia.org?
    Например разрешить доступ на Wikipedia, но запретить доступ на uk.wikipedia.org/wiki/HTTPS?
    Клиентский браузер не ругается на сертификат?
    • 0
      Прочтите предыдущую статью, все будет ясно.
      Так как для блокировки используется данные из sni_info (конкретно server_name), то заблокировать отдельные страницы не получится. Браузеры на сертификат не ругаются, так как это не является MITM-атакой! Сертификат не трогается и не подменяется.
      • 0
        Squid подключается к HTTPS ресурсу, получает его сертификат, и может «посмотреть» некоторые данные о ресурсе, в частности имя сервера, которое нам как раз и нужно для блокировки!

        Значит он здесь может посмотреть адрес сервера и полный URL к запрашиваемой странице? Или только адрес сервера(домен)?
        • 0
          Только адрес сервера, судя по документации на оф.сайте
          • 0
            Ясно, большое спасибо. Меня именно это и интересовало.
            • +1
              Не за что! Я думаю, вскоре найдется способ блокировки отдельных страниц. Это уже сделано, в принципе. Только режим работы Кальмара должен быть НЕ прозрачным. Меня же интересовала тема именно прозрачного проксирования HTTPS
          • 0
            Наверное вопрос глупый, но: имя сервера он берет просто потому, что подключается к этому самому серверу или из данных сертификата?
            • +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-атаки
              • 0
                Видимо для сайтов, которые за Cloudflare такая система корректно работать не будет…
                У них как правило пачка доменов в сертификатах.
                В случае, если example.com находится в одном сертификате с freepron.cum, кальмар сработает на freepron, если последний в локальном бане, так?
                • +1
                  Получается, что да. Если заблокировать, к примеру, mail.ru, то перестает работать Аська, так как у них же она и располагается. Хотя надо проверить
                  • 0
                    Спасибо!
                • 0
                  кальмар сработает на freepron, если последний в локальном бане

                  и freepron утащит с собой example.com так как они в одном сертификате?
                  • +1
                    это надо протестировать, я с этим не сталкивался…
                • 0
                  А если дополнительно использовать SNI?
                  • 0
                    так вся эта система на SNI и завязана!
                    • +1
                      Но вы писали:
                      Имя сервера он получает из сертификата. Процесс очень несложный. Кальмар представляется клиентом, «открывает» ресурс, получает сертификат и смотрит sni_info, откуда берет server_name.
                      В варианте с SNI никаких connection probe делать не нужно. И сертификат парсить тоже. Вы просто извлекаете из перехватываемых пакетов имя хоста, которое передается в открытом виде (без шифрования).

                      У меня сейчас нет под рукой Wireshark'а, но можете проверить сами.

                      UPD: Не до конца дочитал тот кусок, который сам же и процитировал.
                      получает сертификат и смотрит sni_info, откуда берет server_name
                      Я не знаком со сквидом, но почему нельзя было посмотреть содержимое sni_info сразу, без запроса сертификата? И не будет проблем, о которых писал nikitasius.
                      • 0
                        Я знаю, как устроены пакеты. И каким же образом Вы хотите в Squid'e это провернуть? Боюсь, что это выходит за рамки данной статьи. К тому же, я считаю, что легче использовать SNI в самом Кальмаре. Результат тот же самый! SNI — это некая информация, которая доступна во время процесса handshake, т.е. рукопожатия. А handshake предусматривает получение клиентом сертификата. Зачем перехватывать какие-то пакеты, если Кальмар итак уже получил SNI_INFO
                        • 0
                          Я исхожу из того, что мы пытаемся сейчас решить следующую проблему:
                          В случае, если example.com находится в одном сертификате с freepron.cum, кальмар сработает на freepron, если последний в локальном бане, так?
                          В случае, если вы перехватите запрос пользователя, то вы сможете узнать, какой ресурс был запрошен на самом деле: freepron.com или example.com.

                          В случае, если вы сделаете запрос сами, вы лишь узнаете, что это либо freepron.com, либо example.com.

                          Либо я вас не правильно понял.
                          • +1
                            Вопрос товарища nikitasius еще нужно проверить, так как я не сталкивался с такими сертификатами. Но Ваше утверждение требует глобального вмешивания в трафик пользователя, что является потенциальной дырой в безопасности. К тому же, я еще раз повторюсь, не представляю, как это все сделать в связке с Кальмаром. Если есть реальная идея, с удовольствием посмотрю
                            • 0
                              Как я уже сказал, у меня сейчас нет возможности поснифить свой трафик. Вот первая попавшаяся картинка из Google. Суть в том, что имя запрашиваемого хоста можно получить в открытом виде.

                              Насколько я понял по сайту Squid, последний так и делает.

                              UPD: Торопился и не туда ответил. Это ответ на комментарий nagibat0r выше.
                              • 0
                                можно, оно и не шифруется, но Squid итак смотрит именно эту информацию. Поэтому смысла парсить трафик не вижу.
                                • 0
                                  Похоже, мы говорим с вами об одном и том же, просто на разных уровнях абстракции. Вы мне про конфиг Squid, а я вам про сам алгоритм, который, как оказалось, Squid и использует. На этом предлагаю дискуссию прекратить. За статью вам в любом случае +.

                                  P.S. Смотрю, вы тоже не туда ответили. Если вы отвечали на тот комментарий с синим заголовком, который появился при автообновлении, то это похоже на баг habrahabr. Опять UPD: Нет, просто мы с вами создали слишком длинную ветку :-)
                                  • +2
                                    А я и хотел донести, что Кальмар и использует этот алгоритм) Дискуссия длинная получилась, да=)
                        • +1
                          Прочитал документацию, вопрос отпал. Squid не делает своих запросов, а лишь частично передает запросы клиента до тех пор, пока не сможет получить имя хоста.

                          Таким образом, проблем с двумя доменами при такой конфигурации быть не должно.
                          • +1
                            вот я и склоняюсь к этому, просто не до конца понял документацию по этому вопросу. Завтра протестирую
  • 0
    А почему Вы используете старую версию libressl, когда доступна уже 2.3.2?
    Буквально вчера я с последней libressl собирал squid 3.5.12 нс debian 8.2 x64 — проблем со сборкой через dpkg-buildpackage не возникло. Правда добиться работы в прозрачном режиме не удалось с первого напрыга, а т.к. был первый час ночи то я пошёл спать. На днях ещё повоюю с версией 3.5.12
    Вопрос в другом, если Вы контактировали с разработчиками squid то как они обьясняют нестабильность работы версий после 3.5.12?
    • 0
      Потому что именно эта версия протестирована и работает стабильно. А насчет остальных не уверен.
      По поводу нестабильности новых версий Squid. Разработчики именно этот вопрос уже три раза оставляли незакрытым. Оставлял багтреки, но разработчики просто переставали отвечать там.
      • 0
        Любопытная вещь с 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 человек, собственно это я выясню завтра в течении дня запустив фильтрацию на выборочной группе пользователей из офиса.
        • 0
          режим работы прокси — прозрачный?
          • 0
            Да, прозрачный.

            В общем 3.5.12 не готов пока для прозрачного проксирования https, возникают какие-то глюки. То странички по https открываются очень долго, и как правило в результате не открываются вообще, причем выборочно на разных разделах одного и того же сайта по https.
            • 0
              то же самое, что и во всех версиях, начиная с 3.5.9. Печально=(
    • 0
      Вообще, пообщавшись по почте с некоторыми разработчиками, удалось кое-что выяснить. Они «что-то сломали там», еще когда сделали 3.5.9. И никто не обращал внимания. Теперь, чтобы исправить, необходимо много переписывать, дабы не потерять текущий функционал, а добавилось его немало. В частности меня интересует, что с версии 3.5.9 в логи при прозрачном проксировании попадают не просто ip адреса HTPS ресурсов, а имена доменов.
  • 0
    Как-то не красиво выглядит использование 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
    


    И это будут нормальные пакеты с деревом зависимостей. Там же можно наложить дополнительные патчи и указать директивы сборки.
    • 0
      Ну да, в прошлой статье именно так я и делал. Так что ничего нового) А я написал в статье, что этот способ не работает по причине отсутствия «дебианезированных» исходников 3.5.7
      • 0
        Кхм-кхм. Собственно для отсутствия «дебианезированных» исходников более новой версии, и существует uupdate, «дебианизирующий» новую версию на основе старой дистрибутивной.
        • 0
          Кхм кхм, а как Вы, собственно, хотите сделать uupdate с версии 3.5.10 до 3.5.8 (не опечатка)?

          Вы, вероятно, не совсем поняли. В репозитории. как я и написал, отсутствуют нужные исходники. А есть 3.5.10, которая нам не подходит. Подходит только 3.5.8, и никакая другая!
          • 0
            точнее подходит именно для способа из первой статьи версия исходников из репозитория только 3.5.7 (для обновления до 3.5.8). Если взять версию постарше, например 3.5.4, то обновление произойдет некорректно, и компиляция не пройдет. Проверено
          • 0
            > 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 с учетом пожеланий к сборке.
            • 0
              я провел над этим делом три дня, но так и не заставил собраться нормальные пакеты этим способом, плюс были проблемы именно в архитектуре х64. Поэтому checkinstall стал более простым способом. К тому же, позволяет rpm генерировать. Недостатки, которые в статье описаны, связаны с правилами сборки. Надо просто покурить их, пока нет возможности, болею
              • +1
                Тогда выздоравливайте. Я checkinstall недолюбливаю из-за его неприятной особенности: он не собирает пакет с последующей установкой, а отслеживая происходящие изменения на файловой системе, уже генерит пакет. И действие dpkg -i здесь уже излишне.

                Соответственно, если checkinstall споткнется и вывалится с ошибкой, то помойку придется вычищать руками или надеяться на работспособность make uninstall. И наша операционная система начинает превращаться в слаку.

                Потому куда правильнее делать
                ./configure --prefix=/opt/`basename $(pwd)`
                


                Перенос содиржимого opt'a на другую машину куда менее болезнен, чем порожденных чекинсталлом недопакетов.

                Ну это я так, побухтеть. На одной из прошлых работ вдоволь накушался вкривь и вкось собранного непонятно как и чем непотребства.
                • 0
                  почитал, усвоил кое что, спасибо. На самом деле, с чекинсталлом я ранее дело имел редко, потому что я по тем же причинам его недолюбливаю=) просто пришлось из-за того, что я писал выше. Самое идеальное — найти репозиторий, хоть где, где есть «дебианизированные» исходники squid 3.5.7, но я не нашел. Был бы несказанно рад, если кто-то все таки его найдет
  • 0
    Существуют ли какие-то аналогичные решения магистрального масштаба?
    Ну и конечно интересно как от этой блокировки защититься? А то что-то оружие блокировки стало последнее время побеждать.
    • 0
      1) что Вы имеете в виду под словами «магистральный масштаб»?
      2) защита от блокировки — использовать другой прокси, к примеру, выставив вручную настройки в браузере. Но я, например, в своей конторе запретил использование сторонних прокси и DNS, и порты у нас открыты только определенные. Система работает уже несколько месяцев, пока не было случаев обхода
      • 0
        запретил использование сторонних прокси и DNS

        не подскажете, каким образом?
  • 0
    В очередной раз спасибо за статью!
    Но хотелось бы узнать, как грамотно настроить данный прозрачный Squid, если не делать его шлюзом по умолчанию. Так как в качестве шлюза стоит роутер.
    • 0
      Не за что. Если Вы хотите иметь прозрачный прокси, то он должен быть обязательно шлюзом для Ваших ПК, иначе Вас прокси пускать не будет. Статически — пожалуйста, хоть в другую подсеть его убирайте.
    • 0
      Смотря что за шлюз, если это cisco — используйте WCCP. Если это не циско — заворачивать роут-мапами. Если это Linux роутер — используйте DNAT, но при его использовании наверное придется отказаться от tproxy так как нужно разделять трафик уже прошедший через squid и еще не прошедший. Хотя при наличии 2-х интерфейсов в squid — и этот вопрос решаемый.
      • 0
        Стоит у нас Zyxel Zywall.
        Там уже есть http_redirect но там только 1 порт можно указать (312#)
        Думал Route сделать. НО пока времени не хватает.
  • +2
    Ребята, читаем!
    UPD 14.12.15: спешу поделиться с коллегами отличной новостью! Я нашел способ заставить работать новые версии Squid'а без особых танцев с бубном! Необходимо, чтобы у клиентов и в настройках Squid'а были одинаковые DNS! В моем случае, на шлюзе с Кальмаром крутится Bind. Назначил клиентам именно его, и Кальмару директивой:
    dns_nameservers 127.0.0.1
    . После чего все успешно заработало. Проверено на Squid 4.0.3, собрана БЕЗ Libressl!


    Прошу протестировать
    • 0
      Ключи, при сборке пакета, остались прежними?
    • 0
      И что за ключ "--enable-ssl" в ./configure --help его нет.
      • 0
        вообще ключ включает в Кальмаре поддержку SSL
        • 0
          Покажите мне его пожалуйста в официальной документации. В файле configure, в исходниках, такого ключа нет.
        • 0
          Отвечаю на свой же вопрос. В версии Squid 3.5 удалена "--enable-ssl" поэтому используем только "--with-openssl".
          пруф
  • 0
    Вот пакеты: 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
    • 0
      огромное спасибо! Перенесу Ваш коммент в статью!!!
  • 0
    del
  • 0
    Автор, вы меня заинтриговали. Достойная работа! Я уже все интернеты перерыл в поисках нормального решения без костылей в виде прописывания прокси и подмены сертификатов. Надеюсь вскоре нечто подобное будет доступно в PFSense, ибо думаю не осилю Вашу инструкцию…
    • 0
      Спасибо, что читаете. Инструкция легкая, если используете Debian 8 / Archlinux =) Насчет остальных дистрибутивов не скажу, не пробовал. В PFSense в ближайшее время не будет такое доступно ;-)
  • 0
    Вопрос такой — в случае ubuntu 14.04 схема сильно изменится, как думаете?
    в принципе я по вашей инструкции все сделал, но в репах только 3.3.8, так что "возможны нюансы"
    • 0
      В общем-то у меня сквид собрался и даже запустился, все гуд.
      Но при попытке проксировать https я получаю ошибку сертификата, т.е. сквида таки пытается подменить сертификат на свой. как с этим быть — нипанятна...
      • 0
        логи, логи, логи) при таком конфиге Кальмар просто не может подменять сертификат.
  • 0
    https://kias.rfbr.ru/
    не пашет
    • 0
      не актуально, сорри
  • 0
    Народ, кто тестировал х64, отпишитесь, все ли работает? Есть пара сообщений о глюках (Debian x64 Jessie), мол по истечении времени нагрузка на ЦП 100% и сегфолт…
    • 0

      Работает, только тестил не долго еще Бубунта 16.04.
      Собирал по вашему мануалу (3.5.8 пока только), пришлось поправить в bio.cc и support.cc везде где ругался на SSLv3… на SSLv23… (LIbreSSL стоит 2.4.1 из реп)
      Почему то не видит в options= параметры NO_SSLv3, NO_SSLv2, пришлось убрать.

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