قد تفشل خدمة 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 بأكملها لتشغيل طلب واحد على منفذ مخصص.

مقالات ذات صلة