As respostas antigas sobre «APT a través de SOCKS» adoitan recomendar un envoltorio ou un relé HTTP-a-SOCKS. Esas respostas poden describir limitacións reais de versións antigas. Non son a única opción nunha versión de APT que documenta compatibilidade con socks5h.

Un fragmento de configuración pode usar as claves de transporte de adquisición existentes:

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

Este exemplo supón que xa existe un receptor SOCKS5 autorizado na mesma máquina. Non inicia ningún. Un reenvío dinámico SSH é unha forma de crear ese receptor local. Se o proxy é remoto, use no seu lugar o seu punto final realmente accesible; os candidatos da lista de proxies SOCKS5 só se aplican onde se permiten proxies públicos para as solicitudes ao repositorio.

O esquema forma parte da instrución

O manual de transporte de APT enumera socks5h para SOCKS5 con resolución DNS remota. Use o esquema documentado para a versión instalada en lugar de acurtalo a unha etiqueta que outro programa acepte por casualidade.

Así mesmo, Acquire::socks::Proxy nun fragmento antigo dun foro non é proba de que o método de adquisición HTTP lea esa opción. Un analizador de configuración pode aceptar unha clave sen que un método de descarga a use.

O enderezo local ten un límite

Cando APT se executa dentro dun contedor ou máquina virtual, 127.0.0.1 refírese a ese entorno. Un receptor SOCKS no host é outro punto final. Comprobe onde se executa APT antes de diagnosticar unha conexión local rexeitada.

A compatibilidade con SOCKS tampouco elimina as comprobacións de sinatura do repositorio nin do certificado HTTPS. Manteña esas proteccións activadas. Se o APT instalado carece da capacidade documentada, escolla unha alternativa aprobada ou unha ruta de actualización en lugar de tratar un esquema de URI non recoñecido como un problema de contrasinal.

Artigos relacionados