Лучшая практика для прокси репозиториев пакетов

16

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

Это создает проблему, когда мне нужно обновить пакеты. Для репозиториев yum в настоящее время я зеркалирую все необходимые репозитории из Интернета и делаю зеркала доступными во внутренней сети. Я храню копии каждого репо в каждой из наших пяти сред: dev, QA, staging и два производственных центра обработки данных.

В настоящее время я не использую репозитории для конкретных языков. Когда серверы нуждаются в обновлении от rubygems, PyPI, PECL, CPAN или npm, они должны получить временный исходящий доступ в Интернет для получения пакетов. Меня попросили начать зеркалирование rubygems и PyPI, а остальное, вероятно, последует.

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

  • Это может быть прямой или обратный прокси; каждый менеджер пакетов поддерживает прокси-сервер или настраиваемую конечную точку репозитория, которая может быть либо локальным зеркалом, либо обратным прокси-сервером.
  • Требуется детальный контроль доступа, поэтому я могу ограничить, какие IP-адреса клиентов могут подключаться к каким доменам репо.
  • Клиенты должны иметь возможность отслеживать перенаправления на неизвестные домены. Ваш первоначальный запрос может быть ограничен rubygems.org, но если этот сервер вернет 302 в произвольный CDN, вы сможете его выполнить.
  • Он должен поддерживать HTTPS-серверы. Мне необязательно выдавать себя за другие SSL-серверы, но я должен иметь возможность повторно открыть сайт HTTPS через HTTP или завершить и повторно зашифровать с другим сертификатом.

Сначала я рассматривал обратные прокси-серверы, и Varnish, кажется, единственный, который позволил бы мне внутренне разрешать 302 перенаправления в прокси. Однако бесплатная версия Varnish не поддерживает бэкэнды HTTPS. Сейчас я оцениваю Squid как опцию прямого прокси.

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

Благодарность!

Дейв Смит
источник

Ответы:

5

Мы используем 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

http://www.squid-cache.org/Doc/config/refresh_pattern/

Андрей
источник
5

Это окончательный вариант использования прокси . Обычный прокси, а не обратный прокси (он же балансировщик нагрузки).

Самым известным, бесплатным и открытым исходным кодом является 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, ...) самоконфигурируются с использованием переменных среды. Большинство приложений используют одну из распространенных библиотек и, таким образом, поддерживают прокси из коробки (без необходимости, чтобы разработчик знал, что они делают).

Обратите внимание, что синтаксис строгий:

  1. Имя переменной http_proxyДОЛЖНО быть строчным в большинстве Linux.
  2. Значение переменной НЕ ДОЛЖНО начинаться с 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
  • Проверка подлинности прокси это зло

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

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

user5994461
источник
s / человек посередине / человек посередине / (S / E запрещает редактирование одного символа)
Чен Леви
4

Это не решит все ваши задачи, но, возможно, это все еще полезно. Несмотря на название, apt-cacher-ng работает не только с Debian и его производными, но и

кеширующий прокси. Специализируется на файлах пакетов от дистрибьюторов Linux, в основном для дистрибутивов Debian (и на основе Debian), но не ограничивается ими.

Я использую это в производстве в аналогичной (на основе Debian) среде, как ваша.

Однако, AFAIK, он не поддерживает rubygems, PyPI, PECL, CPAN или npm и не предоставляет детализированные ACL.

Лично я считаю, что исследование Squid - хорошая идея. Если вы реализовали настройку в конце, не могли бы вы поделиться своим опытом? Я довольно заинтересован в том, как это идет.

gf_
источник
2

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

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

Вы можете достичь того, чего хотите, используя тузы на прокси-сервере, используя строки user-agent или исходные комбинации ips / mask и ограничивая их доступ к определенным доменам, но если вы сделаете это, я вижу проблему с разными версиями пакетов / библиотек. Поэтому, если один из хостов может получить доступ к cpan и запрашивает модуль xxx :: yyy, если только клиент не дает указание использовать конкретную версию, он извлечет последнюю версию из cpan (или pypy или rubygems), который может быть или не быть тем, который уже был кешируется в прокси. Таким образом, вы можете получить разные версии в одной среде. У вас не будет этой проблемы, если вы используете локальные репозитории.

natxo asenjo
источник