Las respuestas antiguas sobre «APT a través de SOCKS» suelen recomendar un envoltorio o un relé HTTP-a-SOCKS. Esas respuestas pueden describir limitaciones reales de versiones antiguas. No son la única opción en una versión de APT que documenta compatibilidad con socks5h.

Un fragmento de configuración puede usar las 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 ejemplo supone que ya existe un receptor SOCKS5 autorizado en la misma máquina. No inicia ninguno. Un reenvío dinámico SSH es una forma de crear ese receptor local. Si el proxy es remoto, use en su lugar su punto final realmente accesible; los candidatos de la lista de proxies SOCKS5 solo se aplican donde se permiten proxies públicos para las solicitudes al repositorio.

El esquema forma parte de la instrucción

El manual de transporte de APT enumera socks5h para SOCKS5 con resolución DNS remota. Use el esquema documentado para la versión instalada en lugar de acortarlo a una etiqueta que otro programa acepte por casualidad.

Asimismo, Acquire::socks::Proxy en un fragmento antiguo de un foro no es prueba de que el método de adquisición HTTP lea esa opción. Un analizador de configuración puede aceptar una clave sin que un método de descarga la use.

La dirección local tiene un límite

Cuando APT se ejecuta dentro de un contenedor o una máquina virtual, 127.0.0.1 se refiere a ese entorno. Un receptor SOCKS en el host es otro punto final. Compruebe dónde se ejecuta APT antes de diagnosticar una conexión local rechazada.

La compatibilidad con SOCKS tampoco elimina las comprobaciones de firma del repositorio ni del certificado HTTPS. Mantenga esas protecciones activadas. Si el APT instalado carece de la capacidad documentada, elija una alternativa aprobada o una ruta de actualización en lugar de tratar un esquema de URI no reconocido como un problema de contraseña.

Artículos relacionados