تنظیم اعتبارنامهٔ جداگانه برای پراکسی والد 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 شما را اعتبارسنجی می‌کنند. گزینهٔ login در peer، اعتبارنامهٔ گام دیگری را می‌دهد. تغییر یکی دیگری را خودکار به‌روز نمی‌کند.

الزامات احراز هویت مستندشدهٔ والد را رعایت کنید. این خط پیکربندی کامل همهٔ روش‌های احراز هویت اتصال‌گرا نیست. اگر والد NTLM یا Negotiate می‌خواهد، به‌جای تغییر مکرر گذرواژه در این فیلد، چیدمان peer پشتیبانی‌شده را بررسی کنید.

Squid گزینه‌های انتقال اعتبارنامه مانند PASS و PASSTHRU هم دارد. معنای آن‌ها با حساب بالادست اختصاصی فرق دارد و ممکن است اطلاعات احراز هویت کلاینت را برای peer آشکار کنند. اگر طرح حساب‌های جداگانه دارد، آن‌ها را میان‌بر نگیرید.

از پیکربندی محافظت کنید و گام درست را بیازمایید

راز ثابت در پیکربندی ذخیره می‌شود. دسترسی به فایل و پشتیبان را محدود و خروجی تحلیل‌گر یا اشکال‌زدایی را پیش از اشتراک از اطلاعات حساس پاک کنید. این گزینه قواعد گریز خود را دارد: مستندات گریزهای URL را مجاز می‌داند و می‌خواهد نویسهٔ درصدِ لفظی دو بار نوشته شود.

اگر احراز هویت کلاینت‌ها موفق است اما درخواست‌های هدایت‌شده هنوز در والد شکست می‌خورند، همان تبادل بالادست و حساب را بررسی کنید. حفاظت انتقال کلاینت–Squid و Squid–والد را نیز جدا نگه دارید؛ رمزگذاری اتصال اول دومی را خودکار امن نمی‌کند.