Websites laden via de VPN, maar apt bereikt de repository niet

De VPN maakt verbinding, de interne wiki laadt in de browser, en apt update blijft hangen op een mirror die het niet kan bereiken. Aan die afbeelding is niets aan de tunnel stuk. De browser en de pakketbeheerder namen twee afzonderlijke proxybeslissingen, en slechts één daarvan was geconfigureerd.

Welke beslissing faalde, is het enige dat eerst vastgesteld moet worden.

Lees de fout voordat je een instelling aanraakt

Elke fase laat een andere melding achter. Een naam die nooit oplost is DNS, een verbinding die nooit tot stand komt is routing of een firewall, een onmiddellijke 407 is proxyauthenticatie, een klacht over het certificaat is TLS-verificatie, en een handtekeningwaarschuwing is repositorymetadata. Die vijf fouten vragen vijf verschillende oplossingen, en een proxyregel die over een DNS-probleem wordt geplakt, verplaatst alleen het hangen.

Kopieer de exacte regel en de repository die erin genoemd wordt voordat je iets wijzigt. Een vaag gevoel van „het liep in een time-out“ is wat een diagnose van tien minuten in een middag verandert.

APT houdt eigen proxyinstellingen bij

APT leest /etc/apt/apt.conf.d/, het apt.conf-hoofdbestand en elk bestand dat APT_CONFIG noemt. Het leest geen proxyprofiel van de desktop, geen netwerkinstelling van GNOME en geen browserextensie. Het transport respecteert wel proxy-omgevingsvariabelen, en daarom bewijst een werkende export https_proxy=... in je shell niets over een timer die in een andere omgeving draait.

Dump wat het falende proces werkelijk ziet: apt-config dump | grep -i proxy.

Voer dat uit als de gebruiker waaronder de falende bewerking draait. Als root een andere set bestanden leest, of een systemd-timer met een andere omgeving start, zal de dump verschillen, en dat verschil is je antwoord. Twee proxywaarden die elkaar tegenspreken zijn erger dan één ontbrekende waarde, omdat het transport de meest specifieke overeenkomst volgt die het vindt.

Stel de proxy in waar de eigenaar van de configuratie hem verwacht

Voor een door de beheerder goedgekeurde expliciete proxy is een klein fragment in een nieuw bestand genoeg:

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

De derde regel is het deel dat de meeste voorbeelden weglaten. Een sleutel per host overschrijft de algemene waarde, dus een interne mirror die via de tunnel bereikbaar is kan de proxy overslaan terwijl al het andere er nog steeds doorheen gaat. DIRECT is de gedocumenteerde waarde daarvoor, geen lege tekenreeks.

Voeg het fragment toe als een nieuw genummerd bestand, bijvoorbeeld /etc/apt/apt.conf.d/95proxy. Een distributiebestand overschrijven betekent dat de volgende pakketupdate je wijziging stilzwijgend terugdraait.

Inloggegevens blijven buiten de URI

De referentie voor het APT-transport verwijst voor authenticatie naar apt_auth.conf, en daar horen de gebruikersnaam en het wachtwoord thuis. Ze in de proxy-URI stoppen brengt ze in proceslijsten, in de shellgeschiedenis en in elke configuratiedump die in een ticket wordt geplakt. Het auth-bestand heeft beperkende rechten nodig, want het is een opslagplaats voor inloggegevens.

Controleer ook het schema. Een HTTPS-repository is nog steeds via een HTTP-proxy te bereiken; het transport is een aparte keuze naast het URI-schema van de mirror.

Een grafisch softwarecentrum is een aparte voorkant. Gebruikt het PackageKit of een snap-backend, dan verandert het APT-fragment daar niets voor, dus controleer welk proces het mislukte verzoek deed.

Controleer het pad, niet alleen de exitcode

Kijk met het fragment op zijn plaats naar het verzoek in plaats van een groen resultaat te vertrouwen. apt-get -o Debug::Acquire::http=true update drukt de verbindingspoging, de gekozen proxy en de responscode af, wat een verkeerde proxy scheidt van een proxy die je weigerde.

Test daarna het geval dat niet zou moeten werken. Verbreek de VPN en controleer dat de interne mirror stopt met antwoorden; als hij nog steeds downloadt, leidt iets om de tunnel heen of bedient een verouderde cache je. Controleer dat het toegestane pad nog steeds TLS verifieert en nog steeds repositoryhandtekeningen controleert, want een proxy die verkeer inspecteert is geen reden om een van beide uit te zetten. Controleer ook dat een niet-geauthenticeerde client een duidelijke weigering krijgt in plaats van een stille time-out.

Bewaar het werkende fragment en de falende uitvoer samen in het wijzigingslog. De volgende persoon die tegen hetzelfde hangen aanloopt, herkent het verschil van twee regels sneller dan welke uitleg ook.