Kræv login på både 3proxy HTTP- og SOCKS-tjenesterne

Konfigurer 3proxy-brugere, stærk godkendelse og adgangsregler for tjenester til HTTP- og SOCKS5-klienter.

At definere en bruger er ikke hele 3proxy-loginopsætningen. Tjenesten har også brug for en godkendelsesmetode og en adgangsregel, der bruger den. Rækkefølgen betyder noget, fordi tjenestens indstillinger anvendes, mens konfigurationen behandles.

Et kun lokalt eksempel til 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

Konfigurationsreferencen forklarer users, auth strong og tjenestekommandoerne. CL gemmer denne eksempeladgangskode som klartekst. Beskyt filen, og vælg en understøttet form for lagring af legitimationsoplysninger, der passer til udrulningen.

Klienten skal bruge den rigtige loginudveksling

HTTP-tjenesten forventer HTTP-proxygodkendelse. SOCKS-tjenesten kræver en klient, der understøtter SOCKS5-brugernavn- og adgangskodegodkendelse. En SOCKS4-klient kan ikke levere den udveksling, blot fordi den når den samme lytteport.

Ordet strong er navnet på en godkendelsestilstand, ikke en garanti for krypteret transport. Beskyt forbindelsen fra klient til proxy, når det er nødvendigt. HTTPS til destinationen og kryptering til proxyen er stadig separate beslutninger.

Loopback-bindinger begrænser dette eksempel til lokal adgang. For eksterne klienter skal du udtrykkeligt vælge en tilsigtet lytter og netværkspolitik. En offentlig wildcard-lytter er ikke en erstatning for at kontrollere loginadfærd.

Hvis én tjeneste beder om login og en anden ikke, skal du undersøge indstillingerne før hver tjenestekommando, reglerne efter en eventuel flush og godkendelsescachen. Et ændret password kan ikke reparere en tjeneste, der er startet under den forkerte politik. På samme måde opretter et skift af dæmonens operativsystemkonto ikke en proxybruger.

Relaterede artikler