Squid പാരന്റിന് വേറിട്ട പ്രവേശനവിവരങ്ങൾ നൽകുക
ക്ലയന്റിന്റെ പ്രോക്സി പാസ്വേഡ് മറ്റൊരു ഓപ്പറേറ്റർക്ക് നൽകണമെന്നു കരുതാതെ Squid 6.13-ന് സ്വന്തം അപ്സ്ട്രീം ലോഗിൻ നൽകുക.
നിങ്ങളുടെ 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–പാരന്റ് കൈമാറ്റസംരക്ഷണവും വേർതിരിക്കുക; ആദ്യ കണക്ഷൻ എൻക്രിപ്റ്റ് ചെയ്താൽ രണ്ടാമത്തേത് സ്വമേധയാ സുരക്ഷിതമാകില്ല.