APT kan bruge SOCKS5h uden en indpakning

Ældre svar om “APT gennem SOCKS” anbefaler ofte en indpakning eller et HTTP-til-SOCKS-relæ. Disse svar kan beskrive reelle begrænsninger i gamle udgivelser. De er ikke den eneste mulighed på en APT-version, der dokumenterer understøttelse af socks5h.

Et konfigurationsuddrag kan bruge de eksisterende transportnøgler til hentning:

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

Dette eksempel forudsætter, at en autoriseret SOCKS5-lytter allerede findes på samme maskine. Det starter ikke en. En dynamisk SSH-videresendelse er én måde at oprette den lokale lytter på. Hvis proxyen er fjern, skal du i stedet bruge dens faktiske tilgængelige endepunkt; kandidater fra SOCKS5-proxylisten gælder kun, hvor offentlige proxyer er tilladte for anmodningerne til arkivet.

Skemaet er en del af instruktionen

APT-transporthåndbogen viser socks5h til SOCKS5 med fjern DNS-opløsning. Brug det dokumenterede skema til den installerede version i stedet for at forkorte det til en etiket, som et andet program tilfældigvis accepterer.

Ligeledes er Acquire::socks::Proxy i et gammelt forumuddrag ikke bevis for, at HTTP-hentningsmetoden læser den indstilling. En konfigurationsparser kan acceptere en nøgle, uden at en downloadmetode bruger den.

Den lokale adresse har en grænse

Når APT kører i en container eller virtuel maskine, henviser 127.0.0.1 til det miljø. En SOCKS-lytter på værten er et andet endepunkt. Kontroller, hvor APT kører, før du diagnosticerer en afvist lokal forbindelse.

SOCKS-understøttelse fjerner heller ikke kontrol af arkivsignatur eller HTTPS-certifikat. Hold disse beskyttelser aktiveret. Hvis den installerede APT mangler den dokumenterede funktion, skal du vælge et godkendt alternativ eller en opdateringsvej i stedet for at behandle et ukendt URI-skema som et adgangskodeproblem.