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–पेरन्टको यातायात सुरक्षा पनि अलग राख्नुहोस्; पहिलो कनेक्सन इन्क्रिप्ट गर्दा दोस्रो स्वतः सुरक्षित हुँदैन।