Webwerwe laai oor die VPN, maar apt bereik nie die bewaarplek nie

Die VPN verbind, die interne wiki laai in die blaaier, en apt update hang steeds op ’n spieël wat dit nie kan bereik nie. Niks aan die tonnel is in daardie prentjie stukkend nie. Die blaaier en die pakketbestuurder het twee afsonderlike proxybesluite geneem, en net een daarvan was opgestel.

Watter besluit gefaal het, is die enigste ding wat eerste vasgestel moet word.

Lees die fout voordat jy aan ’n instelling raak

Elke fase laat ’n ander boodskap. ’n Naam wat nooit oplos nie, is DNS; ’n verbinding wat nooit voltooi nie, is roetering of ’n firewall; ’n onmiddellike 407 is proxy-verifikasie; ’n klag oor die sertifikaat is TLS-verifikasie; en ’n waarskuwing oor die handtekening is bewaarplekmetadata. Daardie vyf foute het vyf verskillende regstellings nodig, en ’n proxylyn wat oor ’n DNS-probleem geplak word, skuif net die hang.

Kopieer die presiese reël en die bewaarplek wat dit noem voordat jy enigiets verander. ’n Vae herinnering van „dit het uitgeput“ is wat ’n diagnose van tien minute in ’n middag verander.

APT hou sy eie proxy-instellings

APT lees /etc/apt/apt.conf.d/, die hoof apt.conf en enige lêer wat APT_CONFIG noem. Dit lees nie ’n proxyprofiel van die werkskerm nie, nie ’n GNOME-netwerkinstelling nie en nie ’n blaaieruitbreiding nie. Die transport eerbiedig wel proxy-omgewingsveranderlikes, en daarom bewys ’n werkende export https_proxy=... in jou skulp niks oor ’n tydhouer wat in ’n ander omgewing loop nie.

Dump wat die falende proses werklik sien: apt-config dump | grep -i proxy.

Voer dit uit as die gebruiker onder wie die falende bewerking loop. As root ’n ander stel lêers lees, of ’n systemd-tydhouer met ’n ander omgewing begin, sal die dump verskil, en daardie verskil is jou antwoord. Twee proxywaardes wat mekaar weerspreek is erger as een ontbrekende waarde, want die transport volg die mees spesifieke passing wat dit kan vind.

Stel die proxy waar die eienaar van die konfigurasie dit verwag

Vir ’n eksplisiete proxy wat deur die administrateur goedgekeur is, is ’n klein fragment in ’n nuwe lêer genoeg:

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

Die derde reël is die deel wat die meeste voorbeelde uitlaat. ’n Sleutel per gasheer oorheers die algemene waarde, so ’n interne spieël wat deur die tonnel bereikbaar is kan die proxy oorslaan terwyl alles anders steeds daardeur gaan. DIRECT is die gedokumenteerde waarde daarvoor, nie ’n leë string nie.

Voeg die fragment by as ’n nuwe genommerde lêer, byvoorbeeld /etc/apt/apt.conf.d/95proxy. Om ’n verspreidingslêer te oorskryf beteken die volgende pakketopdatering draai jou verandering stilweg terug.

Geloofsbriewe bly buite die URI

Die verwysing na die APT-transport wys vir verifikasie na apt_auth.conf, en dit is waar die gebruikernaam en wagwoord hoort. Om hulle in die proxy-URI in te bed, sit hulle in proselyste, in die skulpgeskiedenis en in elke konfigurasiedump wat in ’n kaartjie geplak word. Die verifikasielêer het streng beperkings nodig, want dit is ’n stoor van geloofsbriewe.

Kontroleer ook die skema. ’n HTTPS-bewaarplek kan steeds deur ’n HTTP-proxy bereik word; die transport is ’n aparte keuse van die URI-skema van die spieël.

’n Grafiese sagteware-sentrum is ’n aparte frontent. As dit PackageKit of ’n snap-agterkant gebruik, verander die APT-fragment niks daarvoor nie, so bevestig watter proses die mislukte versoek gedoen het.

Bevestig die pad, nie net die uittreekode nie

Met die fragment in plek, kyk na die versoek eerder as om ’n groen resultaat te vertrou. apt-get -o Debug::Acquire::http=true update druk die verbindingspoging, die gekose proxy en die antwoordkode, wat ’n verkeerde proxy skei van ’n proxy wat jou geweier het.

Toets dan die geval wat nie behoort te werk nie. Ontkoppel die VPN en bevestig dat die interne spieël ophou antwoord; as dit steeds aflaai, roeteer iets om die tonnel of ’n verouderde kas bedien jou. Bevestig dat die toegelate pad steeds TLS verifieer en steeds bewaarplekhandtekeninge nagaan, want ’n proxy wat verkeer inspekteer is nie ’n rede om enige van die twee af te skakel nie. Bevestig ook dat ’n ongeverifieerde kliënt ’n duidelike weiering kry eerder as ’n stil tydversaking.

Hou die werkende fragment en die falende uitvoer saam in die veranderingsrekord. Die volgende persoon wat dieselfde hang teëkom, sal die verskil van twee reëls vinniger herken as enige verduideliking.