Squid-ის ერთი დანიშნულების დაშვება პროქსის ავთენტიფიკაციის გარეშე

მონიტორინგის გვერდი უნდა მუშაობდეს პროქსიში შესვლის გარეშე. აშკარა წესია http_access allow status_site. ავთენტიფიკაციამდე განთავსებული, მან გამონაკლისი შეიძლება მისცეს იმ კლიენტებსაც, რომელთა მომსახურებასაც არასდროს აპირებდით.

Squid 6 ან 7-ისთვის გამონაკლისის პირობები ერთად შეინახეთ. არსებული მართვის, არაუსაფრთხო პორტების, CONNECT-ისა და ლოკალური სერვისების დაცვის შემდეგ, შესაბამისი ნაწილი შეიძლება ასე გამოიყურებოდეს:

acl office_clients src 192.0.2.0/24
acl status_site dstdomain status.example.net
acl signed_in proxy_auth REQUIRED

http_access allow office_clients status_site
http_access allow office_clients signed_in
http_access deny all

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

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

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

ჰოსტის სახელის გამონაკლისი ფარავს შესაბამის დანიშნულებას და არა მისი გვერდის მიერ ჩატვირთულ ყველა დამოკიდებულებას. გადამისამართებები და მესამე მხარის რესურსები კანონიერად შეიძლება შეხვდეს ჩვეულებრივ შესვლის მოთხოვნას.

უბრალო HTTP-ისთვის პროქსის შეუძლია გამოიყენოს უფრო ზუსტი URL ინფორმაცია, სადაც შესაბამისია. ჩვეულებრივი HTTPS CONNECT მოთხოვნა არ ამხელს გვერდის ბილიკს, ამიტომ „მხოლოდ ერთი გვერდის“ წესი ვერ გამოვიდა მთელი ჰოსტის გვირაბის გამონაკლისიდან.