Squid-ის ჩარევა და პროქსის აშკარა ავთენტიფიკაცია

აშკარა პროქსის კლიენტმა იცის, რომ პროქსის ესაუბრება. ჩარეული ბრაუზერი ფიქრობს, რომ საიტს დაუკავშირდა. ეს განსხვავება ავთენტიფიკაციისთვის ცენტრალურია.

ჩვეულებრივი პროქსის ავთენტიფიკაცია იყენებს პროქსის გამოწვევას და პროქსის ავტორიზაციის პასუხს. კლიენტმა, რომელმაც პროქსი არ აირჩია, არ უნდა გაუგზავნოს გულგრილად პროქსის სერტიფიკატები მოულოდნელ შუამავალს.

ამიტომ Squid-ის ჩარევის სახელმძღვანელო არ უჭერს მხარს proxy_auth-ის უბრალოდ ჩარევის რეჟიმთან შეერთებას. მომუშავე Basic ავთენტიფიკაციის დამხმარე არ ცვლის იმას, რასაც ბრაუზერი დისტანციურ ბოლო წერტილად მიიჩნევს.

თუ იდენტიფიცირებულ მომხმარებლებს სჭირდებათ ჩვეულებრივი ავთენტიფიცირებული გადამისამართებადი პროქსი, დააკონფიგურირეთ კლიენტები აშკარად, პირდაპირ ან შესაბამისი მართული პროქსის კონფიგურაციის გზით. ეს მსმენელი და მისი ავთენტიფიკაციის პოლიტიკა ცალკე შეინახეთ ჩარევის მსმენელისგან.

ავთენტიფიკაციის პორტალი, ქსელის დონის იდენტობის სისტემა ან TLS ჩარევის მოწყობა სხვა დიზაინია, განსხვავებული ნდობისა და განლაგების მოთხოვნებით. ეს არ არის ერთსტრიქონიანი შესწორება დაკარგული აშკარა პროქსის გაცვლისთვის.

ნუ გადაწყვეტთ მოთხოვნის არარსებობას ჩარეული სერვისის საჯარო გახდომით ან ყველა კლიენტის დაშვებით. ჯერ გადაწყვიტეთ, მოთხოვნა აშკარა მომხმარებლის ავთენტიფიკაციაა თუ იმ ტრაფიკის ჩარევა, რომელიც არასოდეს დაკონფიგურირებულა პროქსისთვის. ორივეს სხვადასხვა ვარაუდი სჭირდება.