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

Konfigurer 3proxy-brukarar, sterk autentisering og tilgangsreglar for tenester for HTTP- og SOCKS5-klientar.

Å definere ein brukar er ikkje heile innloggingskonfigurasjonen for 3proxy. Tenesta treng òg ein autentiseringsmetode og ein tilgangsregel som brukar han. Rekkjefølgja har noko å seie fordi tenesteinnstillingane gjeld medan konfigurasjonen blir handsama.

Eit berre lokalt døme for to tenester:

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 tenestekommandoane. CL lagrar dette dømetpassordet som klartekst. Ver vern om fila og vel ei støtta form for lagring av legitimasjon som passar for utrullinga.

Klienten treng rett innloggingsutveksling

HTTP-tenesta ventar HTTP-proxyautentisering. SOCKS-tenesta treng ein klient som støttar SOCKS5-brukarnamn- og passordautentisering. Ein SOCKS4-klient kan ikkje tilby den utvekslinga berre fordi han når same lyttande port.

Ordet strong er namnet på ein autentiseringsmodus, ikkje ei garanti for kryptert transport. Vern om strekninga frå klient til proxy når det trengst. HTTPS til målet og kryptering til proxyen er framleis separate avgjerder.

Loopback-bindingar avgrensar dette dømet til lokal tilgang. For eksterne klientar må du eksplisitt velje ein tiltenkt lyttar og nettverkspolicy. Ein offentleg jokerteikn-lyttar er ikkje ei erstatning for å kontrollere innloggingsåtferd.

Viss éi teneste ber om legitimasjon og ei anna ikkje, undersøk innstillingane før kvar tenestekommando, reglane etter kvar flush og autentiseringsbufferen. Å endre eit passord kan ikkje reparere ei teneste som vart starta under feil policy. På same måte skapar ikkje eit byte av operativsystemkontoen til daemonen ein proxybrukar.

Relaterte artiklar