تحقق من أن وكيلك ليس مفتوحًا للجميع

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

تحقق من الاستماع والسياسة الفعليين

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

ثم افحص الإعداد الذي حمّلته العملية فعلًا، بما فيه الملفات المضمّنة. في Squid 6، قد يلغي سماح سابق أثر قيد لاحق. وفي Tinyproxy 1.11.2، حذف جميع أسطر Allow وDeny يسمح بكل العملاء. لدى Dante قواعد منفصلة للعميل وSOCKS، لذا قبول اتصال TCP ليس السياسة كاملة.

استخدم توثيق الإصدار المثبت. تغييرات توجيهات Squid 8 سبب للتحقق من الإصدار، لا لافتراض أن إعدادًا مألوفًا قُبل بالمعنى نفسه.

اختبر الحالات المسموحة والمرفوضة

إذا كان الوكيل مطلوبًا أن يشترط مصدرًا معتمدًا وتسجيل دخول معًا، فاختبر هذه المصفوفة باستخدام أنظمة تسيطر عليها:

قد يظهر جهازان خلف NAT واحد كمصدر واحد. اختر مواقع اختبار بعناوين مصدر مختلفة عند الوكيل وأكدها في سجلاته. لا تستخدم أجهزة أطراف ثالثة لا علاقة لها، ولا تفحص خدمات الآخرين.

قد لا ينتج رفض الجدار الناري أي استجابة HTTP؛ وقد يعيد رفض التطبيق خطأً. في الحالتين تحقق من أن الهدف الذي تسيطر عليه لم يستقبل الطلب المحظور؛ وإلا فقد تُخلط صفحة الخطأ وحدها باستجابة الوجهة.

اختبر أنماط التمرير التي تريد السماح بها

لوكيل ويب، اختبر طلب HTTP عاديًا ومسار HTTPS CONNECT المسموح منفصلين. إذا كانت القيود على الوجهة جزءًا من السياسة، فاختبر وجهة مسموحة وأخرى تحت سيطرتك يجب رفضها. لا تزل الضوابط فقط لإنجاح كل اختبار.

أعد الاختبار بعد تغيير نطاقات المصدر أو بيانات الاعتماد أو عناوين الاستماع أو الملفات المضمّنة أو إصدارات الخدمة. احفظ وقت الاختبار وإصدار الإعداد والنتائج معًا لفحص التغييرات اللاحقة مقابل الحدود نفسها.

هذا إجراء قبول، وليس ادعاء بأن محلل إعداد أو طلبًا واحدًا يثبت إغلاق كل مسار شبكي.