მოითხოვეთ შესვლა 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-ის შემდეგ და ავთენტიფიკაციის ქეში. პაროლის შეცვლა ვერ შეაკეთებს სერვისს, რომელიც არასწორი პოლიტიკით გაშვდა. ანალოგიურად, დემონის ოპერაციული სისტემის ანგარიშის შეცვლა პროქსის მომხმარებელს არ ქმნის.