يمكن لـSquid 6.13 قبول طلبات البروكسي الأمامي عبر TLS عند بنائه باستخدام GnuTLS أو OpenSSL. يحمي ذلك الرابط بين العميل والبروكسي دون اعتراض جلسة وجهة HTTPS المنفصلة.

  1. احصل على شهادة لاسم المضيف الذي سيستخدمه العملاء للوصول إلى Squid. اقصر الوصول إلى مفتاحها الخاص على هويات الخدمة التي تحتاجه.
  2. أضف مستمع TLS باستخدام العنوان المخصّص لك ومسارات الشهادات الفعلية:
https_port 192.0.2.10:3129 tls-cert=/etc/squid/proxy-chain.pem tls-key=/etc/squid/proxy-key.pem

احتفظ بـقائمة العملاء المسموحين وقيود الوجهات وسياسة المصادقة. لا يمنح المستمع حق الوصول. كما يُبقي http_port الموجود نشطًا؛ احذف المستمع الأقدم أو قيّده إذا كان يلزم استخدام TLS في جميع اتصالات العملاء. لا حاجة إلى وضع مسرّع أو اعتراض أو توليد شهادات.

حلّل الإعداد قبل إعادة تحميل الخدمة المقصودة. يتحقق المحلّل من البنية وتحميل الشهادات، لا من إمكانية الوصول عبر الشبكة. بعد إعادة تحميل ناجحة، أرسل طلبًا عبر نقطة TLS من عميل مسموح:

curl --proxy https://proxy.example:3129 --proxy-cacert approved-proxy-ca.pem --connect-timeout 5 --max-time 15 https://example.com/

استخدم اسم مضيف البروكسي الفعلي وملف CA المعتمد. قد لا تحتاج شهادة بروكسي موثوقة عموميًا إلى حزمة مخصّصة. يضبط --proxy-cacert الثقة بالبروكسي ويترك التحقق من الوجهة منفصلًا؛ احتفظ بـالفحصين معًا.

افحص المستمع الفعلي واسم الشهادة، ثم اختبر أيضًا مصدرًا تحت سيطرتك يجب رفضه. لا يكفي نجاح التحليل وحده لإثبات ثقة العميل أو حدود الوصول.

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