დავუშვათ, ერთმა პარტნიორ დომენმა უნდა გამოიყენოს მითითებული upstream პროქსი, ხოლო სხვა დაშვებული მოთხოვნები ჩვეულებრივ მშობელს იყენებენ. Squid 7-ში სახელდარქმეული peer-ები და cache_peer_access გამოხატავს ამ პოლიტიკას:

cache_peer partner-proxy.example parent 3128 0 no-query name=partner_parent
cache_peer general-proxy.example parent 3128 0 no-query name=general_parent

acl partner_domain dstdomain .partner.example

cache_peer_access partner_parent allow partner_domain
cache_peer_access partner_parent deny all

cache_peer_access general_parent deny partner_domain
cache_peer_access general_parent allow all

never_direct allow all

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

დამთხვევადი დანიშნულებისთვის მხოლოდ partner_parent რჩება უფლებამოსილი. სხვა დანიშნულებებისთვის მხოლოდ general_parent რჩება უფლებამოსილი. თითოეული ცალკეული peer-ისთვის პირველი დამთხვევი წესი წყვეტს, არის თუ არა ეს peer უფლებამოსილი.

cache_peer_access ფილტრავს კანდიდატებს; ის ყველა peer-ს სარეზერვო ჯაჭვში არ აწყობს. თუ რამდენიმეს დატოვებ უფლებამოსილად, Squid-ის peer-ის შერჩევის ალგორითმები მათ შორის ირჩევენ.

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

ეს კონფიგურაცია იყენებს დოკუმენტირებულ Squid 7 ინტერფეისს. საცნობარო წყარო აღნიშნავს, რომ cache_peer_access მიუწვდომელია Squid 8-ში, ამიტომ ამ პარამეტრის მოვლისას გამოიყენე შესაბამისი განლაგებული ვერსიის დოკუმენტაცია.

დაკავშირებული სტატიები