У меня есть набор серверов CentOS в моей корпоративной сети. По соображениям безопасности большинство серверов не имеют общего исходящего доступа в Интернет, если это не является основным функциональным требованием для сервера.
Это создает проблему, когда мне нужно обновить пакеты. Для репозиториев yum я сейчас зеркалирую все необходимые репозитории из Интернета и делаю зеркала доступными внутри интрасети. Я храню копии каждого репо в каждой из наших пяти сред: dev, QA, staging и два производственных центра обработки данных.
В настоящее время я не решаю проблемы репозиториев пакетов для конкретных языков. Когда серверам требуется обновление с помощью rubygems, PyPI, PECL, CPAN или npm, им необходимо получить временный исходящий доступ в Интернет для получения пакетов. Меня попросили начать зеркалирование rubygems и PyPI, а остальное, вероятно, последует.
Все это неуклюже и плохо работает. Я хотел бы заменить его одним кэширующим прокси-сервером в одной среде и четырьмя гирляндными прокси-серверами в других моих средах, чтобы устранить сложность и накладные расходы на диск, связанные с полными зеркалами. Дополнительно:
Изначально я рассматривал обратные прокси-серверы, и Varnish, похоже, единственный, который позволил бы мне внутренне разрешать 302 редиректа внутри прокси. Однако бесплатная версия Varnish не поддерживает серверные части HTTPS. Сейчас я оцениваю Squid как вариант прямого прокси.
Это похоже на то, что должно быть относительно распространенной проблемой в корпоративных сетях, но мне трудно найти примеры того, как другие люди решили эту проблему. Кто-нибудь реализовал что-то подобное или есть мысли, как это лучше сделать?
Спасибо!
Для этого мы используем Squid; Хорошая вещь в squid заключается в том, что вы можете довольно легко установить индивидуальный срок действия объектов на основе сопоставления с образцом, что позволяет довольно быстро очищать метаданные из репозитория yum. У нас есть конфигурация, которая реализует это:
refresh_pattern (Release|Packages(.gz)*)$ 0 20% 2880
refresh_pattern (\.xml|xml\.gz)$ 0 20% 2880
refresh_pattern ((sqlite.bz2)*)$ 0 20% 2880
refresh_pattern (\.deb|\.udeb)$ 1296000 100% 1296000
refresh_pattern (\.rpm|\.srpm)$ 1296000 100% 1296000
refresh_pattern . 0 20% 4320
Это окончательный вариант использования прокси. Обычный прокси, а не обратный прокси (он же балансировщик нагрузки).
Самый известный и бесплатный с открытым исходным кодом - это 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 полностью поддерживается дизайном. Он использует специальный метод «CONNECT», который устанавливает своего рода туннель между браузером и прокси.
Я ничего не знаю об этом, но у меня никогда не было проблем с этим. Просто работает.
Замечание о прозрачном прокси. (т.е. прокси скрыт и перехватывает запросы клиентов, например, человек посередине).
Прозрачные прокси нарушают HTTPS. Клиент не знает, что существует прокси, и у него нет причин использовать специальный метод Connect.
Клиент пытается установить прямое HTTPS-соединение ... которое перехватывается. Обнаружен перехват, и повсюду разбрасываются ошибки. (HTTPS предназначен для обнаружения атак типа "человек в середине").
Вайтлистинг доменов и субдоменов полностью поддерживается squid. Тем не менее, время от времени он неизбежно терпит неудачу.
Современные веб-сайты могут иметь всевозможные перенаправления доменов и CDN. Это нарушит ACL, если люди не приложат лишних усилий, чтобы аккуратно разместить все в одном домене.
Иногда будет установщик или пакет, который хочет вызвать домохозяйство или получить внешние зависимости перед запуском. Он будет давать сбой каждый раз, и вы ничего не можете с этим поделать.
Предоставленный файл конфигурации отключает все формы кеширования. Береженого Бог бережет.
Лично я сейчас запускаю что-то в облаке, все экземпляры имеют скорость подключения не менее 100 Мбит / с, а провайдер запускает собственные репозитории для популярных вещей (например, Debian), которые обнаруживаются автоматически. Это делает пропускную способность товаром, о котором мне наплевать.
Я лучше полностью отключу кеширование, чем столкнусь с единственной ошибкой кеширования, которая растопит мой мозг при устранении неполадок. Каждый человек в Интернете НЕ МОЖЕТ получить правильные заголовки кеширования.
Однако не все среды предъявляют одинаковые требования. Вы можете приложить дополнительные усилия и настроить кеширование.
Существует возможность потребовать аутентификацию по паролю от клиентов, обычно с их учетными записями LDAP. Это нарушит работу всех браузеров и всех инструментов командной строки во вселенной.
Если вы хотите выполнить аутентификацию на прокси, не делайте этого.
Если руководство хочет аутентификации, объясните, что это невозможно.
Если вы разработчик и только что присоединились к компании, которая блокирует прямой доступ в Интернет И принудительно использует аутентификацию через прокси-сервер, УБЕГАЙТЕ, ПОКА ВЫ МОЖЕТЕ.
Мы рассмотрели типичные настройки, типичные ошибки и вещи, которые необходимо знать о проксировании.
Урок выучен:
Как обычно в программировании и проектировании систем, очень важно управлять требованиями и ожиданиями.
Я бы рекомендовал придерживаться основ при настройке прокси. Вообще говоря, простой прокси без какой-либо конкретной фильтрации будет работать хорошо и не доставит никаких проблем. Просто не забудьте (автоматически) настраивать клиентов.
Это не решит всех ваших задач, но, возможно, это все же поможет. Несмотря на название, apt-cacher-ng работает не только с Debian и производными, но и
кеширующий прокси. Специализируется на файлах пакетов от дистрибьюторов Linux, в первую очередь для дистрибутивов Debian (и на основе Debian), но не ограничиваясь ими.
Я использую это в производстве в аналогичной среде (на основе Debian), подобной вашей.
Однако, AFAIK, это не поддерживает rubygems, PyPI, PECL, CPAN или npm и не предоставляет детальные списки ACL.
Лично я считаю, что исследование Squid - хорошая идея. Если вы в конце концов реализуете установку, не могли бы вы поделиться своим опытом? Мне очень интересно, как это происходит.
у нас была аналогичная проблема, и мы решили ее, используя локальные репозитории и систему хранения на основе моментальных снимков. Мы в основном обновляем репозиторий разработки, клонируем его для тестирования, клонируем для постановки и, наконец, для производства. Таким образом, количество используемого диска ограничено, плюс все это медленное хранилище sata, и это нормально.
Клиенты получают информацию о репозитории из нашего управления конфигурациями, поэтому при необходимости легко переключиться.
Вы можете добиться того, чего хотите, используя ace на прокси-сервере, используя строки пользовательского агента или комбинации исходных IP-адресов / масок и ограничивая их доступ к определенным доменам, но если вы сделаете это, я вижу одну проблему, связанную с разными версиями пакетов / библиотек. Таким образом, если один из хостов может получить доступ к cpan и запросить модуль xxx :: yyy, если клиент не укажет использовать определенную версию, будет извлекать последнюю версию из cpan (или pypy или rubygems), которая может быть или не быть той, которая уже была кешируется в прокси. Таким образом, в одной и той же среде могут быть разные версии. У вас не будет этой проблемы, если вы будете использовать локальные репозитории.