Это окончательный вариант использования прокси . Обычный прокси, а не обратный прокси (он же балансировщик нагрузки).
Самым известным, бесплатным и открытым исходным кодом является squid . К счастью, это одна из немногих хороших программ с открытым исходным кодом, которую можно легко установить apt-get install squid3
с помощью одного файла и настроить с помощью одного файла /etc/squid3/squid.conf
.
Мы рассмотрим лучшие практики и уроки, о которых известно.
Слегка изменен официальный файл конфигурации (удалены 5000 бесполезных закомментированных строк).
# WELCOME TO SQUID 3.4.8
# ----------------------------
#
# This is the documentation for the Squid configuration file.
# This documentation can also be found online at:
# http://www.squid-cache.org/Doc/config/
#
# You may wish to look at the Squid home page and wiki for the
# FAQ and other documentation:
# http://www.squid-cache.org/
# http://wiki.squid-cache.org/SquidFaq
# http://wiki.squid-cache.org/ConfigExamples
#
###########################################################
# ACL
###########################################################
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 1025-65535 # unregistered ports
acl CONNECT method CONNECT
#####################################################
# Recommended minimum Access Permission configuration
#####################################################
# Deny requests to certain unsafe ports
http_access deny !Safe_ports
# Deny CONNECT to other than secure SSL ports
http_access deny CONNECT !SSL_ports
# Only allow cachemgr access from localhost
http_access allow localhost manager
http_access deny manager
#####################################################
# ACL
#####################################################
# access is limited to our subnets
acl mycompany_net src 10.0.0.0/8
# access is limited to whitelisted domains
# ".example.com" includes all subdomains of example.com
acl repo_domain dstdomain .keyserver.ubuntu.com
acl repo_domain dstdomain .debian.org
acl repo_domain dstdomain .python.org
# clients come from a known subnet AND go to a known domain
http_access allow repo_domain mycompany_net
# And finally deny all other access to this proxy
http_access deny all
#####################################################
# Other
#####################################################
# default proxy port is 3128
http_port 0.0.0.0:3128
# don't forward internal private IP addresses
forwarded_for off
# disable ALL caching
# bandwidth is cheap. debugging cache related bugs is expensive.
cache deny all
# logs
# Note: not sure if squid configures logrotate or not
access_log daemon:/var/log/squid3/access.log squid
access_log syslog:squid.INFO squid
# leave coredumps in the first cache dir
coredump_dir /var/spool/squid3
# force immediaty expiry of items in the cache.
# caching is disabled. This setting is set as an additional precaution.
refresh_pattern . 0 0% 0
Конфигурация клиента - переменные среды
Настройте эти две переменные среды во всех системах.
http_proxy=squid.internal.mycompany.com:3128
https_proxy=squid.internal.mycompany.com:3128
Большинство клиентских библиотек http (libcurl, httpclient, ...) самоконфигурируются с использованием переменных среды. Большинство приложений используют одну из распространенных библиотек и, таким образом, поддерживают прокси из коробки (без необходимости, чтобы разработчик знал, что они делают).
Обратите внимание, что синтаксис строгий:
- Имя переменной
http_proxy
ДОЛЖНО быть строчным в большинстве Linux.
- Значение переменной НЕ ДОЛЖНО начинаться с
http(s)://
(протокол проксирования НЕ является http (s)).
Конфигурация клиента - Специально
Некоторые приложения игнорируют переменные среды и / или запускаются как сервисы до того, как переменные могут быть установлены (например, debian apt
).
Эти приложения потребуют специальной настройки (например /etc/apt.conf
).
HTTPS Proxying - Подключение
Прокси HTTPS полностью поддерживается дизайном. Он использует специальный метод «CONNECT», который устанавливает своего рода туннель между браузером и прокси.
Не знаю много об этой вещи, но у меня никогда не было проблем с этим в течение многих лет. Это просто работает.
Особый случай HTTPS - Прозрачный Прокси
Заметка о прозрачном прокси. (т.е. прокси-сервер скрыт и перехватывает запросы клиентов, а-ля man-in-the-middle).
Прозрачные прокси ломают HTTPS. Клиент не знает, что есть прокси-сервер, и у него нет причин использовать специальный метод Connect.
Клиент пытается установить прямое HTTPS-соединение ... которое перехвачено. Перехват обнаружен и ошибки выбрасываются повсюду. (HTTPS предназначен для обнаружения атак «человек посередине»).
Белый список доменов и CDN
Белый список доменов и поддоменов полностью поддерживается squid. Тем не менее, время от времени он может неожиданно проваливаться.
Современные веб-сайты могут иметь все виды переадресации доменов и CDN. Это нарушит ACL, когда люди не приложат лишних усилий, чтобы аккуратно поместить все в один домен.
Иногда встречается установщик или пакет, который хочет вызвать домашний сервер или получить внешние зависимости перед запуском. Он будет терпеть неудачу каждый раз, и вы ничего не можете с этим поделать.
Кэширование
Предоставленный файл конфигурации отключает все формы кэширования. Береженого Бог бережет.
Лично я запускаю вещи в облаке на данный момент, все экземпляры имеют подключение не менее 100 Мбит / с, и провайдер запускает собственные репозитории для популярных вещей (например, Debian), которые обнаруживаются автоматически. Это делает пропускную способность товаром, о котором мне наплевать.
Я бы предпочел полностью отключить кеширование, чем испытать одну ошибку кеширования, которая растопит мой мозг при устранении неполадок Каждый человек в Интернете НЕ МОЖЕТ получить правильные заголовки кэширования.
Не все среды предъявляют одинаковые требования. Вы можете пройти лишнюю милю и настроить кэширование.
НИКОГДА не требуйте аутентификации на прокси
Существует возможность требовать аутентификацию по паролю от клиентов, как правило, с их учетными записями LDAP. Это сломает каждый браузер и каждый инструмент командной строки во вселенной.
Если вы хотите выполнить аутентификацию на прокси, не делайте этого.
Если руководство хочет аутентификацию, объясните, что это невозможно.
Если вы разработчик, и вы только что присоединились к компании, которая блокирует прямой доступ к Интернету и вынуждает использовать прокси-аутентификацию, БЕГАЙТЕ, ЧТОБЫ ВЫ МОЖЕТЕ.
Вывод
Мы прошли через общую конфигурацию, распространенные ошибки и вещи, которые нужно знать о прокси.
Урок выучен:
- Есть хорошее ПО с открытым исходным кодом для проксирования (squid)
- Это просто и легко настроить (один короткий файл)
- Все (необязательные) меры безопасности имеют компромисс
- Самые продвинутые опции будут ломать вещи и возвращаться, чтобы преследовать вас
- Прозрачные прокси ломают HTTPS
- Проверка подлинности прокси это зло
Как обычно в программировании и проектировании системы, очень важно управлять требованиями и ожиданиями.
Я бы рекомендовал придерживаться основ при настройке прокси. Вообще говоря, простой прокси-сервер без какой-либо конкретной фильтрации будет работать хорошо и не доставлять никаких проблем. Просто не забудьте (авто) настроить клиентов.
Это не решит все ваши задачи, но, возможно, это все еще полезно. Несмотря на название, apt-cacher-ng работает не только с Debian и его производными, но и
Я использую это в производстве в аналогичной (на основе Debian) среде, как ваша.
Однако, AFAIK, он не поддерживает rubygems, PyPI, PECL, CPAN или npm и не предоставляет детализированные ACL.
Лично я считаю, что исследование Squid - хорошая идея. Если вы реализовали настройку в конце, не могли бы вы поделиться своим опытом? Я довольно заинтересован в том, как это идет.
источник
у нас была похожая проблема, и мы решили ее, используя локальные репозитории и систему хранения на основе снимков. Мы в основном обновляем репозиторий разработки, клонируем его для тестирования, клонируем его для подготовки и, наконец, для производства. Количество используемого диска ограничено таким образом, плюс все это медленное хранилище sata, и это нормально.
Клиенты получают информацию о репозитории из нашего управления конфигурацией, поэтому переключение легко при необходимости.
Вы можете достичь того, чего хотите, используя тузы на прокси-сервере, используя строки user-agent или исходные комбинации ips / mask и ограничивая их доступ к определенным доменам, но если вы сделаете это, я вижу проблему с разными версиями пакетов / библиотек. Поэтому, если один из хостов может получить доступ к cpan и запрашивает модуль xxx :: yyy, если только клиент не дает указание использовать конкретную версию, он извлечет последнюю версию из cpan (или pypy или rubygems), который может быть или не быть тем, который уже был кешируется в прокси. Таким образом, вы можете получить разные версии в одной среде. У вас не будет этой проблемы, если вы используете локальные репозитории.
источник