Exigir inicio de sesión en los servicios HTTP y SOCKS de 3proxy

Definir un usuario no es toda la configuración de inicio de sesión de 3proxy. El servicio también necesita un método de autenticación y una regla de acceso que lo utilice. El orden importa porque la configuración del servicio se aplica mientras se procesa el archivo.

Un ejemplo solo local para dos servicios es:

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

La referencia de configuración explica users, auth strong y los comandos de servicio. CL guarda esta contraseña de ejemplo en texto plano. Proteja el archivo y elija una forma admitida de almacenar credenciales adecuada para el despliegue.

El cliente necesita el intercambio de inicio de sesión correcto

El servicio HTTP espera autenticación de proxy HTTP. El servicio SOCKS necesita un cliente que admita la autenticación SOCKS5 con nombre de usuario y contraseña. Un cliente SOCKS4 no puede ofrecer ese intercambio solo porque llegue al mismo puerto de escucha.

La palabra strong es el nombre de un modo de autenticación, no una garantía de transporte cifrado. Proteja el tramo del cliente al proxy cuando sea necesario. HTTPS hasta el destino y el cifrado hasta el proxy siguen siendo decisiones separadas.

Los enlaces de loopback limitan este ejemplo al acceso local. Para clientes remotos, elija explícitamente un listener y una política de red previstos. Un listener público comodín no sustituye la comprobación del comportamiento de inicio de sesión.

Si un servicio pide credenciales y otro no, revise la configuración antes de cada comando de servicio, las reglas después de cualquier flush y la caché de autenticación. Cambiar una contraseña no puede reparar un servicio iniciado con la política equivocada. Del mismo modo, cambiar la cuenta de sistema operativo del demonio no crea un usuario de proxy.