VPN se připojí, interní wiki se načte v prohlížeči a apt update stále visí na zrcadle, které nedokáže dosáhnout. Na tom obrázku není na tunelu nic rozbité. Prohlížeč a správce balíčků učinily dvě samostatná rozhodnutí o proxy, a nakonfigurováno bylo jen jedno z nich.

Které rozhodnutí selhalo, je jediné, co má smysl určit nejdřív.

Přečtěte chybu, než se dotknete nastavení

Každá fáze zanechá jinou zprávu. Jméno, které se nikdy nepřeloží, je DNS; spojení, které se nikdy nedokončí, je routování nebo firewall; okamžitá 407 je autentizace proxy; stížnost na certifikát je ověřování TLS; a varování k podpisu jsou metadata repozitáře. Těch pět poruch potřebuje pět různých oprav a řádek s proxy vložený přes problém s DNS jen posune zaseknutí.

Zkopírujte přesný řádek a repozitář, který pojmenovává, než cokoli změníte. Vágní vzpomínka „vypršel časový limit“ je to, co z desetiminutové diagnózy udělá celé odpoledne.

APT si drží vlastní nastavení proxy

APT čte /etc/apt/apt.conf.d/, hlavní apt.conf a každý soubor uvedený v APT_CONFIG. Nečte profil proxy z plochy, nastavení sítě v GNOME ani rozšíření prohlížeče. Transport ale respektuje proměnné prostředí pro proxy, a proto funkční export https_proxy=... ve vašem shellu nic nedokazuje o časovači, který běží v jiném prostředí.

Vypište, co selhávající proces skutečně vidí: apt-config dump | grep -i proxy.

Spusťte to jako uživatel, pod kterým běží selhávající operace. Pokud root čte jinou sadu souborů nebo časovač systemd startuje v jiném prostředí, výpis se bude lišit, a ten rozdíl je vaše odpověď. Dvě hodnoty proxy, které si odporují, jsou horší než jedna chybějící, protože transport následuje nejkonkrétnější shodu, kterou najde.

Nastavte proxy tam, kde ji vlastník konfigurace očekává

Pro explicitní proxy schválenou správcem stačí malý fragment v novém souboru:

Acquire::http::Proxy "http://proxy.corp.example:3128/";
Acquire::https::Proxy "http://proxy.corp.example:3128/";
Acquire::http::Proxy::archive.example.internal "DIRECT";

Třetí řádek je část, kterou většina příkladů vynechává. Klíč pro hostitele přepisuje obecnou hodnotu, takže interní zrcadlo dostupné přes tunel může proxy přeskočit, zatímco všechno ostatní přes ni stále jde. DIRECT je pro to dokumentovaná hodnota, ne prázdný řetězec.

Přidejte fragment jako nový očíslovaný soubor, například /etc/apt/apt.conf.d/95proxy. Přepsání distribučního souboru znamená, že další aktualizace balíčků vaši změnu tiše vrátí.

Přihlašovací údaje zůstávají mimo URI

Referenční dokumentace transportu APT ukazuje pro autentizaci na apt_auth.conf a tam patří uživatelské jméno a heslo. Vložení do URI proxy je dostane do výpisů procesů, do historie shellu a do každého výpisu konfigurace vloženého do tiketu. Soubor s autentizací potřebuje omezující oprávnění, protože je úložištěm přihlašovacích údajů.

Zkontrolujte i schéma. Repozitář HTTPS lze stále dosáhnout přes proxy HTTP; transport je volba oddělená od schématu URI zrcadla.

Grafické softwarové centrum je samostatné rozhraní. Pokud používá PackageKit nebo backend snap, fragment APT pro něj nic nemění, takže ověřte, který proces neúspěšný požadavek provedl.

Ověřte cestu, ne jen návratový kód

S fragmentem na místě sledujte požadavek, místo abyste věřili zelenému výsledku. apt-get -o Debug::Acquire::http=true update vypíše pokus o připojení, zvolenou proxy a kód odpovědi, což oddělí špatnou proxy od proxy, která vás odmítla.

Potom otestujte případ, který by fungovat neměl. Odpojte VPN a ověřte, že interní zrcadlo přestane odpovídat; pokud stále stahuje, něco směruje mimo tunel nebo vás obsluhuje zastaralá cache. Ověřte, že povolená cesta stále ověřuje TLS a stále kontroluje podpisy repozitáře, protože proxy, která prohlíží provoz, není důvod vypnout ani jedno. Ověřte také, že neautentizovaný klient dostane jasné odmítnutí místo tichého časového limitu.

Uchovejte funkční fragment a selhávající výstup společně v záznamu změn. Další člověk, který narazí na stejné zaseknutí, rozpozná rozdíl dvou řádků rychleji než z jakéhokoli vysvětlení.

Související články