Вимагати вхід в обох службах 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 і кеш автентифікації. Зміна пароля не виправить службу, запущену за неправильної політики. Так само зміна облікового запису операційної системи демона не створює користувача проксі.

Схожі статті