Fereaskje oanmelding by beide 3proxy HTTP- en SOCKS-tsjinsten

Konfigurearje 3proxy-brûkers, sterke autentikaasje en tsjinsttagongsregels foar HTTP- en SOCKS5-klanten.

In brûker definiearje is net de hiele oanmeldkonfiguraasje fan 3proxy. De tsjinst hat ek in autentikaasjemetoade nedich en in tagongsregel dy't dy brûkt. De folchoarder is wichtich, want tsjinstynstellingen jilde wylst de konfiguraasje ferwurke wurdt.

In allinnich lokaal foarbyld foar twa tsjinsten:

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 konfiguraasjereferinsje ferklearret users, auth strong en de tsjinstopdrachten. CL bewarret dit foarbyldwachtwurd as gewoane tekst. Beskermje it bestân en kies in stipe foarm fan bewarjen fan oanmeldgegevens dy't by de útrol past.

De klant hat de juste oanmeldútwikseling nedich

De HTTP-tsjinst ferwachtet HTTP-proxy-autentikaasje. De SOCKS-tsjinst hat in klant nedich dy't SOCKS5-brûkersnamme en wachtwurd-autentikaasje stipet. In SOCKS4-klant kin dy útwikseling net leverje allinnich om't er deselde harkport berikt.

It wurd strong is in namme foar in autentikaasjemodus, gjin garânsje foar fersifere ferfier. Beskermje it stik fan klant nei proxy as dat nedich is. HTTPS nei de bestemming en fersifering nei de proxy bliuwe aparte besluten.

Loopback-biningen beheine dit foarbyld ta lokale tagong. Kies foar fiere klanten eksplisyt in bedoelde harker en netwurkbelied. In iepenbiere wildcard-harker is gjin ferfanging foar it kontrolearjen fan oanmeldgedrach.

As iene tsjinst om oanmeldgegevens freget en in oare net, ûndersykje dan de ynstellingen foar elke tsjinstopdracht, de regels nei elke flush en de autentikaasje-cache. In wachtwurd feroarje kin in tsjinst net reparearje dy't ûnder ferkeard belied start is. Likegoed makket it feroarjen fan it bestjoeringssysteemakkoart fan de daemon gjin proxy-brûker.

Relatearre artikelen