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

http_access allow office_clients approved_destination

هر دو ACL باید مطابق باشند تا آن خط درخواست را مجاز کند. تقسیم آن سیاست را تغییر می‌دهد:

http_access allow office_clients
http_access allow approved_destination

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

ترتیب بخشی از سیاست است

Squid قواعد دسترسی را به ترتیب ارزیابی می‌کند. نخستین تصمیم منطبق درخواست را کنترل می‌کند. یک allow all پیشین یک محدودیت دقیق بعدی را بی‌اثر می‌کند؛ یک رد منطبق پیشین مانع رسیدن به یک اجازه بعدی می‌شود.

مستندات http_access این ترتیب را توضیح می‌دهد. یک رد نهایی عامدانه نگه دارید، به‌جای تکیه بر اینکه خواننده رفتار پیش‌فرض ضمنی را به یاد بسپارد.

بسیاری از تعریف‌های ACL رابطهٔ OR متفاوتی دارند: یک ACL مبدأ نام‌دار می‌تواند چندین محدودهٔ مجاز را فهرست کند. این باعث نمی‌شود هویت مبدأ و مقصد یک نوع ACL شود. آن‌ها را جدا تعریف کنید و سپس نام‌ها را در یک تصمیم دسترسی ترکیب کنید.

برای یک خروج خصوصی، این بر اینکه چه کسی می‌تواند از IP بیرونی شما استفاده کند اثر می‌گذارد. چهار حالت را در نظر بگیرید: مشتری تأییدشده به مقصد تأییدشده، مشتری تأییدشده به جای دیگر، مشتری دیگر به مقصد تأییدشده، و مشتری دیگر به جای دیگر. اگر قواعد بیش از آنچه سیاست می‌خواهد حالت مجاز کنند، منطق را پیش از گستردن شنونده اصلاح کنید. پیکربندی از نظر نحوی معتبر باز هم می‌تواند مجوزهای نادرست را بیان کند.

مقالات مرتبط