Squid पैरेंट के लिए अलग लॉगिन विवरण सेट करें

आपकी Squid सेवा में उपयोगकर्ता का लॉगिन और पैरेंट में Squid का लॉगिन अलग पहचान विवरण हैं। पैरेंट किसी दूसरे ऑपरेटर का हो सकता है या अलग खाता डेटाबेस इस्तेमाल कर सकता है। क्लाइंट का पासवर्ड स्वीकार करने का मतलब यह न मानें कि उसे अपस्ट्रीम भेजना चाहिए।

Squid 6.13 पैरेंट की परिभाषा में स्थिर लॉगिन जोड़ सकता है:

cache_peer 192.0.2.20 parent 3128 0 no-query default name=upstream login=parentuser:ExampleOnly

ऊपर का पता और पासवर्ड दस्तावेज़ के उदाहरण हैं। गलती से दूसरा peer बनाने के बजाय मौजूदा पैरेंट परिभाषा में लॉगिन जोड़ें। कौन से अनुरोधों को यह पैरेंट इस्तेमाल करना ज़रूरी है, यह तय करने वाली अलग रूटिंग नीति बनाए रखें।

खातों के दायरे अलग रखें

डाउनस्ट्रीम auth_param सेटिंग आपके Squid इंस्टेंस के क्लाइंट की जाँच करती है। peer का login विकल्प दूसरे हॉप के पहचान विवरण देता है। एक बदलने से दूसरा अपने आप अपडेट नहीं होता।

पैरेंट की दस्तावेज़ित प्रमाणीकरण ज़रूरतें पूरी करें। यह लाइन हर कनेक्शन आधारित प्रमाणीकरण तरीके की पूरी कॉन्फ़िगरेशन नहीं है। पैरेंट NTLM या Negotiate चाहता हो तो इस फ़ील्ड का पासवर्ड बार-बार बदलने के बजाय समर्थित peer व्यवस्था जाँचें।

Squid में PASS और PASSTHRU जैसे पहचान विवरण आगे भेजने के विकल्प भी हैं। उनका अर्थ समर्पित अपस्ट्रीम खाते से अलग है और वे क्लाइंट की प्रमाणीकरण जानकारी peer को दिखा सकते हैं। डिज़ाइन अलग खाते रखता हो तो उन्हें शॉर्टकट के तौर पर न चुनें।

कॉन्फ़िगरेशन सुरक्षित रखें और सही हॉप जाँचें

स्थिर गोपनीय जानकारी कॉन्फ़िगरेशन में रखी जाती है। फ़ाइल और बैकअप की पहुँच सीमित करें और parser या debug आउटपुट साझा करने से पहले संवेदनशील जानकारी हटाएँ। विकल्प के अपने escaping नियम हैं: दस्तावेज़ URL escapes की अनुमति देता है और साधारण प्रतिशत चिह्न दो बार लिखने को कहता है।

क्लाइंट का प्रमाणीकरण सफल हो मगर आगे भेजे अनुरोध पैरेंट में विफल हों तो उस अपस्ट्रीम आदान-प्रदान और खाते की जाँच करें। क्लाइंट–Squid और Squid–पैरेंट के ट्रांसपोर्ट संरक्षण को भी अलग रखें; पहला कनेक्शन एन्क्रिप्ट करने से दूसरा अपने आप सुरक्षित नहीं होता।