Dai kuingia kwenye huduma zote mbili za HTTP na SOCKS za 3proxy

Sanidi watumiaji wa 3proxy, uthibitishaji madhubuti na kanuni za ufikiaji wa huduma kwa wateja wa HTTP na SOCKS5.

Kufafanua mtumiaji si usanidi mzima wa kuingia wa 3proxy. Huduma pia inahitaji njia ya uthibitishaji na kanuni ya ufikiaji inayoitumia. Mpangilio ni muhimu kwa sababu mipangilio ya huduma hutumika wakati usanidi unachakatwa.

Mfano wa ndani pekee kwa huduma mbili:

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

Marejeleo ya usanidi yanafafanua users, auth strong na amri za huduma. CL huhifadhi nenosiri la mfano huu kama maandishi wazi. Linda faili na uchague aina inayotumika ya kuhifadhi vitambulisho inayofaa uenezaji.

Mteja anahitaji ubadilishanaji sahihi wa kuingia

Huduma ya HTTP inatarajia uthibitishaji wa proksi ya HTTP. Huduma ya SOCKS inahitaji mteja anayetumia uthibitishaji wa SOCKS5 wa jina la mtumiaji na nenosiri. Mteja wa SOCKS4 hawezi kutoa ubadilishanaji huo kwa sababu tu anafikia bandari ile ile ya kusikiliza.

Neno strong ni jina la hali ya uthibitishaji, si uhakikisho wa usafirishaji uliosimbwa. Linda sehemu kutoka kwa mteja hadi proksi inapohitajika. HTTPS kuelekea lengwa na usimbaji kuelekea proksi hubaki kuwa maamuzi tofauti.

Miunganisho ya loopback hupunguza mfano huu kwa ufikiaji wa ndani. Kwa wateja wa mbali, chagua kwa uwazi msikilizaji na sera ya mtandao inayokusudiwa. Msikilizaji wa umma wa wildcard si mbadala wa kukagua tabia ya kuingia.

Ikiwa huduma moja inaomba vitambulisho na nyingine haombi, chunguza mipangilio kabla ya kila amri ya huduma, kanuni baada ya flush yoyote na akiba ya uthibitishaji. Kubadilisha nenosiri hakuwezi kurekebisha huduma iliyoanzishwa chini ya sera isiyo sahihi. Vivyo hivyo, kubadilisha akaunti ya mfumo wa uendeshaji wa daemon hakuundi mtumiaji wa proksi.

Makala zinazohusiana