მოითხოვეთ როგორც Squid-ში შესვლა, ისე კლიენტის სწორი IP

სწორი პაროლი ამ პოლიტიკის მხოლოდ ნახევარია: ანგარიში უნდა მუშაობდეს ერთი დამტკიცებული კლიენტის მისამართიდანაც. Squid-ში ორივე შემოწმების ერთსა და იმავე წვდომის წესზე დაყენება არის განსხვავება ამ მოთხოვნასა და ორ ცალკე შესვლის გზას შორის.

თუ ვივარაუდებთ, რომ ავთენტიფიკაცია უკვე კონფიგურირებულია, მაგალითად Squid 6.13 NCSA-ს კონფიგურაცია, ძირითადი პოლიტიკა ასეთია:

acl approved_login proxy_auth alex
acl approved_source src 192.0.2.40/32
http_access allow approved_source approved_login
http_access deny all

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

შეამოწმეთ მის ზემოთ არსებული წესები

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

ერთი ნებართვა მომხმარებლის სახელისთვის და მეორე წყაროსთვის არ მოითხოვს ორივეს. ნებისმიერი სტრიქონი შეიძლება დამოუკიდებლად წარმატდეს. ეს სხვა პოლიტიკაა.

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

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