Krev innlogging på både 3proxy HTTP- og SOCKS-tjenestene

Å definere en bruker er ikke hele innloggingskonfigurasjonen for 3proxy. Tjenesten trenger også en autentiseringsmetode og en tilgangsregel som bruker den. Rekkefølgen betyr noe fordi tjenesteinnstillingene gjelder mens konfigurasjonen behandles.

Et kun lokalt eksempel for to tjenester:

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

Konfigurasjonsreferansen forklarer users, auth strong og tjenestekommandoene. CL lagrer dette eksempelpassordet som klartekst. Beskytt filen og velg en støttet form for lagring av legitimasjon som passer for utrullingen.

Klienten trenger riktig innloggingsutveksling

HTTP-tjenesten forventer HTTP-proxyautentisering. SOCKS-tjenesten trenger en klient som støtter SOCKS5-brukernavn- og passordautentisering. En SOCKS4-klient kan ikke tilby den utvekslingen bare fordi den når samme lyttende port.

Ordet strong er navnet på en autentiseringsmodus, ikke en garanti for kryptert transport. Beskytt strekningen fra klient til proxy når det er nødvendig. HTTPS til målet og kryptering til proxyen er fortsatt separate beslutninger.

Loopback-bindinger begrenser dette eksempelet til lokal tilgang. For eksterne klienter må du eksplisitt velge en tiltenkt lytter og nettverkspolicy. En offentlig jokertegn-lytter er ikke en erstatning for å kontrollere innloggingsatferd.

Hvis én tjeneste ber om legitimasjon og en annen ikke, undersøk innstillingene før hver tjenestekommando, reglene etter enhver flush og autentiseringsbufferen. Å endre et passord kan ikke reparere en tjeneste som ble startet under feil policy. På samme måte oppretter ikke et bytte av dæmonens operativsystemkonto en proxybruker.