Proxychains عبر Squid: قيود CONNECT على المنفذ 80
ميّز طلبات HTTP العادية عبر الوكيل من أنفاق HTTP CONNECT في proxychains عندما يُرفض منفذ الوجهة 80.
يحمّل المتصفح صفحة HTTP عبر Squid. ويفشل الوجه نفسه تحت proxychains. وهذا لا يعني بالضرورة أن أحد البرنامجين اختار عنوان IP خاطئًا للوكيل.
يمكن لعميل عادي يفهم HTTP أن يرسل طلب الويب إلى الوكيل الأمامي في صيغة وكيل HTTP. أما غلاف المقبس العام فيحتاج بدلًا من ذلك إلى نفق بايتات للاتصال الذي أرادت التطبيق فتحه. وبالنسبة إلى وكيل HTTP في سلسلته، يستخدم proxychains الأمر CONNECT.
هذا يعني أن موقعًا نصيًا صريحًا على المنفذ 80 يمكن أن يولّد طلب CONNECT للمنفذ 80. وسياسة Squid التي تسمح بـ CONNECT فقط لقائمة منافذ TLS المعتمدة يمكن أن ترفض ذلك النفق رغم السماح بطلبات HTTP العادية إلى المنفذ 80.
قارن الطلبات، لا أسماء المضيفين فقط
توثّق وثائق proxychains-ng دعمها لـ HTTP CONNECT. ويمكن لقواعد الوصول في Squid التمييز بين الطريقة ومنفذ الوجهة. فهذان مساران مختلفان للطلب إلى الموقع نفسه.
اقرأ سبب الرفض والسياسة المقصودة قبل تغييرها. توسيع وصول CONNECT ليشمل كل المنافذ تغيير جوهري؛ ولا ينبغي أن يكون الاستجابة الافتراضية لعدم تطابق الغلاف.
إذا كان للتطبيق دعم أصلي لوكيل HTTP، فإن استخدامه يمكن أن يتجنب نفقًا عامًا غير ضروري لـ HTTP النصي الصريح. وإذا كان يحتاج فعلًا إلى نفق TCP خام، فاختر بروتوكول وكيل وسياسة منافذ معتمدين يوفرانه.
طلب متصفح ناجح دليل مفيد على إمكانية الوصول إلى الوكيل وعلى نمط طلب مدعوم واحد. لكنه لا يثبت أن كل طريقة نفق أو منفذ وجهة أو بروتوكول تطبيق مسموح عبر ذلك الوكيل.