Els llocs web carreguen amb la VPN, però apt no arriba al repositori

La VPN es connecta, el wiki intern es carrega al navegador i apt update continua penjat en un mirall al qual no pot arribar. En aquesta imatge no hi ha res trencat al túnel. El navegador i el gestor de paquets van prendre dues decisions de proxy separades, i només una d’elles estava configurada.

Quina decisió va fallar és l’única cosa que val la pena establir primer.

Llegeixi l’error abans de tocar cap paràmetre

Cada etapa deixa un missatge diferent. Un nom que no es resol mai és DNS, una connexió que no es completa mai és encaminament o un tallafoc, un 407 immediat és autenticació del proxy, una queixa sobre el certificat és verificació TLS i un avís de signatura són les metadades del repositori. Aquestes cinc fallades necessiten cinc correccions diferents, i una línia de proxy enganxada damunt d’un problema de DNS només mou el bloqueig.

Copiï la línia exacta i el repositori que anomena abans de canviar res. Un record vague de «s’ha esgotat el temps» és el que converteix un diagnòstic de deu minuts en una tarda sencera.

APT guarda els seus propis paràmetres de proxy

APT llegeix /etc/apt/apt.conf.d/, el apt.conf principal i qualsevol fitxer indicat per APT_CONFIG. No llegeix un perfil de proxy de l’escriptori, un paràmetre de xarxa del GNOME ni una extensió del navegador. El transport sí que respecta les variables d’entorn de proxy, i per això un export https_proxy=... que funciona a la seva shell no demostra res sobre un temporitzador que s’executa en un altre entorn.

Aboqui el que el procés que falla veu realment: apt-config dump | grep -i proxy.

Executi-ho com l’usuari amb què corre l’operació que falla. Si root llegeix un conjunt de fitxers diferent, o un temporitzador de systemd arrenca amb un altre entorn, l’abocament serà diferent, i aquesta diferència és la seva resposta. Dos valors de proxy que no coincideixen són pitjors que un valor absent, perquè el transport segueix la coincidència més específica que troba.

Defineixi el proxy on el propietari de la configuració l’espera

Per a un proxy explícit aprovat per l’administrador, n’hi ha prou amb un fragment petit en un fitxer nou:

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

La tercera línia és la part que la majoria d’exemples ometen. Una clau per host anul·la el valor genèric, així que un mirall intern abastable pel túnel pot saltar-se el proxy mentre tota la resta hi continua passant. DIRECT és el valor documentat per a això, no una cadena buida.

Afegiu el fragment com a fitxer nou numerat, per exemple /etc/apt/apt.conf.d/95proxy. Sobreescriure un fitxer de la distribució vol dir que la propera actualització de paquets revertirà el seu canvi en silenci.

Les credencials queden fora de l’URI

La referència del transport APT apunta a apt_auth.conf per a l’autenticació, i és aquí on van el nom d’usuari i la contrasenya. Incrustar-los a l’URI del proxy els posa a les llistes de processos, a l’historial de la shell i a cada abocament de configuració enganxat en un tiquet. El fitxer d’autenticació necessita permisos restrictius, perquè és un magatzem de credencials.

Comprovi també l’esquema. Un repositori HTTPS encara es pot assolir a través d’un proxy HTTP; el transport és una tria separada de la de l’esquema de l’URI del mirall.

Un centre de programari gràfic és una interfície a part. Si fa servir PackageKit o un backend snap, el fragment d’APT no hi canvia res, així que confirmi quin procés va fer la petició fallida.

Confirmi el camí, no només el codi de sortida

Amb el fragment al lloc, observi la petició en lloc de refiar-se d’un resultat verd. apt-get -o Debug::Acquire::http=true update imprimeix l’intent de connexió, el proxy triat i el codi de resposta, cosa que separa un proxy equivocat d’un proxy que l’ha refusat.

Després provi el cas que no hauria de funcionar. Desconnecti la VPN i confirmi que el mirall intern deixa de respondre; si encara baixa, alguna cosa està encaminant per fora del túnel o una memòria cau vella li està servint. Confirmi que el camí permès encara valida TLS i encara comprova les signatures del repositori, perquè un proxy que inspecciona el trànsit no és cap motiu per desactivar cap de les dues. Confirmi també que un client no autenticat rep una denegació clara en lloc d’un temps d’espera silenciós.

Mantingui junts el fragment que funciona i la sortida que falla al registre de canvis. La propera persona que topi amb el mateix bloqueig reconeixerà la diferència de dues línies més de pressa que amb qualsevol explicació.