Squid-ის myportname და src ცალკე ACL-ებით გაერთიანება

კონფიგურაცია ერთი შეხედვით დამაჯერებლად გამოიყურება:

acl team_a myportname 3128 src 198.51.100.0/24

მაგრამ ACL-ის განსაზღვრებას მხოლოდ ერთი ტიპი აქვს. აქ myportname ტიპია; სიტყვის src დამატება მეორე შემოწმებას არ იწყებს. დარჩენილი სიტყვები პირველი ტიპის მნიშვნელობების სიას ეკუთვნის. ეს ხაზი არ გამოხატავს „ამ listener-ს და ამ კლიენტურ ქსელს“.

მიეცით თითოეულ პირობას სახელი

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

http_port 192.0.2.10:3128 name=team_a_port
acl team_a_port myportname team_a_port
acl team_a_clients src 198.51.100.0/24

http_access allow team_a_port team_a_clients
http_access deny all

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

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

გამოსასვლელი ცალკე აირჩიეთ

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

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