پروتکل PROXY در Squid: پیش از بررسی‌های دسترسی HTTP به فرستنده اعتماد کنید

از proxy_protocol_access برای اعتماد به رله‌ای که فراداده را تأمین می‌کند استفاده کنید، نه برای انتخاب وب‌سایت‌های مجاز. در Squid 5–7 بررسی یک بار پس از برپایی TCP روی شنوندهٔ require-proxy-header و پیش از پردازش سرآیندهای درخواست HTTP اجرا می‌شود:

acl trusted_relay src 192.0.2.20/32
http_port 3128 require-proxy-header
proxy_protocol_access allow trusted_relay
proxy_protocol_access deny all

نشانی رلهٔ نمونه را جایگزین کنید و دسترسی شبکه به این شنونده را محدود کنید. در این مرحله Squid همتای واقعی TCP را پیش از پذیرش فرادادهٔ ارائه‌شده بررسی می‌کند. پس از پذیرش، از نشانی کارخواهِ ادعاشده برای بررسی‌های ACL و ثبت رویداد بعدی استفاده می‌کند. اعتماد به رله بر پایهٔ نشانی کارخواهی که ادعا می‌کند، همین ترتیب را وارونه می‌کند.

http_access را برای مجوزهای بعدیِ مبدأ کارخواه و مقصد نگه دارید. پذیرش فراداده به دسترسی به وب‌سایت مجوز نمی‌دهد و ACL دامنهٔ مقصد نمی‌تواند به پرسش پیشینِ اعتماد به فرستنده پاسخ دهد.

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

رلهٔ مورد اعتماد می‌تواند از راه هویت کارخواهی که تأمین می‌کند بر مجوز مبتنی بر نشانی اثر بگذارد. این توانایی را تنها به واسطهٔ موردنظر بدهید.