मान लीजिए कि एक साझेदार डोमेन को निर्दिष्ट upstream प्रॉक्सी का उपयोग करना है, जबकि अन्य अनुमत अनुरोध सामान्य पैरेंट का उपयोग करते हैं। Squid 7 में नामित peers और 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 उम्मीदवारों को फ़िल्टर करता है; यह सभी peers को फ़ॉलबैक श्रृंखला में नहीं रखता। यदि आप कई पात्र छोड़ते हैं, तो Squid के peer-चयन एल्गोरिदम उनमें से चुनते हैं।

never_direct पंक्ति इस उदाहरण में पैरेंट के उपयोग को अनिवार्य बनाती है। यदि आवश्यक पैरेंट का उपयोग नहीं किया जा सकता, तो सीधा कनेक्शन विकल्प के रूप में प्रस्तुत नहीं किया जाता। http_access में मौजूदा क्लाइंट और गंतव्य अनुमतियाँ बनाए रखें; वे नियम तय करते हैं कि upstream चयन से पहले कौन से अनुरोध स्वीकार किए जाते हैं।

यह कॉन्फ़िगरेशन प्रलेखित Squid 7 इंटरफ़ेस का उपयोग करता है। संदर्भ cache_peer_access को Squid 8 में अनुपलब्ध बताता है, इसलिए इस सेटअप का रखरखाव करते समय मेल खाते तैनात संस्करण के दस्तावेज़ का उपयोग करें।

संबंधित लेख