Պահանջել մուտք 3proxy-ի թե՛ HTTP, թե՛ SOCKS ծառայություններում

Օգտվող սահմանելը 3proxy-ի մուտքի ամբողջ կարգավորումը չէ։ Ծառայությանը անհրաժեշտ են նաև նույնականացման մեթոդ և մուտքի կանոն, որն օգտագործում է այն։ Հերթականությունը կարևոր է, քանի որ ծառայության կարգավորումները կիրառվում են կարգավորումը մշակելիս։

Միայն տեղական մուտքի օրինակ երկու ծառայությունների համար՝

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

Կարգավորման տեղեկատուն բացատրում է users, auth strong և ծառայության հրահանգները։ CL այս օրինակային գաղտնաբառը պահում է որպես բաց տեքստ։ Պաշտպանեք ֆայլը և ընտրեք տեղակայմանը համապատասխան աջակցվող հավատարմագրերի պահպանման ձև։

Հաճախորդին անհրաժեշտ է մուտքի ճիշտ փոխանակում

HTTP ծառայությունը սպասում է HTTP վստահված սերվերի նույնականացման։ SOCKS ծառայությանը անհրաժեշտ է հաճախորդ, որն աջակցում է SOCKS5 օգտանվան և գաղտնաբառի նույնականացմանը։ SOCKS4 հաճախորդը չի կարող ապահովել այդ փոխանակումը միայն այն պատճառով, որ հասնում է նույն լսման պորտին։

strong բառը նույնականացման ռեժիմի անուն է, ոչ թե գաղտնագրված փոխադրման երաշխիք։ Անհրաժեշտության դեպքում պաշտպանեք հաճախորդից մինչև վստահված սերվեր հատվածը։ Նպատակակետին HTTPS-ը և վստահված սերվերին գաղտնագրումը մնում են առանձին որոշումներ։

Loopback կապերը այս օրինակը սահմանափակում են տեղական մուտքով։ Հեռավոր հաճախորդների համար բացահայտ ընտրեք նախատեսված լսիչ և ցանցային քաղաքականություն։ Հանրային ընդհանրացված լսիչը մուտքի վարքագիծը ստուգելու փոխարինող չէ։

Եթե մի ծառայությունը պահանջում է հավատարմագրեր, իսկ մյուսը՝ ոչ, ստուգեք յուրաքանչյուր ծառայության հրահանգից առաջ կարգավորումները, ցանկացած flush-ից հետո կանոնները և նույնականացման քեշը։ Գաղտնաբառը փոխելը չի կարող վերականգնել սխալ քաղաքականությամբ սկսված ծառայությունը։ Նույն կերպ, դեմոնի օպերացիոն համակարգի հաշիվը փոխելը չի ստեղծում վստահված սերվերի օգտվող։