Esixir un inicio de sesión nos servizos HTTP e SOCKS de 3proxy

Definir un usuario non é toda a configuración de inicio de sesión de 3proxy. O servizo tamén necesita un método de autenticación e unha regra de acceso que o empregue. A orde importa porque a configuración do servizo aplícase mentres se procesa o ficheiro.

Un exemplo só local para dous servizos é:

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

A referencia de configuración explica users, auth strong e os comandos de servizo. CL garda este contrasinal de exemplo en texto claro. Protexa o ficheiro e escolla unha forma admitida de almacenar credenciais axeitada para o despregamento.

O cliente necesita o intercambio de inicio de sesión correcto

O servizo HTTP espera autenticación de proxy HTTP. O servizo SOCKS necesita un cliente que admita a autenticación SOCKS5 con nome de usuario e contrasinal. Un cliente SOCKS4 non pode ofrecer ese intercambio só porque chegue ao mesmo porto de escoita.

A palabra strong é o nome dun modo de autenticación, non unha garantía de transporte cifrado. Protexa o treito do cliente ao proxy cando sexa necesario. HTTPS ata o destino e o cifrado ata o proxy seguen sendo decisións separadas.

As ligazóns loopback limitan este exemplo ao acceso local. Para clientes remotos, escolla explicitamente un listener e unha política de rede previstos. Un listener público comodín non substitúe a comprobación do comportamento de inicio de sesión.

Se un servizo pide credenciais e outro non, revise a configuración antes de cada comando de servizo, as regras despois de calquera flush e a caché de autenticación. Cambiar un contrasinal non pode reparar un servizo iniciado coa política incorrecta. Do mesmo xeito, cambiar a conta de sistema operativo do daemon non crea un usuario de proxy.