گذرواژه درست تنها نیمی از این سیاست است: حساب باید از یک نشانی مشتری تأییدشده نیز کار کند. در Squid، قرار دادن هر دو بررسی روی یک قاعده دسترسی همان تفاوت میان این الزام و دو راه ورود جداگانه است.

با فرض اینکه احراز هویت از قبل پیکربندی شده است، مانند راه‌اندازی Squid 6.13 NCSA، سیاست اصلی این است:

acl approved_login proxy_auth alex
acl approved_source src 192.0.2.40/32
http_access allow approved_source approved_login
http_access deny all

از منبعی که Squid واقعاً دریافت می‌کند استفاده کنید؛ نمونه یک نشانی مستندات است. حفاظت‌های پیشین برای درگاه‌های مقصد ناامن، سرویس‌های محلی و ترافیک CONNECT را حفظ کنید. این قطعه شرط ترکیبی را نشان می‌دهد، نه پیکربندی کامل شنونده.

قواعد بالای آن را بررسی کنید

یک اجازه گسترده قبلی می‌تواند درخواست را پیش از رسیدن به شرط جدید بپذیرد. مرجع http_access تطبیق مرتب را توصیف می‌کند. کل توالی را بخوانید، از جمله فایل‌های شامل‌شده.

یک اجازه برای نام کاربری و دیگری برای منبع، هر دو را الزامی نمی‌کند. هر خط می‌تواند مستقلاً موفق شود. این سیاست متفاوتی است.

ACL proxy_auth به یک کمک‌کننده احراز هویت وابسته است. تعریف آن روش ساخت کاربر یا اعتبارسنجی گذرواژه نیست. این مثال برای یک پروکسی صریح است که مشتریانش می‌توانند به چالش‌های احراز هویت پروکسی پاسخ دهند.

هویت منبع نیز محدودیت‌هایی دارد. افرادی پشت یک NAT می‌توانند یک نشانی را به اشتراک بگذارند و یک لپ‌تاپ متحرک می‌تواند نشانی را تغییر دهد. شرط اضافی مکان شبکه قابل استفاده حساب را محدود می‌کند؛ اما یک رایانه فیزیکی را به‌طور مطمئن شناسایی نمی‌کند. مطمئن شوید این محدودیت با دلیلی که شرط را در ابتدا اضافه کردید همخوانی دارد.

مقالات مرتبط