Сайты открываются через VPN, но apt не доходит до репозитория
Браузер, работающий через VPN, ничего не говорит о настройках прокси для apt. Прочитайте сбойный этап, выведите действующую конфигурацию, затем задайте прокси, который читает apt.
VPN подключается, внутренняя вики открывается в браузере, а apt update по-прежнему висит на зеркале, до которого не может добраться. На этой картине в туннеле ничего не сломано. Браузер и менеджер пакетов приняли два разных решения о прокси, и настроено было только одно из них.
Какое решение отказало — единственное, что стоит установить первым.
Прочитайте ошибку, прежде чем трогать настройку
Каждый этап оставляет своё сообщение. Имя, которое никогда не разрешается, — это DNS; соединение, которое никогда не завершается, — это маршрутизация или межсетевой экран; мгновенный 407 — это аутентификация на прокси; жалоба на сертификат — это проверка TLS; а предупреждение о подписи — это метаданные репозитория. Эти пять сбоев требуют пяти разных исправлений, и строка прокси, вставленная поверх проблемы с DNS, лишь переносит зависание.
Скопируйте точную строку и репозиторий, который в ней назван, прежде чем что-то менять. Смутное воспоминание «оно упало по таймауту» — это то, что превращает десятиминутную диагностику в целый день.
APT хранит собственные настройки прокси
APT читает /etc/apt/apt.conf.d/, основной apt.conf и любой файл, указанный в APT_CONFIG. Он не читает профиль прокси рабочего стола, сетевую настройку GNOME или расширение браузера. Транспорт же учитывает переменные окружения прокси, поэтому работающий export https_proxy=... в вашей оболочке ничего не доказывает о таймере, который запускается в другом окружении.
Выведите то, что на самом деле видит сбойный процесс: apt-config dump | grep -i proxy.
Запустите это от имени того пользователя, под которым работает сбойная операция. Если root читает другой набор файлов или таймер systemd стартует в другом окружении, вывод будет отличаться, и это различие и есть ваш ответ. Два противоречащих значения прокси хуже одного отсутствующего, потому что транспорт следует самому конкретному совпадению, которое находит.
Задайте прокси там, где его ожидает владелец конфигурации
Для явного прокси, одобренного администратором, достаточно небольшого фрагмента в новом файле:
Acquire::http::Proxy "http://proxy.corp.example:3128/";
Acquire::https::Proxy "http://proxy.corp.example:3128/";
Acquire::http::Proxy::archive.example.internal "DIRECT";Третья строка — та часть, которую большинство примеров опускает. Ключ для отдельного хоста перекрывает общее значение, поэтому внутреннее зеркало, доступное через туннель, может обойти прокси, пока всё остальное по-прежнему идёт через него. DIRECT — задокументированное значение для этого, а не пустая строка.
Добавьте фрагмент как новый нумерованный файл, например /etc/apt/apt.conf.d/95proxy. Перезапись файла дистрибутива означает, что следующее обновление пакетов молча отменит ваше изменение.
Учётные данные остаются вне URI
Справочник транспорта APT для аутентификации указывает на apt_auth.conf, и именно там место имени пользователя и паролю. Если встроить их в URI прокси, они попадут в списки процессов, в историю оболочки и в каждый дамп конфигурации, вставленный в тикет. Файлу аутентификации нужны строгие права, потому что это хранилище учётных данных.
Проверьте и схему. Репозиторий HTTPS по-прежнему доступен через прокси HTTP; транспорт — это отдельный выбор от схемы URI зеркала.
Графический центр программ — отдельный интерфейс. Если он использует PackageKit или бэкенд snap, фрагмент APT для него ничего не меняет, поэтому уточните, какой процесс сделал неудачный запрос.
Проверьте путь, а не только код выхода
Когда фрагмент на месте, наблюдайте за запросом вместо того, чтобы доверять зелёному результату. apt-get -o Debug::Acquire::http=true update выводит попытку соединения, выбранный прокси и код ответа, что отделяет неверный прокси от прокси, который вам отказал.
Затем проверьте случай, который работать не должен. Отключите VPN и убедитесь, что внутреннее зеркало перестаёт отвечать; если оно всё ещё скачивает, что-то маршрутизирует в обход туннеля или вас обслуживает устаревший кеш. Убедитесь, что разрешённый путь по-прежнему проверяет TLS и по-прежнему проверяет подписи репозитория, потому что прокси, который инспектирует трафик, не повод отключать ни то, ни другое. Убедитесь также, что неаутентифицированный клиент получает ясный отказ, а не молчаливый таймаут.
Держите рабочий фрагмент и сбойный вывод вместе в записи об изменениях. Следующий человек, наткнувшийся на то же зависание, узнает разницу в две строки быстрее, чем из любого объяснения.