Webbplatser laddar över VPN:en, men apt når inte repositoriet

VPN:en ansluter, den interna wikin laddas i webbläsaren, och apt update hänger fortfarande på en spegel som den inte kan nå. Ingenting med tunneln är trasigt i den bilden. Webbläsaren och pakethanteraren fattade två separata proxybeslut, och bara ett av dem var konfigurerat.

Vilket beslut som misslyckades är det enda som är värt att fastställa först.

Läs felet innan du rör en inställning

Varje steg lämnar ett annat meddelande. Ett namn som aldrig löses upp är DNS, en anslutning som aldrig slutförs är routing eller en brandvägg, en omedelbar 407 är proxyautentisering, ett klagomål på certifikatet är TLS-verifiering och en signaturvarning är repositoriets metadata. De fem felen kräver fem olika åtgärder, och en proxyrad som klistras över ett DNS-problem flyttar bara hängningen.

Kopiera den exakta raden och det repo den namnger innan du ändrar något. Ett vagt minne av ”det tog timeout” är det som gör en tio minuters diagnos till en hel eftermiddag.

APT har egna proxyinställningar

APT läser /etc/apt/apt.conf.d/, huvudfilen apt.conf och varje fil som APT_CONFIG anger. Den läser inte en proxyprofil från skrivbordet, en nätverksinställning i GNOME eller ett webbläsartillägg. Transporten respekterar däremot proxy-miljövariabler, och därför bevisar en fungerande export https_proxy=... i ditt skal ingenting om en timer som körs i en annan miljö.

Dumpa vad den misslyckade processen faktiskt ser: apt-config dump | grep -i proxy.

Kör det som den användare den misslyckade åtgärden körs som. Om root läser en annan uppsättning filer, eller en systemd-timer startar med en annan miljö, kommer dumpen att skilja sig, och skillnaden är ditt svar. Två proxyvärden som inte stämmer överens är värre än ett saknat värde, eftersom transporten följer den mest specifika matchning den hittar.

Sätt proxyn där konfigurationens ägare förväntar sig den

För en explicit proxy som administratören har godkänt räcker ett litet fragment i en ny fil:

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

Den tredje raden är den del som de flesta exempel utelämnar. En nyckel per värd åsidosätter det generiska värdet, så en intern spegel som nås via tunneln kan hoppa över proxyn medan allt annat fortfarande går genom den. DIRECT är det dokumenterade värdet för det, inte en tom sträng.

Lägg till fragmentet som en ny numrerad fil, till exempel /etc/apt/apt.conf.d/95proxy. Att skriva över en distributionsfil betyder att nästa paketuppdatering tyst återställer din ändring.

Uppgifter hålls utanför URI:n

Den referens för APT-transporten pekar på apt_auth.conf för autentisering, och det är där användarnamn och lösenord hör hemma. Att bädda in dem i proxy-URI:n placerar dem i processlistor, skalhistorik och varje konfigurationsdump som klistras in i ett ärende. Auth-filen behöver restriktiva behörigheter, eftersom den är ett förråd för inloggningsuppgifter.

Kontrollera även schemat. Ett HTTPS-repo kan fortfarande nås via en HTTP-proxy; transporten är ett separat val från spegelns URI-schema.

Ett grafiskt programvarucenter är ett separat gränssnitt. Om det använder PackageKit eller en snap-backend ändrar APT-fragmentet ingenting för det, så bekräfta vilken process som gjorde den misslyckade begäran.

Bekräfta vägen, inte bara slutkoden

Med fragmentet på plats, titta på begäran i stället för att lita på ett grönt resultat. apt-get -o Debug::Acquire::http=true update skriver ut anslutningsförsöket, den valda proxyn och svarskoden, vilket skiljer en felaktig proxy från en proxy som nekade dig.

Testa sedan fallet som inte borde fungera. Koppla från VPN:en och bekräfta att den interna spegeln slutar svara; om den fortfarande laddar ner dirigerar något runt tunneln eller så serverar en inaktuell cache dig. Bekräfta att den tillåtna vägen fortfarande verifierar TLS och fortfarande kontrollerar repositoriets signaturer, för en proxy som inspekterar trafik är inte ett skäl att stänga av något av dem. Bekräfta också att en oautentiserad klient får ett tydligt avslag i stället för en tyst timeout.

Håll det fungerande fragmentet och den misslyckade utdatan tillsammans i ändringsloggen. Nästa person som stöter på samma hängning känner igen skillnaden på två rader snabbare än någon förklaring.