APT може використовувати SOCKS5h без обгортки

Для версій APT із задокументованою підтримкою SOCKS5h URI проксі належить до налаштувань транспорту HTTP або HTTPS, а не до вигаданого розділу Acquire::socks.

Старі відповіді про «APT через SOCKS» часто радять обгортку або ретранслятор HTTP-to-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 проблемою пароля.

Схожі статті