Требовать вход в обеих службах 3proxy — HTTP и SOCKS

Настройте пользователей 3proxy, строгую аутентификацию и правила доступа к службам для клиентов HTTP и SOCKS5.

Определение пользователя — это не вся конфигурация входа в 3proxy. Службе также нужны метод аутентификации и правило доступа, которое его использует. Порядок важен, потому что параметры службы применяются при обработке конфигурации.

Пример только для локального доступа с двумя службами:

users alex:CL:replace_with_a_private_password
auth strong
allow alex
proxy -i127.0.0.1 -p3128
flush
allow alex
socks -i127.0.0.1 -p1080

Справочник по конфигурации объясняет users, auth strong и команды служб. CL хранит этот пример пароля как обычный текст. Защитите файл и выберите поддерживаемый способ хранения учётных данных, подходящий для развёртывания.

Клиенту нужен правильный обмен при входе

Служба HTTP ожидает аутентификацию HTTP-прокси. Службе SOCKS нужен клиент, поддерживающий аутентификацию SOCKS5 по имени пользователя и паролю. Клиент SOCKS4 не может обеспечить такой обмен только потому, что достигает того же порта прослушивания.

Слово strong — это название режима аутентификации, а не гарантия шифрованного транспорта. При необходимости защищайте участок от клиента до прокси. HTTPS до назначения и шифрование до прокси остаются отдельными решениями.

Привязки loopback ограничивают этот пример локальным доступом. Для удалённых клиентов явно выберите предназначенный прослушиватель и сетевую политику. Публичный прослушиватель с подстановочным знаком не заменяет проверку поведения при входе.

Если одна служба запрашивает учётные данные, а другая нет, проверьте параметры перед каждой командой службы, правила после любого flush и кэш аутентификации. Смена пароля не исправит службу, запущенную при неверной политике. Точно так же смена учётной записи операционной системы демона не создаёт пользователя прокси.

Похожие статьи