Krefjast innskráningar á bæði 3proxy HTTP- og SOCKS-þjónusturnar

Stilltu 3proxy-notendur, sterka auðkenningu og aðgangsreglur þjónustu fyrir HTTP- og SOCKS5-biðlara.

Að skilgreina notanda er ekki öll innskráningaruppsetning 3proxy. Þjónustan þarf líka auðkenningaraðferð og aðgangsreglu sem notar hana. Röðin skiptir máli því stillingar þjónustunnar gilda meðan uppsetningin er unnin.

Dæmi aðeins fyrir staðbundinn aðgang með tveimur þjónustum:

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

Uppsetningarhandbókin útskýrir users, auth strong og skipanir þjónustunnar. CL geymir þetta dæmalykilorð sem hreinan texta. Verndaðu skrána og veldu studda geymsluform skírteina sem hentar uppsetningunni.

Biðlarinn þarf rétta innskráningarskiptið

HTTP-þjónustan væntir auðkenningar HTTP-milliþjóns. SOCKS-þjónustan þarf biðlara sem styður SOCKS5-auðkenningu með notandanafni og lykilorði. SOCKS4-biðlari getur ekki veitt þessi skipti bara af því að hann nær sömu hlustunargátt.

Orðið strong er heiti auðkenningarhams, ekki ábyrgð á dulrituðum flutningi. Verndaðu kaflann frá biðlara að milliþjóni þegar þörf krefur. HTTPS til áfangastaðar og dulkóðun til milliþjónsins eru áfram aðskildar ákvarðanir.

Loopback-tengingar takmarka þetta dæmi við staðbundinn aðgang. Fyrir fjarbiðlara skaltu velja ætlaðan hlustara og netstefnu skýrt. Opinber algildis-hlustari kemur ekki í staðinn fyrir að athuga innskráningarhegðun.

Ef ein þjónusta biður um skírteini og önnur ekki, skoðaðu stillingarnar fyrir hverja þjónustuskipun, reglurnar eftir hvert flush og auðkenningarskyndiminnið. Að breyta lykilorði getur ekki lagað þjónustu sem var ræst undir rangri stefnu. Á sama hátt skapar breyting á stýrikerfisreikningi daemonsins ekki milliþjónsnotanda.

Tengdir greinar