اجازه دادن به یک درگاه HTTPS اضافی از طریق Squid

یک سرویس HTTPS روی درگاه 8443 ممکن است از طریق پراکسی Squid با پیکربندی صحیح هم کار نکند، حتی وقتی HTTPS معمولی روی 443 کار می‌کند. پیش از تغییر پروتکل پراکسی کلاینت، رد شدن CONNECT و سیاست درگاه مقصد را بررسی کنید.

در یک سیاست دسترسی معمول Squid 6.13، دو بررسی اهمیت دارد: مقصد باید از Safe_ports عبور کند و CONNECT باید از SSL_ports عبور کند. افزودن درگاه فقط به یک ACL ممکن است رد شدن دیگر را همچنان برقرار نگه دارد.

تعریف‌های موجود را با دقت گسترش دهید

برای سیاستی که درگاه‌های معمول وب و یک درگاه HTTPS اضافی را مجاز می‌کند:

acl Safe_ports port 80 443 8443
acl SSL_ports port 443 8443

تعریف‌های مربوط را جایگزین یا ویرایش کنید تا مجموعه‌ای قدیمی و غیرمنتظره از مقادیر باقی نماند. قواعد معمول رد درگاه‌های ناامن و CONNECT و نیز محدودیت‌های موردنظر کلاینت را حفظ کنید.

استثنا را محدود نگه دارید

اگر درگاه اضافی فقط برای یک مقصد تحت کنترل لازم است، یک قاعده رد هدفمند پیش از قاعده اجازه به کلاینت اضافه کنید:

acl extra_tls_port port 8443
acl approved_tls_target dst 203.0.113.20/32
http_access deny CONNECT extra_tls_port !approved_tls_target

این نشانی یک مقدار نمونه برای مستندات است. از مقصدی استفاده کنید که آن را مدیریت می‌کنید یا مجاز به دسترسی به آن هستید و تغییرات واقعی نشانی آن را در نظر بگیرید. این کار استثنای درگاه اضافی را محدود می‌کند، به‌جای آنکه همه مقصدها روی 8443 مجاز شوند.

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

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