قواعد دسترسی Squid 6 برای یک IP کلاینت

این پیکربندی برای Squid 6.13، شامل بستهٔ Debian 13 است. نسخهٔ نصب‌شده را با squid -v تأیید کنید؛ مرجع دستورهای Squid، ‏http_access را در نسخهٔ 8 ناموجود نشان می‌دهد.

ابتدا نشانی‌ها را انتخاب کنید

شنونده به نشانی اختصاص‌یافته به سرور نیاز دارد. قاعدهٔ کلاینت به نشانی مبدأیی که Squid می‌بیند نیاز دارد؛ ممکن است نشانی خروجی عمومی شبکهٔ NAT باشد، نه نشانی خصوصی لپ‌تاپ.

نشانی‌های نمونهٔ مستندات را در پایین عوض کنید. محدودیت کلاینت یک نشانی است که به‌شکل /32 بیان شده است.

http_port 192.0.2.10:3128
acl proxy_client src 198.51.100.27/32
acl Safe_ports port 80 443
acl SSL_ports port 443
acl CONNECT method CONNECT

http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
http_access deny manager
http_access deny to_localhost
http_access deny to_linklocal
http_access allow proxy_client
http_access deny all

شنونده، تعریف‌های ACL و قواعد دسترسی متناظر را در پیکربندی بسته جایگزین کنید، ولی تنظیمات ثبت گزارش و فایل‌سیستم را نگه دارید. افزودن این قواعد زیر یک اجازهٔ قبلی برای کلاینت می‌تواند محدودیت را دور بزند. تعریف‌های تکراری ACL فهرستی نیز ممکن است مقدار اضافه کنند.

درخواست‌ها چگونه از قواعد می‌گذرند

منع‌های نخست، پورت‌های مقصد ناخواسته، درخواست‌های مدیریتی و مقصدهای محلی یا پیوند-محلی را رد می‌کنند. کلاینت شناخته‌شده پس از این بررسی‌ها مجاز می‌شود؛ همهٔ درخواست‌های دیگر به منع نهایی می‌رسند. حفاظت مقصد همچنان لازم است، چون فهرست مجاز مبدأ به‌تنهایی مقصدها را محدود نمی‌کند.

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

sudo squid -k parse -f /etc/squid/squid.conf

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