Faqet hapen përmes VPN, por apt nuk arrin te depoja

VPN lidhet, wiki i brendshëm hapet në shfletues, dhe apt update vazhdon të rrijë varur në një pasqyrë që nuk arrin ta prekë. Në atë pamje asgjë në tunel nuk është prishur. Shfletuesi dhe menaxheri i paketave morën dy vendime të ndara për proxy, dhe vetëm njëri prej tyre ishte konfiguruar.

Cili vendim dështoi është e vetmja gjë që vlen të përcaktohet fillimisht.

Lexoni gabimin përpara se të prekni një cilësim

Secila fazë lë një mesazh tjetër. Një emër që nuk zgjidhet kurrë është DNS, një lidhje që nuk përfundon kurrë është rrugëzim ose mur zjarri, një 407 i menjëhershëm është vërtetim i proxy-t, një ankesë për certifikatën është verifikim TLS, dhe një paralajmërim për nënshkrimin është metadata e depos. Këto pesë dështime kërkojnë pesë rregullime të ndryshme, dhe një rresht proxy i ngjitur mbi një problem DNS vetëm e zhvendos ngecjen.

Kopjoni rreshtin e saktë dhe depon që ai emërton përpara se të ndryshoni gjithçka. Një kujtim i paqartë se „skadoi koha“ është ai që e kthen një diagnozë dhjetë minutash në një pasdite të tërë.

APT mban cilësimet e veta të proxy-t

APT lexon /etc/apt/apt.conf.d/, apt.conf kryesor dhe çdo skedar të emërtuar nga APT_CONFIG. Nuk lexon një profil proxy të desktopit, një cilësim rrjeti të GNOME ose një shtesë shfletuesi. Transporti në fakt respekton variablat e mjedisit për proxy, prandaj një export https_proxy=... që punon në shell-in tuaj nuk provon asgjë për një kohëmatës që xhiron në një mjedis tjetër.

Nxirrni atë që procesi që dështon sheh vërtet: apt-config dump | grep -i proxy.

Ekzekutoni atë si përdoruesi nën të cilin xhiron operacioni që dështon. Nëse root lexon një grup tjetër skedarësh, ose një kohëmatës systemd nis me një mjedis tjetër, nxjerrja do të ndryshojë, dhe ai ndryshim është përgjigjja juaj. Dy vlera proxy që kundërshtojnë njëra-tjetrën janë më keq se një vlerë që mungon, sepse transporti ndjek përputhjen më specifike që gjen.

Vendosni proxy-n aty ku pronari i konfigurimit e pret

Për një proxy të qartë të miratuar nga administratori, mjafton një fragment i vogël në një skedar të ri:

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

Rreshti i tretë është pjesa që shumica e shembujve e lënë jashtë. Një çelës për pritës anulon vlerën e përgjithshme, kështu që një pasqyrë e brendshme e arritshme përmes tunelit mund ta kapërcejë proxy-n ndërsa gjithçka tjetër vazhdon të kalojë përmes tij. DIRECT është vlera e dokumentuar për këtë, jo një varg bosh.

Shtojeni fragmentin si skedar të ri të numëruar, për shembull /etc/apt/apt.conf.d/95proxy. Të mbishkruash një skedar të shpërndarjes do të thotë që përditësimi i ardhshëm i paketave do ta kthejë ndryshimin tuaj në heshtje.

Kredencialet qëndrojnë jashtë URI-së

Referenca e transportit të APT për vërtetimin tregon apt_auth.conf, dhe aty përkasin emri i përdoruesit dhe fjalëkalimi. T'i futësh në URI-në e proxy-t i vendos në listat e proceseve, në historikun e shell-it dhe në çdo nxjerrje konfigurimi të ngjitur në një tiketë. Skedari i vërtetimit kërkon leje të rrepta, sepse është një depo kredencialesh.

Kontrolloni edhe skemën. Një depo HTTPS mund të arrihet ende përmes një proxy HTTP; transporti është një zgjedhje e ndarë nga skema e URI-së së pasqyrës.

Një qendër grafike softuerike është një front i ndarë. Nëse përdor PackageKit ose një backend snap, fragmenti i APT nuk ndryshon asgjë për të, prandaj verifikoni cili proces e bëri kërkesën që dështoi.

Verifikoni rrugën, jo vetëm kodin e daljes

Me fragmentin në vend, vëzhgoni kërkesën në vend që t'i besoni një rezultati të gjelbër. apt-get -o Debug::Acquire::http=true update shtyp përpjekjen për lidhje, proxy-n që zgjodhi dhe kodin e përgjigjes, gjë që e ndan një proxy të gabuar nga një proxy që ju refuzoi.

Pastaj provoni rastin që nuk duhet të funksionojë. Shkëputni VPN dhe verifikoni që pasqyra e brendshme ndalon së përgjigjuri; nëse ende shkarkon, diçka po rrugëzon përreth tunelit ose një cache e vjetër po ju shërben. Verifikoni që rruga e lejuar ende verifikon TLS dhe ende kontrollon nënshkrimet e depos, sepse një proxy që inspekton trafikun nuk është arsye për të çaktivizuar asnjërën. Verifikoni gjithashtu që një klient i pavërtetuar merr një refuzim të qartë në vend të një skadimi të heshtur.

Mbajini së bashku fragmentin që funksionon dhe daljen që dështoi në regjistrin e ndryshimeve. Personi tjetër që ndeshet me të njëjtën ngecje do ta njohë diferencën e dy rreshtave më shpejt se çdo shpjegim.