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–પેરન્ટ પરિવહન સુરક્ષા પણ અલગ રાખો; પ્રથમ કનેક્શન એન્ક્રિપ્ટ કરવાથી બીજું આપમેળે સુરક્ષિત થતું નથી.