Изискване на вход за услугите HTTP и SOCKS на 3proxy

Конфигурирайте потребители на 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 и кеширането на автентикацията. Смяната на парола не може да поправи услуга, стартирана при грешна политика. По същия начин смяната на системния акаунт на демона не създава потребител на проксито.

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