Een aanmelding vereisen bij zowel de HTTP- als de SOCKS-service van 3proxy

Een gebruiker definiëren is niet de hele aanmeldconfiguratie van 3proxy. De service heeft ook een authenticatiemethode en een toegangsregel die die methode gebruikt nodig. De volgorde is belangrijk, omdat service-instellingen gelden terwijl de configuratie wordt verwerkt.

Een alleen lokaal voorbeeld voor twee services:

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

De configuratiereferentie legt users, auth strong en de serviceopdrachten uit. CL bewaart dit voorbeeldwachtwoord als platte tekst. Bescherm het bestand en kies een ondersteunde vorm voor het opslaan van inloggegevens die bij de uitrol past.

De client heeft de juiste aanmeldingsuitwisseling nodig

De HTTP-service verwacht HTTP-proxyauthenticatie. De SOCKS-service heeft een client nodig die SOCKS5-authenticatie met gebruikersnaam en wachtwoord ondersteunt. Een SOCKS4-client kan die uitwisseling niet bieden alleen omdat hij dezelfde luisterpoort bereikt.

Het woord strong is de naam van een authenticatiemodus, geen garantie voor versleuteld transport. Bescherm het traject van client naar proxy wanneer dat nodig is. HTTPS naar de bestemming en versleuteling naar de proxy blijven afzonderlijke beslissingen.

Loopback-bindingen beperken dit voorbeeld tot lokale toegang. Kies voor externe clients uitdrukkelijk een bedoelde listener en netwerkbeleid. Een openbare wildcard-listener is geen vervanging voor het controleren van aanmeldgedrag.

Als de ene service om inloggegevens vraagt en de andere niet, onderzoek dan de instellingen vóór elke serviceopdracht, de regels na elke flush en de authenticatiecache. Een wachtwoord wijzigen kan een service die onder het verkeerde beleid is gestart niet repareren. Evenzo maakt het wijzigen van het besturingssysteemaccount van de daemon geen proxygebruiker aan.