يشير تطبيقك إلى البروكسي B، لكنه أُطلق عبر غلاف مُهيّأ للبروكسي A. أي مخرج يرى الموقع؟ تعتمد الإجابة على الاتصال الذي يعترضه الغلاف.

في ترتيب متداخل بسيط، يحاول التطبيق أولاً الاتصال بـ B. يعترض الغلاف ذلك الاتصال ويمرره عبر A. ثم يتحدث التطبيق ببروتوكول البروكسي الخاص بـ B عبر التدفق الناتج، ويقوم B بإجراء اتصال الموقع النهائي.

application → wrapper proxy A → application proxy B → website

يرى الموقع اتصال B الخارجي النهائي. ويرى B اتصالاً يصل عبر A. وهذا يختلف عن أن يستبدل الغلاف بصمت إعداد البروكسي الخاص بالتطبيق.

المخطط البسيط له شروط

قواعد التجاوز، واستدعاءات المقابس غير المدعومة، والعمليات القائمة، ونموذج الاعتراض لدى كل منتج يمكن أن تغيّر المسار. بعض الأغلفة يمكنها استثناء بروكسيها أو وجهات مختارة. لا تفترض أن كل زوج من الأدوات يتركّب بالطريقة نفسها.

يوضح وصف proxychains-ng أسلوبه في الاعتراض وحدوده. البرنامج الذي يستخدم دعم البروكسي الأصلي لا يزال يُجري اتصال شبكة بذلك البروكسي، وهذا أحد المرشحين للاعتراض.

لسلسلة مقصودة من نقاط نهاية عامة غير موثّقة، تقدم قائمة البروكسي المجانية مرشحين يجب أن تتوافق بروتوكولاتهم مع كل أداة. وللمخرج غير المتوقع، سجّل ثلاثة عناوين بشكل منفصل: نقطة النهاية التي اختارها التطبيق، ونقطة النهاية التي اختارها الغلاف، والنتيجة التي يراها الموقع. النظر إلى إعدادات المتصفح فقط يفوّت الطبقة الوسطى.

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

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