Reikalauti prisijungimo abiejose 3proxy HTTP ir SOCKS paslaugose

Sukonfigūruokite 3proxy naudotojus, stiprų autentifikavimą ir paslaugų prieigos taisykles HTTP ir SOCKS5 klientams.

Naudotojo apibrėžimas nėra visa 3proxy prisijungimo konfigūracija. Paslaugai taip pat reikia autentifikavimo metodo ir prieigos taisyklės, kuri jį naudoja. Tvarka svarbi, nes paslaugos nustatymai taikomi apdorojant konfigūraciją.

Tik vietinės prieigos pavyzdys dviem paslaugoms:

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

Konfigūracijos žinynas paaiškina users, auth strong ir paslaugos komandas. CL saugo šį pavyzdinį slaptažodį kaip paprastą tekstą. Apsaugokite failą ir pasirinkite palaikomą kredencialų saugojimo formą, tinkamą diegimui.

Klientui reikia tinkamo prisijungimo mainų

HTTP paslauga tikisi HTTP tarpinio serverio autentifikavimo. SOCKS paslaugai reikia kliento, palaikančio SOCKS5 naudotojo vardo ir slaptažodžio autentifikavimą. SOCKS4 klientas negali suteikti šių mainų vien todėl, kad pasiekia tą patį klausymosi prievadą.

Žodis strong yra autentifikavimo režimo pavadinimas, o ne užšifruoto perdavimo garantija. Kai reikia, apsaugokite atkarpą nuo kliento iki tarpinio serverio. HTTPS iki paskirties ir šifravimas iki tarpinio serverio lieka atskiri sprendimai.

Loopback susiejimas riboja šį pavyzdį vietine prieiga. Nuotoliniams klientams aiškiai pasirinkite numatytą klausytoją ir tinklo politiką. Viešas pakaitos simbolio klausytojas nepakeičia prisijungimo elgsenos patikros.

Jei viena paslauga prašo kredencialų, o kita ne, patikrinkite nustatymus prieš kiekvieną paslaugos komandą, taisykles po bet kurios flush ir autentifikavimo talpyklą. Slaptažodžio pakeitimas nepataisys paslaugos, paleistos pagal neteisingą politiką. Taip pat operacinės sistemos paskyros pakeitimas nesukuria tarpinio serverio naudotojo.

Susiję straipsniai