I siti si caricano con la VPN, ma apt non raggiunge il repository

La VPN si connette, il wiki interno si carica nel browser e apt update resta bloccato su un mirror che non riesce a raggiungere. In quel quadro non c’è nulla di rotto nel tunnel. Il browser e il gestore dei pacchetti hanno preso due decisioni proxy separate, e solo una delle due era configurata.

Quale decisione è fallita è l’unica cosa che vale la pena stabilire per prima.

Leggi l’errore prima di toccare un’impostazione

Ogni stadio lascia un messaggio diverso. Un nome che non si risolve mai è DNS, una connessione che non si completa mai è routing o un firewall, un 407 immediato è autenticazione del proxy, una lamentela sul certificato è verifica TLS e un avviso di firma sono i metadati del repository. Quei cinque guasti richiedono cinque correzioni diverse, e una riga di proxy incollata sopra un problema di DNS sposta solo il blocco.

Copia la riga esatta e il repository che nomina prima di cambiare qualsiasi cosa. Un ricordo vago di «è andato in timeout» è ciò che trasforma una diagnosi di dieci minuti in un pomeriggio intero.

APT tiene le proprie impostazioni proxy

APT legge /etc/apt/apt.conf.d/, il apt.conf principale e qualsiasi file indicato da APT_CONFIG. Non legge un profilo proxy del desktop, un’impostazione di rete di GNOME o un’estensione del browser. Il trasporto invece rispetta le variabili d’ambiente del proxy, ed è per questo che un export https_proxy=... funzionante nella tua shell non dimostra nulla su un timer che gira in un altro ambiente.

Scarica ciò che il processo in errore vede davvero: apt-config dump | grep -i proxy.

Esegui il comando come l’utente con cui gira l’operazione fallita. Se root legge un insieme di file diverso, o un timer systemd parte con un altro ambiente, lo scarico sarà diverso, e quella differenza è la tua risposta. Due valori proxy che non concordano sono peggio di un valore mancante, perché il trasporto segue la corrispondenza più specifica che trova.

Imposta il proxy dove il proprietario della configurazione se lo aspetta

Per un proxy esplicito approvato dall’amministratore basta un piccolo frammento in un nuovo file:

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

La terza riga è la parte che quasi tutti gli esempi omettono. Una chiave per host ha la precedenza sul valore generico, così un mirror interno raggiungibile dal tunnel può saltare il proxy mentre tutto il resto ci passa ancora. DIRECT è il valore documentato per questo, non una stringa vuota.

Aggiungi il frammento come nuovo file numerato, ad esempio /etc/apt/apt.conf.d/95proxy. Sovrascrivere un file della distribuzione significa che il prossimo aggiornamento dei pacchetti annullerà la modifica in silenzio.

Le credenziali restano fuori dall’URI

La documentazione del trasporto APT rimanda a apt_auth.conf per l’autenticazione, ed è lì che vanno nome utente e password. Incorporarli nell’URI del proxy li mette negli elenchi dei processi, nella cronologia della shell e in ogni scarico di configurazione incollato in un ticket. Il file di autenticazione richiede permessi restrittivi, perché è un archivio di credenziali.

Controlla anche lo schema. Un repository HTTPS può comunque essere raggiunto attraverso un proxy HTTP; il trasporto è una scelta distinta da quella dello schema URI del mirror.

Un centro software grafico è un front end separato. Se usa PackageKit o un backend snap, il frammento APT non cambia nulla per lui, quindi verifica quale processo ha fatto la richiesta fallita.

Verifica il percorso, non solo il codice di uscita

Con il frammento in posizione, osserva la richiesta invece di fidarti di un risultato verde. apt-get -o Debug::Acquire::http=true update stampa il tentativo di connessione, il proxy scelto e il codice di risposta, il che distingue un proxy sbagliato da un proxy che ti ha rifiutato.

Poi prova il caso che non dovrebbe funzionare. Disconnetti la VPN e verifica che il mirror interno smetta di rispondere; se scarica ancora, qualcosa sta aggirando il tunnel o una cache obsoleta ti sta servendo. Verifica che il percorso consentito validi ancora TLS e controlli ancora le firme del repository, perché un proxy che ispeziona il traffico non è un motivo per disattivare l’una o le altre. Verifica anche che un client non autenticato riceva un rifiuto chiaro invece di un timeout silenzioso.

Tieni insieme il frammento funzionante e l’output fallito nel registro delle modifiche. La prossima persona che incontra lo stesso blocco riconoscerà più in fretta la differenza di due righe di qualsiasi spiegazione.