Exigir un inici de sessió tant al servei HTTP com al SOCKS de 3proxy
Configura usuaris de 3proxy, autenticació forta i regles d'accés als serveis per a clients HTTP i SOCKS5.
Definir un usuari no és tota la configuració d'inici de sessió de 3proxy. El servei també necessita un mètode d'autenticació i una regla d'accés que el faci servir. L'ordre importa perquè la configuració del servei s'aplica mentre es processa el fitxer.
Un exemple només local per a dos serveis és:
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 -p1080La referència de configuració explica users, auth strong i les ordres dels serveis. CL desa aquesta contrasenya d'exemple en text pla. Protegeix el fitxer i tria una forma admesa d'emmagatzematge de credencials adequada per al desplegament.
El client necessita l'intercanvi d'inici de sessió correcte
El servei HTTP espera autenticació de proxy HTTP. El servei SOCKS necessita un client que admeti l'autenticació SOCKS5 amb nom d'usuari i contrasenya. Un client SOCKS4 no pot oferir aquest intercanvi només perquè arriba al mateix port d'escolta.
La paraula strong és el nom d'un mode d'autenticació, no una garantia de transport xifrat. Protegeix el tram del client al proxy quan calgui. HTTPS fins a la destinació i el xifratge fins al proxy continuen sent decisions separades.
Els enllaços de loopback limiten aquest exemple a l'accés local. Per a clients remots, tria explícitament un listener i una política de xarxa previstos. Un listener públic comodí no substitueix la comprovació del comportament d'inici de sessió.
Si un servei demana credencials i un altre no, revisa la configuració abans de cada ordre de servei, les regles després de qualsevol flush i la memòria cau d'autenticació. Canviar una contrasenya no pot reparar un servei iniciat amb la política equivocada. Igualment, canviar el compte de sistema operatiu del dimoni no crea cap usuari de proxy.