Российские зеркала репозиториев: как переключиться и что проверить после

MAATRIX

apt update зависает на середине списка пакетов, dnf падает по таймауту на конкретном baseurl, а apt-get install иногда обрывается на скачивании одного и того же .deb — для серверов, которые физически стоят или администрируются из России, это не разовый сбой, а фон, к которому многие уже привыкли. Один из рабочих способов снять эту нестабильность — переключить источник пакетов на репозиторий, зеркалирующий тот же дистрибутив, но с более предсказуемой доступностью из России. Ниже — как это сделать, не сломав механизм проверки подлинности пакетов, и что обязательно проверить сразу после переключения, чтобы не обнаружить через месяц, что зеркало давно не обновлялось.

Почему оригинальные репозитории становятся ненадёжными

Проблема почти всегда сетевая, а не в самом репозитории. Маршрут до зарубежного источника пакетов идёт через каналы, качество которых непредсказуемо меняется день ото дня: то, что вчера скачивалось за секунды, сегодня растягивается на минуты или обрывается на середине. Многие крупные дистрибутивы раздают пакеты через один и тот же набор CDN — и когда конкретный диапазон IP этого CDN попадает под ограничения вместе с другими, никак не связанными с Linux сервисами, репозиторий становится недоступен как побочный эффект, а не как цель.

Отсюда характерная картина: сегодня всё работает штатно, завтра apt update виснет на archive.ubuntu.com, послезавтра снова всё в порядке. Для разового сбоя обычно достаточно подождать или вручную дёрнуть команду ещё раз. Но если недоступность повторяется неделя за неделей, а патчи безопасности откладываются, потому что сервер физически не может достучаться до источника пакетов в момент планового обновления — это уже основание держать более стабильный канал.

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

Как выбрать зеркало, которому можно доверять

Прежде чем что-либо менять на сервере, стоит на несколько минут задержаться на самом выборе источника — ошибка здесь дороже, чем в любом другом шаге переключения.

Признаки, на которые стоит смотреть:

• Присутствие в официальном списке зеркал дистрибутива. У большинства крупных дистрибутивов публикуется официальный реестр зеркал — попадание в него обычно означает, что зеркало прошло минимальную верификацию мейнтейнерами и синхронизируется по стандартному протоколу. Адрес из случайного форума или Telegram-канала, которого нет ни в одном официальном списке, — повод проверить его тщательнее, а не сразу прописывать в конфиг.
• Понятный оператор. За зеркалом должна стоять узнаваемая организация — учебное заведение, дата-центр, хостинг-провайдер или ИТ-компания с публичными контактами, а не анонимный домен без информации о том, кто его поддерживает.
• Поддержка HTTPS. Само по себе не защищает от преднамеренно вредоносного зеркала, но закрывает пассивный перехват и подмену на промежуточных узлах — это минимальное требование, а не опция.
• Публичная информация о времени последней синхронизации. Хорошо администрируемые зеркала показывают дату обновления явно (статус-страница, файл с меткой времени) либо это можно вычислить косвенно — по заголовку Date в Release/InRelease для apt или repomd.xml для rpm.
• Стандартная структура каталогов и неизменная модель доверия. Зеркало должно повторять оригинал один в один, без пересборки пакетов и без замены метаданных. Любое зеркало, требующее отключить проверку подписи или добавить незнакомый GPG-ключ вместо оригинального, не заслуживает использования — независимо от скорости.
• Срок существования. Зеркало, стабильно работающее не первый год и упоминаемое независимо (в документации других проектов, в обсуждениях администраторов), в среднем надёжнее только что появившегося домена.

Если ни один вариант не удовлетворяет этим критериям, часто разумнее не искать компромиссное готовое зеркало, а поднять кэширующий прокси перед оригинальным репозиторием — он не хранит весь репозиторий заранее, а прозрачно кэширует то, что реально запрашивается. Подход разобран в статье про кэширующий прокси для apt и yum на своём сервере.

Переключение источников пакетов: apt и yum/dnf

Механика переключения простая и одинаковая по сути для всех deb- и rpm-систем: замена адреса сервера в конфигурации источников при сохранении названия релиза, веток и компонентов.

Debian/Ubuntu. До relativно недавних релизов список источников хранится в /etc/apt/sources.list и файлах /etc/apt/sources.list.d/*.list. На свежих системах (начиная примерно с Ubuntu 24.04) используется формат deb822 — единый файл вида /etc/apt/sources.list.d/ubuntu.sources с секциями URIs:. Перед правкой — обязательно бэкап:

cp /etc/apt/sources.list /etc/apt/sources.list.bak.$(date +%F)

Классический формат (sources.list):

# было
deb http://archive.ubuntu.com/ubuntu noble main restricted universe multiverse
deb http://archive.ubuntu.com/ubuntu noble-updates main restricted universe multiverse
deb http://archive.ubuntu.com/ubuntu noble-security main restricted universe multiverse

# стало (адрес зеркала — пример, подставьте реальный проверенный адрес)
deb http://mirror.example.ru/ubuntu noble main restricted universe multiverse
deb http://mirror.example.ru/ubuntu noble-updates main restricted universe multiverse
deb http://mirror.example.ru/ubuntu noble-security main restricted universe multiverse

Формат deb822 (ubuntu.sources):

Types: deb
URIs: http://mirror.example.ru/ubuntu
Suites: noble noble-updates noble-security
Components: main restricted universe multiverse
Signed-By: /usr/share/keyrings/ubuntu-archive-keyring.gpg

Обратите внимание на Signed-By — это ключ проверки подписи, и он должен остаться оригинальным ключом дистрибутива, а не каким-либо ключом, предоставленным оператором зеркала.

RPM-системы (RHEL-совместимые, включая отечественные RPM-дистрибутивы). Источники описываются файлами /etc/yum.repos.d/*.repo, там меняется параметр baseurl (или mirrorlist, если репозиторий использует метабалансировщик — в этом случае прямая замена не нужна, достаточно указать региональный список):

[baseos]
name=BaseOS
baseurl=http://mirror.example.ru/rpm/baseos
enabled=1
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-original

Ключевое здесь — gpgcheck=1 и gpgkey, указывающий на оригинальный ключ дистрибутива, должны остаться без изменений. Если какая-либо инструкция по переключению на зеркало советует поставить gpgcheck=0 «чтобы заработало» — это красный флаг, и правильный путь другой: разобраться, почему проверка подписи не проходит, а не отключать её.

После правки — обновление индексов и контрольная установка любого некритичного пакета:

apt update && apt install -y curl
# или для rpm-систем
dnf makecache && dnf install -y curl

Если серверов несколько, логичнее не редактировать файлы вручную на каждом, а завести замену адреса в механизм, которым разворачивается конфигурация (Ansible, cloud-init, скрипт по SSH в цикле), а для новых серверов сразу заложить проверенный адрес зеркала в шаблон первичной настройки — это один из пунктов, которые стоит держать в чек-листе безопасности нового сервера.

Проверка после переключения: актуальность и полнота зеркала

Само по себе успешное выполнение apt update без ошибок ещё не значит, что зеркало пригодно для постоянного использования. Стоит проверить три вещи отдельно.

Свежесть метаданных. У apt-репозиториев в файле Release/InRelease есть заголовки Date и Valid-Until — по ним видно, когда зеркало последний раз синхронизировалось и до какого момента метаданные считаются действительными:

curl -s http://mirror.example.ru/ubuntu/dists/noble/InRelease | grep -E '^(Date|Valid-Until):'

Для rpm сопоставимая проверка — время изменения repodata/repomd.xml:

curl -sI http://mirror.example.ru/rpm/baseos/repodata/repomd.xml | grep -i last-modified

Если дата заметно отстаёт (счёт на недели, а не на часы или дни), зеркало, скорее всего, синхронизируется нерегулярно или сломано, и полагаться на него для патчей безопасности рискованно.

Полнота компонентов. Частая проблема неофициальных или частичных зеркал — они зеркалируют не все компоненты или не все архитектуры. Проверяется просто: apt update должен пройти без 404, а apt-cache policy <пакет> — показывать версию из ожидаемого источника для набора пакетов, которые вы реально используете:

apt-cache policy nginx docker-ce postgresql-16

Если для нужного пакета кандидат на установку не находится вовсе или подтягивается с fallback-адреса — зеркало неполное, и на него нельзя полагаться как на единственный источник.

Регулярность, а не разовая проверка. Зеркало, актуальное в момент переключения, может начать отставать через недели без видимого сигнала — apt update продолжит отрабатывать без ошибок, просто молча показывая более старые версии пакетов. Разумно завести периодическую (например, еженедельную) проверку той же команды с Date/Valid-Until, а ещё лучше — сравнение версии одного-двух ключевых пакетов безопасности с версией у апстрима. Похожий по сути вопрос синхронизации возникает и при сборках в CI — разбор ситуации есть в статье про то, почему сборка падает из-за недоступного зеркала.

Целостность пакетов: контрольные суммы и подписи

Главная защита от подмены пакета — не сам факт, что зеркало «выглядит надёжно», а то, что apt и dnf проверяют подлинность метаданных и пакетов криптографически, независимо от того, кто физически раздаёт файлы.

Механизм для apt: файл Release подписывается GPG-ключом дистрибутива, подпись лежит в Release.gpg (или встроена в InRelease), а сам Release содержит контрольные суммы (SHA256) файлов Packages, которые в свою очередь содержат контрольные суммы каждого .deb-пакета. Зеркало физически копирует эти файлы как есть — оно не может незаметно подменить пакет, не подделав всю цепочку подписей, а без приватного ключа дистрибутива это невозможно. Ровно поэтому критично не менять ключ проверки подписи при переключении на зеркало: сохранённая цепочка доверия (Signed-By в apt, gpgkey в yum/dnf) — то, что делает использование стороннего зеркала безопасным в принципе.

Проверить цепочку вручную можно так:

# apt — проверка подписи Release
gpg --verify /var/lib/apt/lists/mirror.example.ru_ubuntu_dists_noble_InRelease

# rpm — проверка конкретного пакета против его подписи
rpm -K --nosignature=0 /path/to/package.rpm
rpm -qa gpg-pubkey --qf '%{summary}\n'

Для дистрибутивов с собственными ключами подписи (например, отечественные RPM-based системы, где пакеты пересобираются и подписываются вендором отдельно от апстрима) важно свериться, что ключ, установленный при настройке зеркала, совпадает с ключом, опубликованным самим вендором в официальной документации, а не подсунут оператором зеркала «для удобства». Отпечаток ключа (gpg --fingerprint) стоит сверять построчно — это единственное место в цепочке, где легковерность реально открывает возможность для атаки.

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

Риски использования непроверенного зеркала

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

Компрометация цепочки поставки. Если зеркало действует как «прозрачный» прокси с возможностью модификации ответов (или скомпрометировано на уровне хостинга), а проверка подписи по какой-то причине отключена или ослаблена — это открывает путь к подмене пакета вредоносной версией на этапе установки. Это тот сценарий, который делает бессмысленным любой совет «отключите gpgcheck, чтобы зеркало заработало»: отключённая проверка убирает единственную защиту, делающую использование стороннего зеркала в принципе безопасным.

Тихая деградация актуальности. Зеркало, переставшее синхронизироваться, не подаёт явных сигналов — apt update продолжает отрабатывать успешно, просто выдавая всё более старые версии пакетов. Это создаёт ложное чувство защищённости: команда выполняется без ошибок, а критичный патч безопасности физически не устанавливается неделями. Разовая проверка при переключении здесь не спасает — нужен периодический контроль, описанный выше.

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

Частые вопросы