Exigir início de sessão nos serviços HTTP e SOCKS do 3proxy

Definir um utilizador não é toda a configuração de início de sessão do 3proxy. O serviço também precisa de um método de autenticação e de uma regra de acesso que o utilize. A ordem importa porque as definições do serviço são aplicadas enquanto a configuração é processada.

Um exemplo apenas local para dois serviços:

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 referência de configuração explica users, auth strong e os comandos do serviço. CL guarda esta palavra-passe de exemplo em texto simples. Proteja o ficheiro e escolha uma forma suportada de armazenar credenciais adequada à implementação.

O cliente precisa da troca de início de sessão correta

O serviço HTTP espera autenticação de proxy HTTP. O serviço SOCKS precisa de um cliente que suporte autenticação SOCKS5 com nome de utilizador e palavra-passe. Um cliente SOCKS4 não pode fornecer essa troca só porque alcança a mesma porta de escuta.

A palavra strong é o nome de um modo de autenticação, não uma garantia de transporte cifrado. Proteja o troço do cliente ao proxy quando necessário. HTTPS até ao destino e cifragem até ao proxy continuam a ser decisões separadas.

As ligações loopback limitam este exemplo ao acesso local. Para clientes remotos, escolha explicitamente um listener e uma política de rede pretendidos. Um listener público com wildcard não substitui a verificação do comportamento de início de sessão.

Se um serviço pedir credenciais e outro não, examine as definições antes de cada comando de serviço, as regras após qualquer flush e a cache de autenticação. Mudar uma palavra-passe não pode reparar um serviço iniciado com a política errada. Do mesmo modo, mudar a conta de sistema operativo do daemon não cria um utilizador de proxy.