По-стари отговори за „APT през SOCKS“ често препоръчват обвивка или релей HTTP към SOCKS. Тези отговори може да описват реални ограничения на стари версии. Те обаче не са единственият вариант при версия на APT, която документира поддръжка на socks5h.

Фрагмент от конфигурация може да използва съществуващите ключове за транспорт на получаване:

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

Този пример предполага, че на същата машина вече има оторизиран слушател на SOCKS5. Той не стартира такъв. Динамично пренасочване по SSH е един начин да създадете този локален слушател. Ако проксито е отдалечено, използвайте вместо това реалната му достижима крайна точка; кандидатите от списъка с SOCKS5 проксита важат само там, където публичните проксита са разрешени за заявките към хранилището.

Схемата е част от инструкцията

Ръководството за транспорт на APT изброява socks5h за SOCKS5 с отдалечено DNS разрешаване. Използвайте документираната схема за инсталираната версия, вместо да я съкращавате до етикет, който друга програма случайно приема.

По същия начин Acquire::socks::Proxy в стар фрагмент от форум не е доказателство, че методът за получаване HTTP чете тази настройка. Парсерът на конфигурация може да приеме ключ, без метод за изтегляне да го използва.

Локалният адрес има граница

Когато APT работи в контейнер или виртуална машина, 127.0.0.1 се отнася за тази среда. Слушател на SOCKS на хоста е различна крайна точка. Проверете къде се изпълнява APT, преди да диагностицирате отказана локална връзка.

Поддръжката на SOCKS също не премахва проверките на подписа на хранилището или на HTTPS сертификата. Оставете тези защити включени. Ако инсталираният APT няма документираната възможност, изберете одобрена алтернатива или път за обновяване, вместо да третирате неразпозната URI схема като проблем с парола.

Подобни статии