Прозрачное кэширование в nginx для всех и каждого

Why does it go so slowly through Squid?

The work-around used by many cache maintainers has been to set the above config and force Squid to fetch the whole object when a range request goes through.

Compounding the problem and ironically causing some slowdowns is the fact that some of the Microsoft servers may be telling your Squid not to store the archive file. This means that Squid will pull the entire archive every time it needs any small piece.

You will need to test your squid config with smaller values for the range_offset_limit bypass and see which provides the best results for you.

Another symptoms which occasionally appear when attempting to force caching of windows updates is service packs.

If the quick_abort_min, quick_abort_max, quick_abort_pct settings are set to abort a download incomplete and a client closes with almost but not quite enough of the service pack downloaded. That clients following requests will often timeout waiting for Squid to re-download the whole object from the start. Which naturally causes the problem to repeat on following restart attempts.

Использование СКВИДов

Исключительно высокая энергетическая чувствительность (порядка долей постоянной Планка), которой обладают СКВИДы при измерениях магнитных полей, открыла новые возможности в экспериментах фундаментальной физики. Одна из таких задач — оценка возможной величины электрического дипольного момента (ЭДМ) электрона. Общеизвестно, что электроны обладают электрическим зарядом и спином. Эффекты, связанные с нарушением СР- и Т-инвариантности, не запрещают электрону иметь распределение электрического заряда, не совпадающее с распределением его массы, то есть электрический дипольный момент. Различные модели предсказывают существование у электрона ЭДМ на уровне от 10−20 см на заряд электрона до 10−28 см на заряд электрона, а возможно, и ещё меньше. Соответствующие опыты со СКВИДом показали, что ЭДМ у электронов меньше, по крайней мере, 10−22 см на заряд электрона. Этот результат вошел в справочники по свойствам элементарных частиц и к настоящему времени вызвал целую серию подобных измерений.

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

Сканирующий СКВИД-микроскоп

В отличие от традиционных магнитометров, в которых СКВИДы используются как пассивные датчики низкочастотного или постоянного магнитного поля, в новом микроскопе используется переменный ток микроволновой частоты, циркулирующий по кольцу СКВИДа, когда на его джозефсоновских переходах возникает постоянное напряжение (нестационарный эффект Джозефсона). Основной принцип действия в том, что микроволновой ток течет в кольце СКВИДа легче, когда рядом с ним находится проводящий образец.

3: Настройка Apache

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

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

Если сервер Apache поддерживает трафик HTTP и HTTPS, параметры обратного прокси-сервера нужно поместить в оба виртуальных хоста.

• Настройка виртуальных хостов Apache в Ubuntu 16.04
• Создание SSL-сертификата на Apache в Ubuntu 16.04

Откройте файл виртуального хоста Apache по умолчанию:

Найдите блок <VirtualHost *:80>.

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

Обратный прокси-сервер для одного сервера бэкэнда

Замените все параметры блока VirtualHost следующими настройками:

Примечание: Если вы создали серверы бэкэнда согласно разделу 2, используйте 127.0.0.1:8080. Если вы работаете с собственным сервером, укажите его адрес.

В файле используются такие директивы:

• ProxyPreserveHost: передаёт исходный заголовок Host серверу бэкэнда (так он узнает адрес, используемый для доступа к приложению).
• ProxyPass: основная директива настройки проксирования. В данном случае всё, что идет после / (корневого URL), будет передаваться на указанный адрес сервера бэкэнда. К примеру, если веб-сервер Apache получает запрос к /example, он подключится к http://your_backend_server/example и вернёт клиенту ответ.
• ProxyPassReverse: эта директива должна иметь такие же настройки, что и ProxyPass. Она изменяет заголовки ответов сервера бэкэнда. Таким образом, если внутренний сервер возвращает заголовок редиректа, браузер клиента будет перенаправлен на адрес прокси-сервера, а адрес сервера, бэкэнда будет заблокирован.

Перезапустите Apache.

Если вы откроете ссылку http://your_server_ip, вместо стандартной приветственной страницы веб-сервера вы увидите ответ сервера бэкэнда:

Обратный прокси-сервер и балансировка нагрузки

Если у вас есть массив серверов бэкэнда, вы можете распределить трафик между ними с помощью обратного прокси-сервера Apache и модуля mod_proxy.

Замените содержимое блока VirtualHost следующими параметрами:

В данном случае нужно добавить блок Proxy, чтобы указать массив серверов. Блок называется balancer://mycluster (имя можно изменить) и содержит одну или несколько директив BalancerMember, с помощью которой указываются адреса серверов бэкэнда. Директивы ProxyPass и ProxyPassReverse используют пул балансировки нагрузки mycluster.

Если вы создали серверы бэкэнда согласно разделу 2, укажите в директиве BalancerMember адреса 127.0.0.1:8080 и 127.0.0.1:8081. Если вы используете собственные серверы, укажите их адреса.

Чтобы обновить настройки, перезапустите Apache.

Если вы откроете в браузере ссылку:

вместо стандартной приветственной страницы веб-сервера вы увидите ответ сервера бэкэнда:

Обновите страницу, и на экране появится ответ второго сервера:

Если это так, обратный прокси-сервер работает правильно.

Ограничения пользователей

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

Ограничения по времени

Ограничить пользователей по времени можно следующим образом:

Где день: M — Понедельник, T — Вторник, W — Среда, H — Четверг, F — Пятница, A — Суббота, S — Воскресенье.

При этом чч:мм должно быть меньше чем ЧЧ:ММ, то есть можно указать с 00:00-23:59, но нельзя указать 20:00-09:00.

Давайте запретим всё тому же Васе иметь доступ в сеть Интернет с 10 до 15 часов каждый день:

Если хочется разрешить Васе пользоваться программой Mirc с 13 до 14 часов, то пишем:

А что делать, если необходимо запретить или разрешить в определенные дни недели? Squid также позволяет это сделать, к примеру с 13 до 14 в понедельник и в воскресенье:

Как видите, ничего сложного в этом нет.

Установка и базовая настройка

Устанавливаем прокси-сервер следующей командой:

apt-get install squid

Открываем на редактирование конфигурационный файл:

vi /etc/squid/squid.conf

Если сеть клиентских компьютеров отличается от стандартной (192.168.0.0/16, 172.16.0.0/12, 10.0.0.0/8), необходимо ее добавить в acl, например:

#  TAG: acl
…
acl localnet src 217.66.157.0/24

или через файл:

#  TAG: acl
…
acl localnet src «/etc/squid/acl_localnet»

* кавычки обязательны
** после необходимо создать файл /etc/squid/acl_localnet и с каждой строчки перечислить разрешенные IP-адреса.

С точки зрения безопасности, лучше закомментировать все подсети, которые не используются в нашей локальной сети, например:

#  TAG: acl
…
#acl localnet src 0.0.0.1-0.255.255.255
#acl localnet src 10.0.0.0/8
#acl localnet src 100.64.0.0/10
#acl localnet src 169.254.0.0/16
#acl localnet src 172.16.0.0/12
acl localnet src 192.168.0.0/16
#acl localnet src fc00::/7
#acl localnet src fe80::/10

* в данном примере мы оставили только подсеть 192.168.0.0/16.

Разрешаем доступ для локальных сетей, которые заданы опцией acl localnet:

#  TAG: http_access
…
http_access allow localnet

* данную опцию нужно либо раскомментировать, либо вставить выше опции http_access deny all.

Настраиваем директорию для кэша:

#  TAG: cache_dir
…
cache_dir ufs /var/spool/squid 4096 32 256

* где ufs — файловая система (ufs для SQUID является самой подходящей); /var/spool/squid — директория хранения кэша; 4096 — объем пространства в мегабайтах, которое будет выделено под кэш; 32 — количество каталогов первого уровня, которое будет создано для размещение кэша; 256 — количество каталогов второго уровня, которое будет создано для размещение кэша.

Останавливаем squid:

systemctl stop squid

Создаем структуру папок под кэш следующей командой:

squid -z

Запускаем squid и разрешаем его автозапуск:

systemctl enable squid —now

Squid and http-gw from the TIS toolkit.

Several people on both the fwtk-users and the squid-users mailing asked about using Squid in combination with http-gw from the TIS toolkit. The most elegant way in my opinion is to run an internal Squid caching proxyserver which handles client requests and let this server forward it’s requests to the http-gw running on the firewall. Cache hits won’t need to be handled by the firewall.

In this example Squid runs on the same server as the http-gw, Squid uses 8000 and http-gw uses 8080 (web). The local domain is home.nl.

Firewall configuration

Either run http-gw as a daemon from the /etc/rc.d/rc.local (Linux Slackware):

exec /usr/local/fwtk/http-gw -daemon 8080

or run it from inetd like this:

web stream      tcp      nowait.100  root /usr/local/fwtk/http-gw http-gw

I increased the watermark to 100 because a lot of people run into problems with the default value.

Make sure you have at least the following line in /usr/local/etc/netperm-table

http-gw: hosts 127.0.0.1

You could add the IP-address of your own workstation to this rule and make sure the http-gw by itself works, like:

http-gw:                hosts 127.0.0.1 10.0.0.1

Squid configuration

The following settings are important:

http_port       8000
icp_port        0
cache_peer      localhost.home.nl parent 8080 0 default
acl HOME        dstdomain .home.nl
alwayws_direct  allow HOME
never_direct    allow all

This tells Squid to use the parent for all domains other than home.nl. Below, access.log entries show what happens if you do a reload on the Squid-homepage:

872739961.631 1566 10.0.0.21 ERR_CLIENT_ABORT/304 83 GET http://www.squid-cache.org/ - DEFAULT_PARENT/localhost.home.nl -
872739962.976 1266 10.0.0.21 TCP_CLIENT_REFRESH/304 88 GET http://www.nlanr.net/Images/cache_now.gif - DEFAULT_PARENT/localhost.home.nl -
872739963.007 1299 10.0.0.21 ERR_CLIENT_ABORT/304 83 GET http://www.squid-cache.org/Icons/squidnow.gif - DEFAULT_PARENT/localhost.home.nl -
872739963.061 1354 10.0.0.21 TCP_CLIENT_REFRESH/304 83 GET http://www.squid-cache.org/Icons/Squidlogo2.gif - DEFAULT_PARENT/localhost.home.nl

http-gw entries in syslog:

Aug 28 02:46:00 memo http-gw: permit host=localhost/127.0.0.1 use of gateway (V2.0beta)
Aug 28 02:46:00 memo http-gw: log host=localhost/127.0.0.1 protocol=HTTP cmd=dir dest=www.squid-cache.org path=/
Aug 28 02:46:01 memo http-gw: exit host=localhost/127.0.0.1 cmds=1 in=0 out=0 user=unauth duration=1
Aug 28 02:46:01 memo http-gw: permit host=localhost/127.0.0.1 use of gateway (V2.0beta)
Aug 28 02:46:01 memo http-gw: log host=localhost/127.0.0.1 protocol=HTTP cmd=get dest=www.squid-cache.org path=/Icons/Squidlogo2.gif
Aug 28 02:46:01 memo http-gw: permit host=localhost/127.0.0.1 use of gateway (V2.0beta)
Aug 28 02:46:01 memo http-gw: log host=localhost/127.0.0.1 protocol=HTTP cmd=get dest=www.squid-cache.org path=/Icons/squidnow.gif
Aug 28 02:46:01 memo http-gw: permit host=localhost/127.0.0.1 use of gateway (V2.0beta)
Aug 28 02:46:01 memo http-gw: log host=localhost/127.0.0.1 protocol=HTTP cmd=get dest=www.nlanr.net path=/Images/cache_now.gif
Aug 28 02:46:02 memo http-gw: exit host=localhost/127.0.0.1 cmds=1 in=0 out=0 user=unauth duration=1
Aug 28 02:46:03 memo http-gw: exit host=localhost/127.0.0.1 cmds=1 in=0 out=0 user=unauth duration=2
Aug 28 02:46:04 memo http-gw: exit host=localhost/127.0.0.1 cmds=1 in=0 out=0 user=unauth duration=3

To summarize:

Advantages:

• http-gw allows you to selectively block ActiveX and Java, and it’s primary design goal is security.
• The firewall doesn’t need to run large applications like Squid.
• The internal Squid-server still gives you the benefit of caching.

Disadvantages:

• The internal Squid proxyserver can’t (and shouldn’t) work with other parent or neighbor caches.
• Initial requests are slower because these go through http-gw, http-gw also does reverse lookups. Run a nameserver on the firewall or use an internal nameserver.

(contributed by Rodney van den Oever)

Can I set up ACL’s based on MAC address rather than IP?

Yes, for some operating systes. The ACL type is named arp after the ARP protocol used in IPv4 to fetch the EUI-48 / MAC address. This ACL is supported on Linux, Solaris, and probably BSD variants.

MAC address is only available for clients that are on the same subnet. If the client is on a different subnet, then Squid can not find out its MAC address as the MAC is replaced by the router MAC when a packet is router.

For Squid-3.1 and older to use ARP (MAC) access controls, you first need to compile in the optional code.

Do this with the —enable-arp-acl configure option:

% ./configure --enable-arp-acl ...
% make clean
% make

If src/acl.c doesn’t compile, then ARP ACLs are probably not supported on your system.

For Squid-3.2 and newer the EUI support is enabled by default whenever it can be used.

Add some arp ACL lines to your squid.conf:

acl M1 arp 01:02:03:04:05:06
acl M2 arp 11:12:13:14:15:16
http_access allow M1
http_access allow M2
http_access deny all

Run squid -k parse to confirm that the ARP / EUI supprot is available and the ACLs are going to work.

Запуск Squid

Включаем Squid в rc.conf:
Вручную редактором:
Или командой:
Запускаем Squid:
Если при старте получаем предупреждение: «WARNING: Could not determine this machines public hostname. Please configure one or set ‘visible_hostname’». Задаем имя сервера параметром «visible_hostname» в конфиге.
Проверяем, запущен ли демон:
Проверяем, слушается ли порт:
Проверяем системный лог на наличие сообщений от Squid:
Проверяем cache.log:
В случае успешного старта вывод будет примерно следующим:

Остается еще одна маленькая вещь, мимо которой мы не можем пройти безнаказанно. И эта вещь — реклама. Не знаю, как вас, но меня достали эти разражающе мигающие и переливающиеся баннеры. И если порнуху можно запретить простым прописыванием сайтов в deny-листы, то с баннерами такая ситуация не проходит. То есть проходит, но страницы при этом портятся до безобразия. Но народ умный, он придумал такую вещь, как редиректор. Суть проста — каждый URL, который передается squid’у, первоначально передается редиректору. И тот либо возвращает прежний URL в случае, если все в порядке, либо возвращает тот, который по его мнению, более правильный. А кто мешает нам перехватывать обращения к баннерам и счетчикам и вместо них подсовывать свою картинку? Никто!. В итоге страницы не портятся безобразными значками о невозможности выкачать картинку, а заполняются прозрачными окошками.

Common Mistakes

And/Or logic

Interpretation of ACL-driven directives is based, in part, on the following rules:

• All elements of an acl entry are OR’ed together.

• All elements of an access entry are AND’ed together (e.g. http_access and icp_access)

For example, the following access control configuration will never work:

acl ME src 10.0.0.1
acl YOU src 10.0.0.2
http_access allow ME YOU

In order for the request to be allowed, it must match the «ME» acl AND the «YOU» acl. This is impossible because any IP address could only match one or the other. This should instead be rewritten as:

acl ME src 10.0.0.1
acl YOU src 10.0.0.2
http_access allow ME
http_access allow YOU

Or, alternatively, this would also work:

acl US src 10.0.0.1 10.0.0.2
http_access allow US

allow/deny mixups

I have read through my squid.conf numerous times, spoken to my neighbors, read the FAQ and Squid Docs and cannot for the life of me work out why the following will not work.

I can successfully access cachemgr.cgi from our web server machine here, but I would like to use MRTG to monitor various aspects of our proxy. When I try to use squidclient or GET cache_object from the machine the proxy is running on, I always get access denied.

acl manager proto cache_object
acl localhost src 127.0.0.1
acl server    src 1.2.3.4
acl ourhosts  src 1.2.0.0/24
http_access deny manager !localhost !server
http_access allow ourhosts
http_access deny all

The intent here is to allow cache manager requests from the localhost and server addresses, and deny all others. This policy has been expressed here:

http_access deny manager !localhost !server

The problem here is that for allowable requests, this access rule is not matched. For example,

• if the source IP address is localhost, then «!localhost» is false and the access rule is not matched, so Squid continues checking the other rules.

• if the source IP address is server, then «!server is false and the access rule is not matched, so Squid continues checking the other rules.

Cache manager requests from the server address work because server is a subset of ourhosts and the second access rule will match and allow the request.

Also note that this means any cache manager request from ourhosts would be allowed.

To implement the desired policy correctly, the access rules should be rewritten as

http_access allow manager localhost
http_access allow manager server
http_access deny manager
http_access allow ourhosts
http_access deny all

If you’re using miss_access, then don’t forget to also add a miss_access rule for the cache manager:

miss_access allow manager

You may be concerned that the having five access rules instead of three may have an impact on the cache performance. In our experience this is not the case. Squid is able to handle a moderate amount of access control checking without degrading overall performance. You may like to verify that for yourself, however.

Differences between »src» and »srcdomain» ACL types

For the srcdomain ACL type, Squid does a reverse lookup of the client’s IP address and checks the result with the domains given on the acl line. With the src ACL type, Squid converts hostnames to IP addresses at startup and then only compares the client’s IP address. The src ACL is preferred over srcdomain because it does not require address-to-name lookups for each request.