Postuli ensaluton en ambaŭ 3proxy-servoj HTTP kaj SOCKS
Agordu 3proxy-uzantojn, fortan aŭtentikigon kaj servajn alirregulojn por HTTP- kaj SOCKS5-klientoj.
Difini uzanton ne estas la tuta ensaluta agordo de 3proxy. La servo ankaŭ bezonas aŭtentikigan metodon kaj alirregulon, kiu uzas ĝin. La ordo gravas, ĉar servaj agordoj aplikiĝas dum la agordo estas prilaborata.
Nur-loka ekzemplo por du servoj estas:
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 -p1080La agorda referenco klarigas users, auth strong kaj la servajn komandojn. CL konservas ĉi tiun ekzemplan pasvorton kiel puran tekston. Protektu la dosieron kaj elektu subtenatan formon de konservado de akreditaĵoj taŭgan por la disfaldiĝo.
La kliento bezonas la ĝustan ensalutan interŝanĝon
La servo HTTP atendas HTTP-prokuran aŭtentikigon. La servo SOCKS bezonas klienton subtenantan SOCKS5-uzantnoman kaj pasvortan aŭtentikigon. Kliento SOCKS4 ne povas havigi tiun interŝanĝon nur ĉar ĝi atingas la saman aŭskultan pordon.
La vorto strong estas nomo de aŭtentikiga reĝimo, ne garantio de ĉifrita transporto. Protektu la vojon de la kliento al la prokuro kiam necese. HTTPS al la celo kaj ĉifrado al la prokuro restas apartaj decidoj.
Loopback-ligoj limigas ĉi tiun ekzemplon al loka alirado. Por malproksimaj klientoj, eksplicite elektu intenditan aŭskultanton kaj retan politikon. Publika ĵokera aŭskultanto ne anstataŭas kontroladon de ensaluta konduto.
Se unu servo petas akreditaĵojn kaj alia ne, kontrolu la agordojn antaŭ ĉiu serva komando, la regulojn post ajna flush kaj la aŭtentikigan kaŝmemoron. Ŝanĝo de pasvorto ne povas ripari servon startigitan sub la malĝusta politiko. Same, ŝanĝo de la operaciuma konto de la demono ne kreas prokuran uzanton.