Сайтовете се зареждат през 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 или backend snap, фрагментът на APT не променя нищо за него, затова проверете кой процес е направил неуспешната заявка.
Проверете пътя, не само кода на изхода
С фрагмента на място наблюдавайте заявката, вместо да вярвате на зелен резултат. apt-get -o Debug::Acquire::http=true update извежда опита за връзка, избраното прокси и кода на отговора, което разграничава грешно прокси от прокси, което ви е отказало.
След това проверете случая, който не би трябвало да работи. Изключете VPN и потвърдете, че вътрешното огледало спира да отговаря; ако все още изтегля, нещо маршрутизира покрай тунела или ви обслужва остарял кеш. Потвърдете, че разрешеният път все още проверява TLS и все още проверява подписите на хранилището, защото прокси, което инспектира трафика, не е причина да изключите нито едното, нито другото. Потвърдете също, че неудостоверен клиент получава ясен отказ, а не тих таймаут.
Пазете работещия фрагмент и неуспешния изход заедно в записа за промени. Следващият човек, който попадне на същото забиване, ще разпознае разликата от два реда по-бързо от всяко обяснение.