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

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

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

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


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

Итак, для начала немного теории. Как мы все знаем, 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 адресов. Но и тут меня ждали несколько разочарований, о которых речь пойдет ниже. Но всё, как говорится, допиливается напильником.

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

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

Собирать Squid ручками или ставить готовые пакеты (ссылки ниже), решать вам. Если вы думаете, что я впендюрил в них блекджек и ш… вирусы, то компильте сами. Также компилировать нужно, если у вас дистрибутив другой (если Убунта, то поставите). Собирать мы будем версию Squid 3.5.23, которая на момент написания статьи валяется в репозитории Stretch, повысив ее до свежих исходников 3.5.27 с оф.сайта. Также нам понадобится для этих дел libecap, его мы тоже соберем. В отличие от моей первой статьи про 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 будет либо лагать, либо не соберется вовсе из-за непонятных ошибок


Далее получаем исходники Squid 3.5.23

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

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

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

<b>client_side_request.patch</b>

--- 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, поставив перед ним знак #:

#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 матерится на зависимости, сделайте

apt-get -f install

Далее нужно выключить Squid из автозагрузки (по умолчанию используется init файл, Squid жалуется на недоступность PID файла)

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.
##

[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 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

Замечание
Вы можете использовать и не regex, можно использовать dstdomain, также можно «прикрутить» списки с неправомерно заблокированными подсетями (dst)

Более подробно про этот формат списка читайте в оф документации. Результат себя долго ждать не заставил — все заработало, как и было запланировано. И работает по сей день. Возможно, со статьей опоздал, но она, вероятно, пригодится в будущем).

Тему буду пополнять по возможности.

Готовые пакеты Squid и Libecap (.deb x86)

UPD 04.05.18: можно добавить в torcc строчку
HTTPTunnelPort 8118

и в принципе отказаться от Privoxy. Спасибо dartraiden за замечание

Найден баг. Не рекомендуется использование HTTPTunnelPort, Privoxy нужен пока-что, пока не закроется вот это. Спасибо Юрию Воинову!

Также поправил статью по части libecap3. Не нужно компилировать ничего, а просто установить из репозитория Stretch. Спасибо AlucoST за замечание

UPD 05.05.18: товарищ dartraiden подсказывает, что в конфиг Tor можно добавить
ExcludeExitNodes {ru}, {ua}, {by}

Это исключает использование выходных узлов в указанных странах

Огромное спасибо Юрию Воинову, который помогал в решении проблем с работой данной связки!

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


  1. LAG_LAGbI4
    03.05.2018 21:10
    -1

    Какая-то очень страшная дичь. Я пытался что-то понять, но не смог. Зачем это нужно? Для посещения сайтов можно использовать бесплатный vpn. Можно использовать обычный тор. Если всё плохо можно использовать vps с vpn. В чём приемущество описанного в статье метода, я не понял


    1. proton17
      04.05.2018 06:56
      +1

      Я так понимаю, что это решение для конторы, а не для себя любимого. У нас на работе, например, инет тоже за прокси, и естественно телеграмм не работает. Наши админы нас послали куда подальше, а вместо этого подсунули нам некий говно-чат с локальным серваком к которому нет доступа из внешнего мира, соответственно нет доступа с смартфона, вот и нах оно нам надо. А тут люди сделали сотрудникам хорошо.


      1. nagibat0r Автор
        04.05.2018 07:11

        Верно. Решение для конторы. С 0руб потраченных средств


        1. awesomer
          04.05.2018 08:27

          1) Для конторы не хватит производительности

          2) Конторе 0 рублей потраченных средств (при том что речь идет о смешных суммах — VPN можно и от 1 доллара в месяц найти, ну а за 5 долларов — вы получите гарантировано отличнейшую производительность) — не довод вообще.

          Конторе важно чтобы оно работало, а не сэкономить 3 копейки.

          3) Tor — это средство анонимизации. В отличие от простого VPN. Вопрос — а чем занимается ваша контора, что нуждается в таком?


          1. nagibat0r Автор
            04.05.2018 08:30

            Для нас то, что описывается в статье, является нормальным решением. Производительности нам хватает.


            1. awesomer
              04.05.2018 08:41

              является нормальным решением


              И Гугль всегда нормально работает?

              Я вот наблюдаю как при подключении через Тор так Гугль постоянно:
              1) Как минимум запрашивает Капчу решать.
              2) А иногда и просто — блокирует, и Капчу не предлагает.

              Яндекс чуть добрее — но в принципе такой же подозрительный.


              1. nagibat0r Автор
                04.05.2018 08:44

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


      1. scruff
        04.05.2018 08:10

        VPS с VPN разве трудно используется на работе? Самое простое прописать на проксе маршруты до Telegram-a через VPN.


        1. LAG_LAGbI4
          04.05.2018 08:15

          Согласен для конторы заплатить 5 баксов за терабайт заблокированного трафика гораздо разумнее. Надёжность и скорость этого решения будет выше.


          1. nagibat0r Автор
            04.05.2018 08:28

            Надежность — под вопросом. Если VPS попадет в список блокировки? Да и я уже сказал, что прокси итак уже есть. Прозрачный, без MITM и так далее. Поэтому захотелось его научить обходить блокировки. А так как решения в Интернетах по этому поводу были не совсем рабочие для моего случая, сделал так, чтобы работало)


            1. awesomer
              04.05.2018 08:49

              Надежность — под вопросом. Если VPS попадет в список блокировки?


              Надежность под вопросом у Тора.
              Гугль-Яндекс практически всегда требуют капчу решать. Но! Иногда и капча не помогает — просто нода Тора заблокирована у них намертво — и живи со своим прокси как хочешь

              VPS с вашим личным IP (не shared) на небольшом хостере — никуда не попадает ни в какие списки.
              Да и производительность у VPN существенно выше, чем у Tor


              1. nagibat0r Автор
                04.05.2018 08:53

                У Гугль-Яндекса капча вводится в поисковиках, насколько я знаю? Я уже сказал, что поисковик идет напрямую. Яндекс в принципе никак не трогал, он итак работает. Бывают проблемы с Youtube, пустил его через Tor — он работает. Скорость вполне приемлемая. И я написал, почему использовал именно так, как использовал. VPS\VPN — другая история.


                1. awesomer
                  04.05.2018 09:02

                  У Гугль-Яндекса капча вводится в поисковиках, насколько я знаю?


                  Нет, не только одной капчой дело ограничивается.

                  Нередко и капча не помогает.

                  Тебе сразу выдают страничку — что твой IP (IP выходной ноды Tor) заблокирован.
                  Иногда не сразу, иногда после парочки поисковых запросов.

                  Это очень даже нередкое поведение.


                  1. nagibat0r Автор
                    04.05.2018 09:08

                    Про это я в курсе, но в который раз говорю, что поисковики идут напрямую :) если Вас наводит на мысль, что весь гугл (в т.ч.) поиск идет у нас через Тор, то вероятно дело в списке url_regex, который в статье. Он дан для примера. У меня список совсем другой.


                    1. HiMyNameIs
                      05.05.2018 08:53
                      +1

                      в который раз говорю
                      Очевидно же, что говорить бесполезно. Это один из тех, кто знает про ВПН из СМИ, но никогда не пробрасывал и даже не в курсе про маршруты, и уж тем более не знает, как это раньше было при наличии локалки и подключению к инету по впн по пакетам.


                      1. nagibat0r Автор
                        05.05.2018 09:41

                        Согласен)


            1. scruff
              04.05.2018 14:37

              В случае блокировки… поднимаете два VPN-а в географически разных регионах. И с откзоустойчивостью сразу получаете NLB при наличии прямых рук и светлого ума.


            1. scruff
              04.05.2018 14:39

              Да кстати, если Компания большая и имеет бранчи в разных странах, то к VPN-у добавляется еще и бесплатность.


              1. nagibat0r Автор
                04.05.2018 14:52

                И сколько нужно будет поднимать VPS с VPN в случае частых блокировок? Tor не заблокируют. Есть obfs. И на Squid можно сделать round robin на несколько cache peer, запустить несколько Tor'ов с разными конфигами, получится HA. И проблема скорости, в принципе, тоже будет решена. И еще бесплатно «искаропки»


        1. nagibat0r Автор
          04.05.2018 08:26

          Дело не в телеграме, он итак работает без проксей.
          VPS с VPN — это хорошо. Но у меня Squid итак работает, прокси нужен. Поэтому было решено попробовать его научить обходить блокировки РКН.


      1. navion
        04.05.2018 12:11

        Для конторы лучше решение с BGP — проще настройка и нет лишней точки отказа.


        1. nagibat0r Автор
          04.05.2018 12:34

          Тоже хорошо. Свои плюсы и минусы. Насчет «проще» — ну не знаю. В моём случае можно не париться с компиляцией и красноглазием, а поставить пакеты и накатить конфиг. Работа сводится только к созданию списка антиблокировок. Но решение с BGP, безусловно, заслуживает внимания. Просто это другой подход)


    1. nagibat0r Автор
      04.05.2018 07:10

      Преимущество в том, что не надо покупать VPS, который, к слову, тоже может попасть в блокированные подсети из-за сами знаете чего. Бесплатный VPN? И какая скорость там будет, учитывая что сейчас куча народу используют бесплатные VPN? На Tor скорость в наше время повыше, чем на бесплатных VPN


      1. awesomer
        04.05.2018 08:34

        Преимущество в том, что не надо покупать VPS


        Если вы школьник — то, да, это довод.
        Вы то позицируете сие решение для конторы, как вы сами тут написали habr.com/post/354708/#comment_10788154
        А стоимость VPS смешная.

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


        Если это не публичный VPN, то никуда он не попадет.
        Не заводите его на Amazon, заведите у мелкого хостера — и никаких случайных блокировок вам.

        Решение через Tor крайне медленное.
        На фоне скорости Tor и копеечных затрат на другой-второй-третий VPS довод про блокировку VPS, которая не более чем случайна — притянут за уши.

        Вы банально через Tor не сможете полноценно пользоваться google.com — ибо Google сам блокирует частенько ноды Tor.


        1. nagibat0r Автор
          04.05.2018 08:42

          Я уже написал, почему решил использовать так, как описано, и я знаю про VPS, про цены и так далее. У нас не такой большой трафик на заблокированные ресурсы, чтобы покупать VPS\VPN ради этого. И не такой трафик, чтобы использование Tor доставляло неудобства при использовании сети. Бюджетное решение — есть бюджетное решение. Плюс, статья может быть полезна бюджетным организациям, где на RJ45 коннекторы по полгода деньги выделяют, не забывайте про них. Нам это решение подходит. А VPS\VPN — это совсем другая история


          1. awesomer
            04.05.2018 08:57

            Плюс, статья может быть полезна бюджетным организациям, где на RJ45 коннекторы по полгода деньги выделяют


            Что-то сомнительно чтобы в учреждениях, не имеющих в запасе пару десятков RJ-45, жизненно необходимыми были бы вообще хоть какие-нибудь зарубежные сайты.

            И, запросто руководству предприятия это может стоить места, если кто накапает, что у них блокировки обходятся. И за меньшее по шапке дают.


            1. nagibat0r Автор
              04.05.2018 09:01

              Вы невнимательно читали статью, видимо… И в принципе не владеете ситуацией. Речь идет об обходе блокировки неправомерно заблокированных ресурсов, попавших «под раздачу». И таких ресурсов немало, и там есть далеко не зарубежные сайты.


              1. awesomer
                04.05.2018 09:08
                -1

                И в принципе не владеете ситуацией.


                Перешли на личности? Кончились здравые аргументы?

                Я понимаю, что вы решили техническую задачу — и гордитесь этим. Это то понятно.

                Но вот обоснование… Для бюджетных учреждений? Вы серьезно?

                Какие именно жизненно важные ресурсы для бюджетной организации, которая на столько далека от современных технологий, что такой организации даже RJ-45 нужно за полгода заказывать — какие такие жизненно важные ресурсы, размещенные на заграничных хостингах, которые прям настолько нужны организации, что руководитель этого бюджетного госучреждения готов рискнуть своим местом?

                Конкретные примеры, пожалуйста.

                И, еще один вопрос, а что мешает запускать Tor локально?

                Не навлекая возможной ответственности ни на админа этой организации ни на ее руководителя?

                Речь идет об обходе блокировки неправомерно заблокированных ресурсов, попавших «под раздачу».


                Давайте не будете врать.
                Tor позволяет обходить все. И правомерные и неправомерные.

                Вы проверяете все судебные решения? Ваша прокси автоматически блокирует только неправомерные сайты?


                1. nagibat0r Автор
                  04.05.2018 09:16

                  Уважаемый, на личности никто не переходит. К чему весь трёп? Вас не устраивает решение, Вы оставили комментарий-другой, ок. С чего я должен Вам рассказывать, какие жизненно важные ресурсы нам необходимы? Что за нездоровый интерес? Нас решение устраивает целиком и полностью, и нет необходимости покупать VPS. Вы в курсе, что даже образовательные порталы попали под раздачу? А образовательные порталы используются в учебных заведениях, в которых как раз таки скудное финансирование, экономится каждая копейка.
                  Какая ответственность? Вы внимательно читали то, что я писал? Ничего противоправного в статье не описано. Tor локально? Вы серьезно? И ЗАЧЕМ?
                  Вы предложили VPS и VPN, ок, предложили так предложили, но нам это не нужно, нет надобности, понимаете? Предлагаю закончить диалог.


                  1. chromimon
                    04.05.2018 11:32

                    нет необходимости покупать VPS.


                    Тут работы админа примерно столько же, сколько стоит аренда VPS на полгода.


                    1. nagibat0r Автор
                      04.05.2018 11:52

                      Я — штатный админ. И здесь преимуществ перед VPS намного больше.


          1. navion
            04.05.2018 12:15

            бюджетным организациям, где на RJ45 коннекторы по полгода деньги выделяют

            В чём проблема заплатить 2 евро со своей карты?


            1. nagibat0r Автор
              04.05.2018 12:37
              +1

              Если у Вас есть лишние 2 евро, можете платить, никто ведь не запрещает! Я боюсь, что все те, кто пишут про VPS\VPN и прочее, немного недопонимают все прелести связки Squid и Tor. Перечитайте статью, пожалуйста.


    1. StiflerWEN
      04.05.2018 09:34
      +1

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


    1. Zolg
      04.05.2018 19:21
      +1

      В чём приемущество описанного в статье метода, я не понял
      в том, чтобы в vpn/tor маршрутизировать только «запрещенный» трафик. Используя остальной интернет напрямую.


      1. nagibat0r Автор
        05.05.2018 09:12

        Именно так. Плюс ко всему сам Squid предоставляет огромные возможности масштабирования. И тем, кому еще и нужно отслеживать посещения, «искаропки» предоставляются логи с доменными именами даже для HTTPS ресурсов, а для просмотра использовать любимый парсер логов Squid.


  1. kolu4iy
    03.05.2018 21:16
    +1

    И с репозиториями неаккуратно вышло… я бы Бастер подключал с другим приоритетом, и вместе с основным, а не вместо него. И apt указал бы ставить пакет из него.


    1. nagibat0r Автор
      04.05.2018 06:57

      Согласен. В данном случае репозиторий подключался лишь для скачивания исходников libecap, это можно сделать и без подключения репозитория, в принципе. В любом случае, спасибо за замечание


      1. AlucoST
        04.05.2018 11:53
        +1

        Поправьте, если не прав, но кажется libecap3 в stretch тот же, что и в Buster. Тем самым, эти действия в принципе лишние.


        1. nagibat0r Автор
          04.05.2018 11:55

          Вы правы! Действия над libecap лишние в принципе. Статью поправил!


  1. dragoangel
    03.05.2018 22:17

    А зачем проксировать gopher и другие морально устаревшие протоколы?


    1. sim2q
      04.05.2018 06:57

      по моему это традиция


    1. nagibat0r Автор
      04.05.2018 07:16

      Вот как раз таки gopher нам нужен) Насчет остальных я не заморачивался.


      1. Rastishka
        04.05.2018 12:45

        Надеюсь это шутка? O_o


        1. nagibat0r Автор
          04.05.2018 12:51

          Насчет gopher нет, не шутка. Не могу сказать зачем, но он используется. Да да.


  1. dartraiden
    04.05.2018 00:27
    +1

    Как мы все знаем, Tor — это не HTTP-прокси

    Мы все также знаем, что с версии 0.3.2 Tor может использоваться в роли туннелирующего HTTP-прокси (использует метод «HTTP CONNECT»). Порт для приёма соединений к прокси задаётся через настройку HTTPTunnelPort.


    1. nagibat0r Автор
      04.05.2018 07:14

      Все также знаем, что HTTPS прокси он не умеет


    1. nagibat0r Автор
      04.05.2018 07:25

      Пардон. И правда, можно выбросить Privoxy. Спасибо за замечание!


    1. nagibat0r Автор
      05.05.2018 21:35

      Найден баг, так что способ не совсем работает. Privoxy нужен


      1. dartraiden
        05.05.2018 22:24

        Там говорится про альфа-версию, в релизе не исправили?

        Здесь не вижу…


  1. Pastafarianist
    04.05.2018 01:43

    А вы видели habr.com/post/249117? Не нашёл в тексте статьи отсылок туда, но там, казалось бы, решают ту же задачу. Посмотрите также комментарии, там много интересного.

    Кстати, в вашей конфигурации работают websockets?


    1. nagibat0r Автор
      04.05.2018 07:00

      Статью видел. Но основой послужила другая, которую я указал в материале. Статья, указанная Вами, не решает мою задачу, а именно Transparent HTTPS (Peek and Splice) + Tor, и чтобы это работало как надо.


  1. alexkbs
    04.05.2018 04:17

    Чем ваш подход лучше этого и этого вариантов?


    Чем хуже сразу можно сказать: нужно патчить и собирать свои версии пакетов, а значит потом тоже нужно будет пересобирать и постоянно следить за обновлениями. Конкретно головная боль и лишняя забота. Про url_regex я даже не знаю что сказать.


    1. nagibat0r Автор
      04.05.2018 07:04

      Не лучше и не хуже.
      1) в Ваших вариантах другой подход в принципе, свои плюсы и минусы.
      2) мне нужен был именно Transparent HTTP+HTTPS прокси, по которому можно нормально и централизовано отслеживать посещения, в т.ч. HTTPS ресурсы. И данная связка это позволяет. Плюс, в моей первой статье 2015 года так и не была решена основная проблема — ip адреса в логах на порту 443 вместо доменных имен. И не работали более новые версии Squid. Лучше поздно, чем никогда) Проблему исправил патчем. Эта статья, можно сказать, дополнение к первой про peek and splice.
      3) можно ничего не патчить и не компилить, а просто взять готовые пакеты и поставить, накатить конфиг, дело 10 минут.


      1. alexkbs
        04.05.2018 07:07

        Про требование отслеживать посещения в статье ни слова, стоило бы добавить если это, вы считаете, важно. Добавлять ли обсуждение достоинств и недостатков этого подхода, а также ссылки на альтернативные варианты — на ваше усмотрение.


        1. nagibat0r Автор
          04.05.2018 07:12

          Хорошо, я исправлю материал. Спасибо


        1. nagibat0r Автор
          04.05.2018 07:18

          кстати, а что не так с url_regex?


          1. alexkbs
            04.05.2018 07:20

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


            1. nagibat0r Автор
              04.05.2018 07:35

              Ну, в принципе отличия написаны в оф.документации. Regex предоставляют наиболее широкие возможности по спискам в целом. Можно использовать dstdomain, и прикрутить туда список из РКН. Но тогда люди получат доступ к действительно по праву заблокированным ресурсам, что недопустимо.


              1. iig
                04.05.2018 14:55

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


                Либо трусы, либо крестик. Либо ресурсы заблокированы, и к ним доступа нет. Либо админ придумал и реализовал способ обхода блокировки, и предоставил этот способ в общественное пользование — тогда он нарушает, ага.


                1. nagibat0r Автор
                  04.05.2018 15:02

                  А что админ нарушил, «предоставив общественности» способ обхода неправомерных блокировок РКН?


                  1. iig
                    04.05.2018 15:33

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


                    1. nagibat0r Автор
                      04.05.2018 15:42

                      Ну, если уж на то пошло, то статьи такого рода уже есть, о чем я писал в статье. Я всего лишь сделал так, чтобы оно работало в моих условиях. Конечная цель — получить доступ к ресурсам, которые просто попали под раздачу, находясь на заблокированных подсетях, но при этом сами ресурсы заблокированными быть не должны, так как нет никаких оснований. Вайбер глючил до недавнего времени — яркий пример. Или гугл шрифты (по сей день проблема наблюдается), Ютуб (по сей день наблюдаются проблемы). Море примеров. А замглавы Минкомсвязи Алексей Волин вообще заявил: «У нас разве есть закон, запрещающий обходить блокировки? Я про такой не слышал». Максимум, что нельзя, это быть провайдером или VPN сервером публичным и предоставлять средства для обхода, но мы-то не операторы, и не предоставляем другим такой сервис, а используем в работе. А в работе необходим доступ к тем ресурсам, которые не работают по причине попыток блокировки телеграма


  1. romaf
    04.05.2018 07:05

    Скажите, нет ли у вас в планах, собрать это все в docker контейнер?


    1. nagibat0r Автор
      04.05.2018 07:05

      можно сделать, как раз думал об этом


  1. koderr
    04.05.2018 07:06

    В Privoxy есть выборочный форвардинг по хостам и маскам, можно как завернуть отдельные сайты, так и завернуть всё, кроме отдельных сайтов. Так что кроме Tor и Privoxy всё лишнее.

    Или можно выбросить Tor, купить VPS за $5, настроить ssh-туннель с локальным SOCKS5 и заворачивать туда.


    1. nagibat0r Автор
      04.05.2018 07:08

      мне не лишнее, мне нужен был Squid с прозрачным проксированием HTTP и HTTPS без подмены сертификатов. В статье не указан весь конфиг, Squid используется и для других целей, которые Privoxy сделать не позволяет. А это как дополнение, чтобы было «все в одном»


  1. Nordilion
    04.05.2018 07:08

    Н, да. Чем быть только не занимался айтишник, лишь бы только не…


    1. nagibat0r Автор
      04.05.2018 07:08

      Лишь бы только не… что?


  1. mihmig
    04.05.2018 09:56

    Какая-то странная контора: обеспечиваете доступ к заблокированным ресурсам через анонимизатор TOR, но при этом хотите видеть куда ходят пользователи…


    1. nagibat0r Автор
      04.05.2018 10:01

      Что странного? Статистика\контроль интернет-трафика есть почти везде. А разрешение доступа к заблокированным ресурсам — уже писал выше, что это и зачем. Я прекрасно вижу, какие запросы от кого и куда отправились через TOR, так как это Squid c Cache Peer. В логи все прекрасно попадает с допиской «FIrst Parent»


  1. Areso
    04.05.2018 14:01

    Меня больше практический вопрос интересует, а скорость достаточная? Tor-ом пользоваться это боль, многие сайты рвут соединение. KeepAlive до 30 секунд включительно портит нервы. Ну, а некоторые детектят выходные ноды Тора и просто шлют лесом.


    1. nagibat0r Автор
      04.05.2018 14:12

      Мы пока не натыкались на такие. Нам хватает скорости, но ничего не мешает сделать round robin на Squid и запустить несколько Tor'ов с разными конфигами. Скорость будет достаточная. И работать будет всегда. К слову, если сделать на tor obfs, это будет HA решение.


  1. dartraiden
    04.05.2018 14:31
    +1

    В конфиг Tor можно добавить
    ExcludeExitNodes {ru,ua}

    Это исключает использование выходных узлов в указанных странах (хотя, вероятность, что вам попадётся именно российский узел, мала, но она есть). Ещё придётся установить пакет tor-geoip (в Debian — tor-geoipdb).


    1. dartraiden
      04.05.2018 14:50
      +1

      Быстрый фикс, корректно так
      ExcludeExitNodes {ru}, {ua}, {by}


      1. nagibat0r Автор
        04.05.2018 14:54

        Спасибо! Ценное замечание! Добавлю в статью!


        1. rogoz
          04.05.2018 15:03

          Тогда ещё {cn} и возможно {??}


  1. Das_original
    04.05.2018 14:59

    Товарищ nagibat0r, огромное спасибо! Особенно за статью с bump`ом. Хотел было поназадавать вопросов, но мой беспонтовый статус на хабре не позволяет этого. Собственно вопрос, возможно ли при бампе https гонять содержимое через контент-фильтр по ключевым файлам? Сейчас стоит задача поднять маленький, но очень гордыйфункциональный корпоративный прокси с контент фильтром. Пробовал решения в виде dansguardian — там увы, только обычный http, есть форк e2guardian — там есть https, но умеет его только с подменой и самое худшее не умеет работать прозрачно(


    1. nagibat0r Автор
      04.05.2018 15:08

      Не за что! Но про бамп я не писал, я писал только про splice) Без MITM не получится контент фильтр сделать, увы. Если нет MITM (SSL Bump), то вся работа прозрачного прокси сводится в просмотру SNI, где только домен и ничего более.


      1. Grief
        04.05.2018 19:03

        Хочу поделиться альтернативным вариантом — sniproxy, который рулит в tor или куда-то еще, плюс dnsmasq или другой dns-сервер, который отдает для интересующих хостов айпишник машины, на который работает sniproxy. Решение гораздо более легковесное, у меня работает на роутере с openwrt, плюс не надо ничего собирать.


        1. nagibat0r Автор
          05.05.2018 08:59

          Вы опять же не улавливаете, как и многие читатели, всю суть… Что умеет SNIProxy? И что умеет связка, описанная в статье? Совершенно разные вещи. Про SNIProxy я знаю, но увы, это тоже другая история)


  1. SeriousM
    04.05.2018 15:29

    Хорошая статья, было бы здорово, чтоб все это работало еще в режиме спуфинга TRPROXY для разделения групп компов по разным провайдерам


    1. nagibat0r Автор
      04.05.2018 15:34

      Ну, если нужно два провайдера, то подойдет директива tcp_outgoing_address с server_persistent_connections, выставленной в off (если я правильно понял Вашу мысль). Возможностей здесь море. Возможно напишу о них позже, когда NDA позволит)


  1. konchok
    04.05.2018 18:58

    Какое-то некрасивое полурешение. 15 миллионов IP может ещё в сквид прописать? Куда более грамотно заворачивать все их в VPN, остальное пускать как обычно. А про URLы вообще забыть.


    1. nagibat0r Автор
      05.05.2018 09:00

      А что мешает прописать их на Squid? Почитайте оф.документацию и оф. вики, и Вы поймете, что Squid можно настроить так, что он практически не чихнет и не пыхнет даже от 15млн IP и доменов.


      1. konchok
        05.05.2018 09:10

        Даже если все их туда прописать, половина всё равно работать не будет. Интернет это как бы не только http/https. Ну и я лично уверен что с 15 млн IP в конфиге это будет работать адово медленно на железках вроди Raspberry Pi потому что сквиду придется сравнивать каждый запрос с этой базой.


        1. nagibat0r Автор
          05.05.2018 09:51

          Уважаемый, вы пробовали в конторе заворачивать все на забугорный VPS? Как Вы себе это представляете? Я уже выше писал, напишу еще раз, раз уж так нужно. VPS\VPN и прочее не предоставляют возможностей по масштабированию, абсолютно, никак и никогда. Да и не нужно эти ваши 15млн IP адресов прописывать. Тема статьи — как обойти блокировки тех ресурсов, которые оказались заблокированными случайно, но очень нужны. Если Вы лично уверены, что 15млн IP адресов для этой связки — «адово медленно», тогда я прошу Вас предоставить тесты с наблюдениями) К тому же, если уж вдруг Squid настроен не оптимальным образом и система тормозит, в конце концов можно открыть оф.вики и настроить под себя. Squid в любом случае настраивается под конкретные условия. Под конкретную сеть. Если не хватает времени оттестировать систему и настроить так, как полагается, то поставьте еще один Squid на ту же виртуалку, да настройте roung robin, проблем абсолютно никаких. А вот с использованием забугорных VPS — как раз таки вещь ОЧЕНЬ не надежная. Это все блокируется. И даже очень. В отличие от Tor. И Tor тоже позволяет масштабироваться. Сделайте несколько конфиг файлов, разные порты, да запускайте хоть 100 копий, и будет 100 туннелей, которые опять же можно прикрутить к Squid (round robin).


          1. konchok
            05.05.2018 10:14

            Контора может арендовать и выделенный сервер, суть от этого не меняется. Сквид это всего лишь http прокси, интернет http не исчерпывается.


            1. nagibat0r Автор
              05.05.2018 10:32

              Еще раз. Решение на VPS\VPN — не надежное! Не масштабируется никак! Squid+Tor масштабируются, и надежно. Основная проблема — доступ к HTTP\HTTPS ресурсам, как ни крути.


              1. konchok
                05.05.2018 10:49

                Если конкретно у вас не хватает знаний сделать надёжные VPS/VPN то это не проблема самих VPS/VPN. Сделать десять соединений в разные страны, тот же round-robin итд никакой проблемы не представляет.


                1. nagibat0r Автор
                  05.05.2018 16:07

                  И еще раз… Сколько стоит Ваше решение вопроса?) 10 VPS с VPN, Вы серьезно?)
                  VPN, VPS — еще раз, не надежное решение, в перспективе. VPN блокируется как таковой. Причем легко, в отличие от Tor с obfs. И Tor бесплатен, если интересует именно скорость, то как я уже сказал, ничего не мешает сделать несколько сервисов и настроить на них Squid. К тому же, я готов к более конструктивному обсуждению Вашего способа. Предоставьте обзор, я только рад, на такую-то тему


                  1. konchok
                    05.05.2018 16:56

                    Тут уже всё обсуждается: habr.com/post/354282


                    1. nagibat0r Автор
                      05.05.2018 18:47

                      Я видел эту статью. Это вариант. Но!
                      1) нужен сервер «где-то там». И насколько он будет доступен — тоже вопрос.
                      2) не для каждого CCNP.
                      3) как Вы сами же изъяснились, «Какое-то некрасивое полурешение»
                      4) платно. Почему кто-то должен дополнительно платить за то, чтобы работать в Интернете, если он уже итак за него платит?
                      Это малая часть недостатков. Безусловно, там есть и свои плюсы. Подход абсолютно другой. Каждый сам решает, с чем ему извращаться. Можно покупать VPS за бугром, настраивать до него туннели и т.п., с маршрутизацией копаться. Можно настроить несколько сервисов Tor, использовать и не беспокоиться о скорости и о том, что «оно отвалится» из-за каких-то там аварий\блокировок и т.д.
                      Здесь ведь еще, не забывайте, вопрос доступности для других. Вы сможете реализовать. Я смогу. Петр — сосед сисадмин не сможет, Евгений не сможет, и т.д. Поставить Squid, Tor, настроить за 10 минут базовый конфиг из статьи сможет практически любой админ, хотя бы немного знающий Linux. И решение в принципе не уступает вышеназванной статье по функционалу. Вы говорили, что «интернет не ограничивается https и https». Это верно. Но… К чему нужно получить доступ вне этих протоколов? Если заблокирован доступ к какому-то серверу по SSH, что мешает пускать SSH через тот же Squid?) Или FTP?


                      1. konchok
                        05.05.2018 18:52

                        Завтра точно также ваши публичные ноды ТОР заблокируют и будете ставить свои платные сервера «где-то там».


                        1. nagibat0r Автор
                          05.05.2018 19:05

                          Повторюсь. Obfs


                          1. konchok
                            05.05.2018 19:09

                            Вы вообще не догоняете походу. КУДА вы сделаете туннель obfs если все публичные мосты будут заблокированы? Не валяйте дурачка и идите учитесь ставить VPS, пока есть такая возможность.


                            1. nagibat0r Автор
                              05.05.2018 19:28

                              Вы, уважаемый, видимо тоже ничего не догоняете в отношении Tor! И вы своими «не валяйте дурачка» и «учитесь ставить VPS» переходите уже планку приличия. Я Вам не буду кидать сервисы типа «давай я поищу в гугле вместо тебя», думаю Вы сами откроете оф.документацию Тор и поймете, что нет никаких публичных мостов. С 2012 года их не существует. И список взять неоткуда


                            1. nagibat0r Автор
                              05.05.2018 19:31

                              Перекрыть Tor можно только полным отключением от глобальной сети, имейте это в виду, прежде чем делать такие заявления


        1. nagibat0r Автор
          05.05.2018 10:09

          К тому же, «сквиду придется сравнивать каждый запрос с этой базой» наводит на мысль, что Вам желательно почитать вики на оф.сайте) Почитайте, Вам станет все намного понятнее и прозрачнее в отношении Squid.


          1. konchok
            05.05.2018 10:20

            Ок, замените «каждый запрос» на «каждый новый запрос». Я со сквидом работаю с версий 1.х, так что документацию читал, не переживайте )


            1. nagibat0r Автор
              05.05.2018 10:32

              Хорошо. Но суть Вы так и не уловили. Жаль. Очень жаль.


  1. erondondon
    04.05.2018 19:10

    Нет ничего лучше, подорванных пердаков дуроботов.


  1. Zolg
    04.05.2018 19:28

    На самом деле squid не особенно и нужен для данного сценария. Детектировать обращение к запрещенному ресурсу можно во время name resolving'а и запихивать IP в rdr правила iptables.
    Отлично работает даже на low-end домашних роутерах за несколько тысяч рублей.

    Здесь подробно описал habr.com/post/270657


    1. nagibat0r Автор
      05.05.2018 09:05

      Хорошо. Но масштабируемости в принципе нет. Squid + Tor позволяет масштабировать систему насколько угодно. Ваш способ годится разве что для дома, как действительно простое и легкое решение. Со своими минусами и плюсами.


      1. konchok
        05.05.2018 10:30
        -1

        Тор это от слова тормозить. Подойдёт разве что для каких-то отдельных сервисов где не нужна интерактивность.


        1. nagibat0r Автор
          05.05.2018 10:33

          Увы, но Вы плохо представляете возможности Tor, Squid.


          1. konchok
            05.05.2018 10:50
            -1

            Да куда уж мне )


        1. Zolg
          05.05.2018 11:24

          никто не заставляет использовать именно тор: есть возможность/желание — поднимайте впн и маршрутизируйте блокированный трафик в него


          1. nagibat0r Автор
            05.05.2018 16:08

            выше уже сказал о недостатках VPN… И те недостатки, которые перечислили выше насчет Tor, легко решаются, если вдруг не хватает скорости.


  1. Temtaime
    04.05.2018 22:32

    У меня при подключении к прокси хром ругается ERR_PROXY_CERTIFICATE_INVALID.
    При создании сертификата CN указывал. ЧЯДНТ?


    1. nagibat0r Автор
      05.05.2018 09:07

      Телепаты в отпуске) Что Вы делали? Как Вы делали? Конфиг?


      1. Temtaime
        05.05.2018 11:55

        Спасибо за ответ.
        Конфиг pastebin.com/4zrVrw7r — просто прокси без тора и фильтрации для начала. Хром негодует.
        В чём может быть проблема? Сертификат создавал командой из статьи.


        1. nagibat0r Автор
          05.05.2018 16:11

          У Вас в конфиге в принципе неверное использование. Вы пытаетесь использовать авторизацию и прозрачность. Читайте вики по Squid.
          Прозрачность — это прозрачность, никакой авторизации и настроек на стороне клиента. Только заворачивайте файрволом порты на Squid и все. И Squid должен быть шлюзом по-умолчанию для клиентов.


  1. NeLexa
    05.05.2018 07:05

    Давно уже сделал соединение, через tor для указанных доменов, через расширение FoxyProxy для Firefox. Достаточно добавить соединение к 127.0.0.1 и тор порту (9050) и оно было активно для белого списка сайтов. В списке сайтов уже добавлять по regexp или wildcard шаблону.


    1. nagibat0r Автор
      05.05.2018 19:53

      Как решение «для себя одного» вполне. Кстати, плагин давно знаю, раньше часто спасал


    1. darkdaskin
      05.05.2018 21:48

      У себя заменил FoxyProxy на SmartProxy. У него есть удобная фишка — полуавтоматическое создание правил для недоступных хостов. Полезно для сайтов, которые используют заблокированные внешние ресурсы, не нужно искать, что именно отвалилось. И в целом интерфейс поудобнее.