Pieprasīt pieteikšanos abos 3proxy HTTP un SOCKS pakalpojumos

Konfigurējiet 3proxy lietotājus, spēcīgu autentifikāciju un pakalpojumu piekļuves noteikumus HTTP un SOCKS5 klientiem.

Lietotāja definēšana nav visa 3proxy pieteikšanās konfigurācija. Pakalpojumam ir vajadzīga arī autentifikācijas metode un piekļuves noteikums, kas to izmanto. Secība ir svarīga, jo pakalpojuma iestatījumi tiek piemēroti konfigurācijas apstrādes laikā.

Tikai lokālas piekļuves piemērs diviem pakalpojumiem:

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

Konfigurācijas rokasgrāmata izskaidro users, auth strong un pakalpojumu komandas. CL glabā šo piemēra paroli kā vienkāršu tekstu. Aizsargājiet failu un izvēlieties atbalstītu akreditācijas datu glabāšanas formu, kas piemērota izvietošanai.

Klientam nepieciešama pareizā pieteikšanās apmaiņa

HTTP pakalpojums sagaida HTTP starpniekservera autentifikāciju. SOCKS pakalpojumam nepieciešams klients, kas atbalsta SOCKS5 lietotājvārda un paroles autentifikāciju. SOCKS4 klients nevar nodrošināt šo apmaiņu tikai tāpēc, ka tas sasniedz to pašu klausīšanās portu.

Vārds strong ir autentifikācijas režīma nosaukums, nevis šifrētas pārvades garantija. Ja nepieciešams, aizsargājiet posmu no klienta līdz starpniekserverim. HTTPS līdz galamērķim un šifrēšana līdz starpniekserverim joprojām ir atsevišķi lēmumi.

Loopback piesaistes ierobežo šo piemēru ar lokālu piekļuvi. Attāliem klientiem skaidri izvēlieties paredzēto klausītāju un tīkla politiku. Publisks aizstājējzīmes klausītājs neaizstāj pieteikšanās uzvedības pārbaudi.

Ja viens pakalpojums pieprasa akreditācijas datus, bet otrs ne, pārbaudiet iestatījumus pirms katras pakalpojuma komandas, noteikumus pēc jebkuras flush un autentifikācijas kešatmiņu. Paroles maiņa nevar salabot pakalpojumu, kas palaists ar nepareizu politiku. Tāpat dēmona operētājsistēmas konta maiņa neizveido starpniekservera lietotāju.

Saistītie raksti