Прозрачный прокси сервер squid3 squidguard iptables sarg

Оставьте комментарий 6,950

  • Tutorial

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

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

Зачем это?

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


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

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

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

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


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

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


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

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


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

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

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

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

  1. Debian Stretch (9) x86 (в х64 не пробовал)
  2. Сорцы Squid 3.5.23 из репозитория
  3. Свеженькие сорцы Squid с оф.сайта
  4. OpenSSL
  5. Libecap3
  6. Privoxy
  7. Прямые руки и много кофе с печеньками
Собирать Squid ручками или ставить готовые пакеты (ссылки ниже), решать вам. Если вы думаете, что я впендюрил в них блекджек и ш… вирусы, то компильте сами. Также компилировать нужно, если у вас дистрибутив другой (если Убунта, то поставите). Собирать мы будем версию Squid 3.5.23, которая на момент написания статьи валяется в репозитории Stretch , повысив ее до свежих исходников 3.5.27 с оф.сайта. В отличие от моей первой статьи про HTTPS+Squid, собирать будем без Libressl.

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

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

ВАЖНО!

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

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

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

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

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

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

Совет

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

Acl localnet src 192.168.0.0/24 # Ваша локалка acl SSL_ports port 443 acl Safe_ports port 80 # http acl Safe_ports port 21 # ftp acl Safe_ports port 443 # https acl Safe_ports port 70 # gopher acl Safe_ports port 210 # wais acl Safe_ports port 1025-65535 # unregistered ports acl Safe_ports port 280 # http-mgmt acl Safe_ports port 488 # gss-http acl Safe_ports port 591 # filemaker acl Safe_ports port 777 # multiling http acl CONNECT method CONNECT acl SSL method CONNECT #Укажем DNS для Squid. Крайне рекомендую использовать одинаковые DNS тут и у клиентов dns_nameservers 77.88.8.8 # Список доменов, которые нужно пустить через Tor acl rkn url_regex "/etc/squid/tor_url" http_access deny !Safe_ports http_access deny CONNECT !SSL_ports http_access allow localhost manager http_access deny manager http_access allow localnet http_access allow localhost http_access deny all icp_access deny all htcp_access deny all #прозрачный порт указывается опцией intercept http_port 192.168.0.1:3128 intercept options=NO_SSLv3:NO_SSLv2 #также нужно указать непрозрачный порт, ибо если захотите вручную указать адрес #прокси в браузере, указав прозрачный порт, вы получите ошибку доступа, поэтому нужно #указывать непрозрачный порт в браузере, если конечно такое желание будет, к тому же в логах #сыпятся ошибки о том, что непрохрачный порт не указан=) http_port 192.168.0.1:3130 options=NO_SSLv3:NO_SSLv2 #и наконец, указываем HTTPS порт с нужными опциями https_port 192.168.0.1:3129 intercept ssl-bump options=ALL:NO_SSLv3:NO_SSLv2 connection-auth=off cert=/etc/squid/squidCA.pem sslproxy_cert_error allow all sslproxy_flags DONT_VERIFY_PEER #укажем правило со списком блокируемых ресурсов (в файле домены вида.domain.com) acl blocked ssl::server_name "/etc/squid/blocked_https.txt" acl step1 at_step SslBump1 ssl_bump peek step1 #терминируем соединение, если клиент заходит на запрещенный ресурс ssl_bump terminate blocked ssl_bump splice all # Никогда не пускать напрямую домены, указанные в списке РКН never_direct allow rkn # Указываем прокси, куда отправлять домены из списка, в нашем случае - Privoxy cache_peer 127.0.0.1 parent 8118 0 no-query no-digest default cache_peer_access 127.0.0.1 allow rkn cache_peer_access 127.0.0.1 deny all sslcrtd_program /usr/lib/squid/ssl_crtd -s /var/lib/ssl_db -M 4MB coredump_dir /var/spool/squid refresh_pattern ^ftp: 1440 20% 10080 refresh_pattern ^gopher: 1440 0% 1440 refresh_pattern -i (/cgi-bin/|\?) 0 0% 0 refresh_pattern . 0 20% 4320 logfile_rotate 4 pid_filename /var/run/squid.pid
Список url_regex имеет примерно такой вид (список дан для примера!):

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

Прозрачный прокси - схема связи, при которой трафик, или его часть, перенаправляется на прокси-сервер неявно (средствами маршрутизатора). При этом клиент может использовать все преимущества прокси-сервера без дополнительных настроек браузера (или другого приложения для работы с интернетом). Пример: route -p add 10.32.5.5 mask 255.255.255.255 10.32.1.14

Классификация прокси-серверов для целей анонимизации представлена в статье Веб-прокси .

Технические подробности

Клиентский компьютер имеет настройку (конкретной программы или операционной системы), в соответствии с которой все сетевые соединения по некоторому протоколу совершаются не на IP-адрес сервера (ресурса), выделяемый из DNS-имени ресурса, или напрямую заданный, а на IP-адрес (и другой порт) прокси-сервера.

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

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

Таким образом прокси-сервер является полнофункциональным сервером и клиентом для каждого поддерживаемого протокола и имеет полный контроль над всеми деталями реализации этого протокола, имеет возможность применения заданных администратором политик доступа на каждом этапе работы протокола.

Прокси-серверы являются самым популярным способом выхода в Интернет из локальных сетей предприятий и организаций. Этому способствуют следующие обстоятельства:

  • Основной используемый в интернете протокол - HTTP , в стандарте которого описана поддержка работы через прокси;
  • Поддержка прокси большинством браузеров и операционных систем;
  • Контроль доступа и учёт трафика по пользователям;
  • Фильтрация трафика (интеграция прокси с антивирусами);
  • Прокси-сервер - может работать с минимальными правами на любой ОС с поддержкой сети (стека TCP/IP);
  • Многие приложения, использующие собственные специализированные протоколы, могут использовать HTTP как альтернативный транспорт или SOCKS -прокси как универсальный прокси, подходящий для практически любого протокола;
  • Отсутствие доступа в Интернет по другим (нестандартным) протоколам может повысить безопасность в корпоративной сети.

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

Наиболее распространённые прокси-серверы

  • 3proxy (BSD, многоплатформенный)
  • CoolProxy (проприетарный , Windows)
  • Eserv (shareware, Windows)
  • HandyCache (shareware, Windows) бесплатен для домашнего использования
  • Kerio Control (проприетарный, Windows, Linux)
  • Microsoft Forefront Threat Management Gateway , ранее Microsoft ISA Server (proprietary, Windows)
  • Blue Coat Proxy SG (аппаратный/виртуальный appliance)
  • nginx (веб-сервер, имеющий режим работы в качестве reverse proxy и часто для этого использующийся)
  • Squid (GPL, многоплатформенный)
  • Traffic Inspector (проприетарный, Windows)
  • UserGate (проприетарный, Windows)
  • Интернет Контроль Сервер (shareware, FreeBSD)
  • Tor (BSD, многоплатформенный)
  • Ideco ICS (проприетарный, Linux)
  • WinGate (проприетарный, Windows)
  • (с авторизацией)
  • Apache (веб-сервер, имеющий дополнительные модули для реализации прямого и реверсного прокси)

Проксификаторы

Проксификатор - это программа, перенаправляющая другие программы через прокси-серверы. Проксификаторы часто применяются для интернет-клиентов, которые не поддерживают прокси-серверы.

  • Сравнение проксификаторов (англ.)
  • Proxy software and scripts в каталоге ссылок

Понадобилось мне недавно поставить прозрачный прокси-сервер в одной конторе. Выход в интернет там организован через роутер ASUS WL-550g, на котором стояла альтернативная прошивка.

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

Вобщем для выполнения этой задачи я установил Debian на отдельный ПК, затем поставил туда проси Squid, Apache и Lightsquid для просмотра статистики. После этого встал вопрос каким образом завернуть весь трафик 80-го TCP порта на комп прокси-сервера.

Самое просто что пришло в голову это прописать на шлюзе что-то типа:
iptables -t nat -A PREROUTING -s localnetwork -p tcp -dport 80 -j DNAT -to-destination proxy-server-ip:port
Заработало… Весь трафик реально стал заворачиваться на прокси-сервер, вот только в отображаемой Лайтсквиде статистике получился небольшой казус. Все запросы в интернет отправленные с компьтеров сети в статистике стали отображаться как запросы, отправленные непосредственно с локального IP-адреса маршрутизатора. Почему так произошло, ведь DNAT меняет в IP-пакете только адрес назначения? Все очень просто. Общее правило, по которому вся сеть выходила в интернет никуда не делось, а там у нас было прописано примерно вот что:
iptables -t nat -A POSTROUTING -s localnetwork -j MASQUERADE
На деле получалось так, что в цепочке PREROUTING у нас менялся адрес назначения, а затем, в цепочке POSTROUTING еще и адрес отправителя.
Делаем правильно!
Порывшись в интернете я набрел на доку, в которой написано как наиболее правильно делать перенаправление на прозрачный прокси.
Итак, сначала пишется правило, которое пропускат без изменений весь трафик идущий от прокси-сервера в интернет:
iptables -t mangle -A PREROUTING -j ACCEPT -p tcp -dport 80 -s proxy-server-ip
Трафик идущий в интернет от других компьютеров локальной сети мы маркируем:
iptables -t mangle -A PREROUTING -j MARK -set-mark 3 -p tcp -dport 80
Затем мы создаем правило маршрутизации - весь промаркированный трафик засовываем в новую таблицу 2:
ip rule add fwmark 3 table 2
После этого прописсываем маршрут дл таблицы 2:
ip route add default via proxy-server-ip dev router-lan-interface table 2
После этих шагов весь трафик будет заворачиваться на проски-сервер на момент принятия решения о маршрутизации, т.е. не доходя до цепочки POSTROUTING.
Но тут есть один маленький ньюанс, весь трафик с компьютеров локальной сети будет приходить на прокси-сервер на 80й порт, поэтому Squid нужно настраивать на 80-м порту либо делать REDIRECT с 80-го на какой-нибудь 3128. Правило на прокси-сервере будет выглядить примерно таким образом:
iptables -A PREROUTING -t nat -i eth0 -p tcp -dport 80 -j REDIRECT -to-port 3128
Так как 80й порт на прокси-сервере у нас будет в любом случае занят не зависимо от того повесим мы на него Squid или будем делать редирект, не забудте Apache привязать к другому порту, т.к. по умолчанию он тоже висит на TCP 80.

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

Что такое прозрачный прокси-сервер?

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

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

Как добиться работы прозрачного проксирования?

Для нормальной работы прозрачного проксирования, следует правильно настроить маршрутизатор. Как известно, большая часть современных компьютерных сетей использует маршрутизатор для соединения локальной сети и сети интернет. Суть настройки маршрутизатора в этом случае заключается в перенаправлении всего трафика, следующего на 80 порт, на squid прозрачный прокси сервер. Существуют случаи, особенно это касается небольших сетей, когда запустить прокси сервер можно даже на маршрутизаторе, что весьма удобно.

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

Для чего нужен прозрачный прокси-сервер?

Как уже говорилось выше, прозрачный прокси-сервер обладает своими преимуществами, которые и делают его столь часто используемым. Главное преимущество такого вида проксирования заключается в том, что клиент, который будет использовать прозрачный прокси сервер не должен ничего настраивать, что очень удобно и комфортно для самого клиента. Всё что необходимо сделать это правильно организовать перенаправление трафика на маршрутизаторе, что должен сделать админ сети, после чего все участники этой сети смогут пользоваться всеми преимуществами, которыми обладает прокси-сервер. Что же касается преимуществ прокси-серверов и их возможностей, то можно выделить следующие из них:

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

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

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

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

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



© Copyright 2024, https://qzoreteam.ru