Svetainės įkeliamos per VPN, bet apt nepasiekia saugyklos
Naršyklė, kuri veikia per VPN, nieko nesako apie apt tarpinio serverio nustatymus. Perskaitykite nepavykusį etapą, išspausdinkite galiojančią konfigūraciją ir tada nustatykite tarpinį serverį, kurį apt skaito.
VPN prisijungia, vidinė viki įkeliama naršyklėje, o apt update vis dar kabo veidrodyje, kurio negali pasiekti. Tame vaizde tunelyje niekas nesugedę. Naršyklė ir paketų tvarkyklė priėmė du atskirus tarpinio serverio sprendimus, ir tik vienas iš jų buvo sukonfigūruotas.
Kuris sprendimas nepavyko, yra vienintelis dalykas, kurį verta nustatyti pirmiausia.
Perskaitykite klaidą prieš liesdami nustatymą
Kiekvienas etapas palieka skirtingą pranešimą. Vardas, kuris niekada neišsprendžiamas, yra DNS; ryšys, kuris niekada nebaigiamas, yra maršrutizavimas arba ugniasienė; momentinis 407 yra tarpinio serverio autentifikavimas; skundas dėl sertifikato yra TLS patikra; o įspėjimas dėl parašo yra saugyklos metaduomenys. Šie penki gedimai reikalauja penkių skirtingų taisymų, o eilutė su tarpiniu serveriu, užklijuota ant DNS problemos, tik perkelia strigimą.
Nukopijuokite tikslią eilutę ir saugyklą, kurią ji įvardija, prieš ką nors keisdami. Miglotas prisiminimas „baigėsi laikas“ yra tai, kas dešimties minučių diagnozę paverčia visu popiete.
APT turi savo tarpinio serverio nustatymus
APT skaito /etc/apt/apt.conf.d/, pagrindinį apt.conf ir bet kurį failą, kurį nurodo APT_CONFIG. Jis neskaito darbalaukio tarpinio serverio profilio, GNOME tinklo nustatymo ar naršyklės plėtinio. Transportas vis dėlto atsižvelgia į tarpinio serverio aplinkos kintamuosius, todėl jūsų apvalkale veikiantis export https_proxy=... nieko neįrodo apie laikmatį, kuris vykdomas kitoje aplinkoje.
Išspausdinkite, ką nepavykusiame procese iš tikrųjų matoma: apt-config dump | grep -i proxy.
Vykdykite tai kaip naudotojas, kuriuo vykdoma nepavykusi operacija. Jei root skaito kitą failų rinkinį arba systemd laikmatis paleidžiamas kitoje aplinkoje, išvestis skirsis, ir tas skirtumas yra jūsų atsakymas. Dvi prieštaringos tarpinio serverio reikšmės yra blogiau nei viena trūkstama, nes transportas vadovaujasi tiksliausiu atitikmeniu, kurį randa.
Nustatykite tarpinį serverį ten, kur jo tikisi konfigūracijos savininkas
Administratorių patvirtintam aiškiam tarpiniam serveriui pakanka nedidelio fragmento naujame faile:
Acquire::http::Proxy "http://proxy.corp.example:3128/";
Acquire::https::Proxy "http://proxy.corp.example:3128/";
Acquire::http::Proxy::archive.example.internal "DIRECT";Trečioji eilutė yra ta dalis, kurią dauguma pavyzdžių praleidžia. Raktažodis pagal prieglobos kompiuterį viršija bendrą reikšmę, todėl vidinis veidrodis, pasiekiamas per tunelį, gali apeiti tarpinį serverį, o visa kita vis dar eina per jį. DIRECT yra dokumentuota reikšmė tam, o ne tuščia eilutė.
Pridėkite fragmentą kaip naują sunumeruotą failą, pavyzdžiui /etc/apt/apt.conf.d/95proxy. Distribucijos failo perrašymas reiškia, kad kitas paketų atnaujinimas tyliai atšauks jūsų pakeitimą.
Prisijungimo duomenys lieka už URI ribų
APT transporto nuoroda autentifikavimui nurodo apt_auth.conf, ir būtent ten priklauso naudotojo vardas ir slaptažodis. Įterpus juos į tarpinio serverio URI, jie atsiranda procesų sąrašuose, apvalkalo istorijoje ir kiekvienoje konfigūracijos išvestyje, įklijuotoje į bilietą. Autentifikavimo failui reikia griežtų teisių, nes tai prisijungimo duomenų saugykla.
Patikrinkite ir schemą. HTTPS saugyklą vis dar galima pasiekti per HTTP tarpinį serverį; transportas yra atskiras pasirinkimas nuo veidrodžio URI schemos.
Grafinis programinės įrangos centras yra atskira sąsaja. Jei jis naudoja PackageKit arba snap foninę programą, APT fragmentas jam nieko nekeičia, todėl patikrinkite, kuris procesas atliko nepavykusią užklausą.
Patvirtinkite kelią, ne tik išėjimo kodą
Kai fragmentas yra vietoje, stebėkite užklausą, o ne pasitikėkite žaliu rezultatu. apt-get -o Debug::Acquire::http=true update išspausdina prisijungimo bandymą, pasirinktą tarpinį serverį ir atsakymo kodą, o tai atskiria neteisingą tarpinį serverį nuo tarpinio serverio, kuris jums atsisakė.
Tada išbandykite atvejį, kuris neturėtų veikti. Atjunkite VPN ir patvirtinkite, kad vidinis veidrodis nustoja atsakinėti; jei jis vis dar atsisiunčia, kažkas maršrutizuoja aplink tunelį arba jus aptarnauja pasenusi talpykla. Patvirtinkite, kad leidžiamas kelias vis dar tikrina TLS ir vis dar tikrina saugyklos parašus, nes tarpinis serveris, kuris tikrina srautą, nėra priežastis išjungti vieną ar kitą. Taip pat patvirtinkite, kad neautentifikuotas klientas gauna aiškų atmetimą, o ne tylų laiko limitą.
Laikykite veikiantį fragmentą ir nepavykusią išvestį kartu pakeitimų žurnale. Kitas žmogus, susidūręs su tuo pačiu strigimu, dviejų eilučių skirtumą atpažins greičiau nei iš bet kurio paaiškinimo.