Websites laadze oer de VPN, mar apt berikt it bewarplak net
In browser dy’t oer de VPN wurket, seit neat oer de proxy-ynstellingen fan apt. Lês de stap dy’t misgiet, dump de effektive konfiguraasje en set dan de proxy dy’t apt lêst.
De VPN ferbynt, de ynterne wiki laadt yn ’e browser, en apt update hinget noch hieltyd op in spegel dy’t it net berikke kin. Oan dat byld is neat fan de tunnel stikken. De browser en de pakketbehearder namen twa aparte proxybesluten, en mar ien fan beide wie konfigurearre.
Hokker beslút misgie, is it iennige dat earst fêststeld wurde moat.
Lês de flater ear’t jo in ynstelling oanreast
Elke stap lit in oare melding efter. In namme dy’t nea oplost is DNS, in ferbining dy’t nea foltôget is routing of in firewall, in direkt 407 is proxy-autentikaasje, in klacht oer it sertifikaat is TLS-ferifikaasje, en in warskôging oer de hantekening is bewarplakmetadat. Dy fiif flaters freegje fiif ferskillende oplossings, en in proxyrige dy’t oer in DNS-probleem plakt wurdt, ferpleatst allinnich it hingjen.
Kopiearje de krekte rigel en it bewarplak dat er neamt ear’t jo wat feroarje. In ûndúdlik oantinken fan „it rûn yn in timeout“ is wat in diagnoaze fan tsien minuten yn in middei feroaret.
APT hâldt eigen proxy-ynstellingen by
APT lêst /etc/apt/apt.conf.d/, it haadbestân apt.conf en elk bestân dat APT_CONFIG neamt. It lêst gjin proxyprofyl fan it buroblêd, gjin netwurkynstelling fan GNOME en gjin browserútwreiding. De transport respektearret wol proxy-omjouwingsfariabelen, en dêrom bewiist in wurkjende export https_proxy=... yn jo shell neat oer in timer dy’t yn in oare omjouwing rint.
Dump wat it misgjende proses echt sjocht: apt-config dump | grep -i proxy.
Fier dat út as de brûker dêr’t de misgjende operaasje ûnder rint. As root in oare set bestannen lêst, of in systemd-timer mei in oare omjouwing start, sil de dump ferskille, en dat ferskil is jo antwurd. Twa proxywearden dy’t elkoar tsjinsprekke binne slimmer as ien ûntbrekkende wearde, omdat de transport de meast spesifike oerienkomst folget dy’t er fine kin.
Set de proxy dêr’t de eigner fan de konfiguraasje him ferwachtet
Foar in eksplisite proxy dy’t troch de behearder goedkard is, is in lyts fragmint yn in nij bestân genôch:
Acquire::http::Proxy "http://proxy.corp.example:3128/";
Acquire::https::Proxy "http://proxy.corp.example:3128/";
Acquire::http::Proxy::archive.example.internal "DIRECT";De tredde rigel is it part dat de measte foarbylden weilitte. In kaai per host oerskriuwt de algemiene wearde, sadat in ynterne spegel dy’t oer de tunnel berikber is de proxy oerslaan kin wylst al it oare der noch trochhinne giet. DIRECT is de dokumintearre wearde dêrfoar, net in lege tekenrige.
Foegje it fragmint ta as in nij nûmere bestân, bygelyks /etc/apt/apt.conf.d/95proxy. In distribúsjebestân oerskriuwe betsjut dat de folgjende pakketfernijing jo feroaring stil weromdraait.
Bewiisstikken bliuwe bûten de URI
De ferwizing nei it APT-transport wiist foar autentikaasje nei apt_auth.conf, en dêr hearre de brûkersnamme en it wachtwurd. Se yn ’e proxy-URI stopje bringt se yn proseslisten, yn ’e shellskiednis en yn elke konfiguraasjedump dy’t yn in ticket plakt wurdt. It autentikaasjebestân hat strange rjochten nedich, want it is in opslach fan bewiisstikken.
Kontrolearje ek it skema. In HTTPS-bewarplak kin noch hieltyd fia in HTTP-proxy berikt wurde; de transport is in aparte kar fan it URI-skema fan de spegel.
In grafysk software-sintrum is in aparte foarkant. As it PackageKit of in snap-backend brûkt, feroaret it APT-fragmint dêr neat foar, dus kontrolearje hokker proses it misgjende fersyk dien hat.
Kontrolearje it paad, net allinnich de útgongskoade
Mei it fragmint op syn plak, sjoch nei it fersyk ynstee fan op in grien resultaat te fertrouwen. apt-get -o Debug::Acquire::http=true update printet de ferbiningspoging, de keazen proxy en de antwurdkoade, wat in ferkearde proxy skiedt fan in proxy dy’t jo wegere.
Test dan it gefal dat net wurkje moatte soe. Koppel de VPN los en beklamje dat de ynterne spegel ophâldt mei antwurdzjen; as er noch hieltyd downloadt, rûtelelet der wat om de tunnel hinne of in ferâldere cache tsjinnet jo. Befêstigje dat it tasteane paad noch hieltyd TLS ferifiearret en noch hieltyd bewarplakhantekeningen kontrolearret, want in proxy dy’t ferkear ynspektearret is gjin reden om ien fan beide út te setten. Befêstigje ek dat in net-autentisearre klient in dúdlike wegering krijt ynstee fan in stille timeout.
Hâld it wurkjende fragmint en de misgjende útfier byinoar yn it feroaringsrekord. De folgjende persoan dy’t itselde hingjen treft, sil it ferskil fan twa rigels flugger werkenne as hokker ferklearring ek.