ለ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–ላይኛው ፕሮክሲ የማስተላለፍ ጥበቃንም ለይተው ይያዙ፤ የመጀመሪያውን ግንኙነት ማመስጠር ሁለተኛውን በራሱ አይጠብቅም።