APT può usare SOCKS5h senza wrapper

Le vecchie risposte su «APT tramite SOCKS» consigliano spesso un wrapper o un relè HTTP-to-SOCKS. Tali risposte possono descrivere limiti reali delle versioni precedenti. Non sono però l'unica opzione su una versione di APT che documenta il supporto per socks5h.

Un frammento di configurazione può usare le chiavi di trasporto di acquisizione esistenti:

Acquire::http::Proxy "socks5h://127.0.0.1:1080/";
Acquire::https::Proxy "socks5h://127.0.0.1:1080/";

Questo esempio presuppone che sulla stessa macchina esista già un listener SOCKS5 autorizzato. Non ne avvia uno. Un inoltro dinamico SSH è un modo per creare quel listener locale. Se il proxy è remoto, usa invece il suo endpoint realmente raggiungibile; i candidati dalla lista di proxy SOCKS5 valgono solo dove i proxy pubblici sono consentiti per le richieste al repository.

Lo schema fa parte dell'istruzione

Il manuale del trasporto di APT elenca socks5h per SOCKS5 con risoluzione DNS remota. Usa lo schema documentato per la versione installata invece di abbreviarlo in un'etichetta che un altro programma accetta per caso.

Allo stesso modo, Acquire::socks::Proxy in un vecchio frammento di forum non è prova che il metodo di acquisizione HTTP legga quell'impostazione. Un parser di configurazione può accettare una chiave senza che un metodo di download la usi.

L'indirizzo locale ha un confine

Quando APT viene eseguito in un container o in una macchina virtuale, 127.0.0.1 si riferisce a quell'ambiente. Un listener SOCKS sull'host è un altro endpoint. Controlla dove viene eseguito APT prima di diagnosticare una connessione locale rifiutata.

Il supporto SOCKS non elimina nemmeno i controlli della firma del repository o del certificato HTTPS. Mantieni attive queste protezioni. Se l'APT installato non dispone della capacità documentata, scegli un'alternativa approvata o un percorso di aggiornamento invece di trattare uno schema URI non riconosciuto come un problema di password.