Vereis 'n aanmelding by beide 3proxy se HTTP- en SOCKS-dienste

Stel 3proxy-gebruikers, sterk verifikasie en diensreels vir HTTP- en SOCKS5-kliënte op.

Om 'n gebruiker te definieer is nie die hele aanmeldkonfigurasie van 3proxy nie. Die diens benodig ook 'n verifikasiemetode en 'n toegangsreël wat daarvan gebruik maak. Die volgorde maak saak, want diensinstellings geld terwyl die konfigurasie verwerk word.

'n Slegs-plaaslike voorbeeld vir twee dienste is:

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

Die konfigurasieverwysing verduidelik users, auth strong en die diensopdragte. CL stoor hierdie voorbeeldwagwoord as gewone teks. Beskerm die lêer en kies 'n ondersteunde vorm om geloofsbriewe te bewaar wat by die ontplooiing pas.

Die kliënt het die regte aanmeldruil nodig

Die HTTP-diens verwag HTTP-proxy-verifikasie. Die SOCKS-diens benodig 'n kliënt wat SOCKS5-gebruikersnaam-en-wagwoord-verifikasie ondersteun. 'n SOCKS4-kliënt kan nie daardie ruil lewer bloot omdat dit dieselfde luisterpoort bereik nie.

Die woord strong is 'n naam vir 'n verifikasiemodus, nie 'n waarborg van versleutelde vervoer nie. Beskerm die skakel van kliënt na proxy wanneer nodig. HTTPS na die bestemming en versleuteling na die proxy bly aparte besluite.

Loopback-bindings beperk hierdie voorbeeld tot plaaslike toegang. Kies vir afgeleë kliënte uitdruklik 'n bedoelde luisteraar en netwerkbeleid. 'n Openbare wildcard-luisteraar is nie 'n plaasvervanger vir die nagaan van aanmeldgedrag nie.

As een diens om geloofsbriewe vra en 'n ander nie, ondersoek die instellings voor elke diensopdrag, die reëls ná enige flush en die kas van verifikasie. 'n Wagwoord wat verander word, kan nie 'n diens herstel wat onder die verkeerde beleid begin is nie. Net so skep 'n verandering van die daemon se bedryfstelselrekening nie 'n proxy-gebruiker nie.

Verwante artikels