Richiedere l'accesso su entrambi i servizi HTTP e SOCKS di 3proxy

Definire un utente non è l'intera configurazione di accesso di 3proxy. Il servizio necessita anche di un metodo di autenticazione e di una regola di accesso che lo usi. L'ordine conta perché le impostazioni del servizio si applicano durante l'elaborazione della configurazione.

Un esempio solo locale per due servizi:

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

Il riferimento di configurazione spiega users, auth strong e i comandi del servizio. CL memorizza questa password di esempio in chiaro. Proteggi il file e scegli una forma supportata di archiviazione delle credenziali adatta alla distribuzione.

Il client necessita del giusto scambio di accesso

Il servizio HTTP si aspetta l'autenticazione proxy HTTP. Il servizio SOCKS necessita di un client che supporti l'autenticazione SOCKS5 con nome utente e password. Un client SOCKS4 non può fornire quello scambio solo perché raggiunge la stessa porta di ascolto.

La parola strong è il nome di una modalità di autenticazione, non una garanzia di trasporto cifrato. Proteggi il tratto dal client al proxy quando serve. HTTPS verso la destinazione e cifratura verso il proxy restano decisioni separate.

I binding loopback limitano questo esempio all'accesso locale. Per i client remoti, scegli esplicitamente un listener e una politica di rete previsti. Un listener pubblico con wildcard non sostituisce il controllo del comportamento di accesso.

Se un servizio chiede le credenziali e un altro no, esamina le impostazioni prima di ogni comando di servizio, le regole dopo ogni flush e la cache di autenticazione. Cambiare una password non può riparare un servizio avviato con la politica sbagliata. Allo stesso modo, cambiare l'account di sistema operativo del demone non crea un utente proxy.