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–پیرنٹ کی نقل و حمل کی حفاظت بھی الگ رکھیں؛ پہلے کنکشن کی خفیہ کاری دوسرے کو خودکار محفوظ نہیں کرتی۔