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–पेरेंट वाहतूक संरक्षणही वेगळे ठेवा; पहिले कनेक्शन एन्क्रिप्ट केल्याने दुसरे आपोआप सुरक्षित होत नाही.