Squid کے ذریعے Proxychains: پورٹ 80 پر CONNECT پابندیاں

براؤزر Squid کے ذریعے HTTP صفحہ لوڈ کرتا ہے۔ وہی ہدف proxychains کے تحت ناکام ہوتا ہے۔ اس کا مطلب یہ نہیں کہ دونوں میں سے کسی پروگرام نے غلط پراکسی IP منتخب کی ہے۔

عام HTTP سمجھنے والا کلائنٹ ویب درخواست کو HTTP پراکسی کی شکل میں فارورڈ پراکسی کو بھیج سکتا ہے۔ البتہ عام ساکٹ ریپر کو اس کنکشن کے لیے بائٹ سرنگ درکار ہوتی ہے جو ایپلیکیشن کھولنا چاہتی تھی۔ اپنی زنجیر میں موجود HTTP پراکسی کے لیے proxychains CONNECT استعمال کرتا ہے۔

یعنی پورٹ 80 پر سادہ متن کی ویب سائٹ پورٹ 80 کے لیے CONNECT درخواست پیدا کر سکتی ہے۔ صرف منظور شدہ TLS پورٹ فہرست کی طرف CONNECT کی اجازت دینے والی Squid پالیسی اس سرنگ کو مسترد کر سکتی ہے، حالانکہ پورٹ 80 پر عام HTTP درخواستیں اجازت یافتہ ہیں۔

صرف ہوسٹ نام نہیں، درخواستوں کا موازنہ کریں

proxychains-ng کی دستاویزات اس کی HTTP CONNECT معاونت بیان کرتی ہیں۔ Squid کے رسائی قواعد طریقہ اور ہدف پورٹ میں فرق کر سکتے ہیں۔ یہ اسی ویب سائٹ کی طرف مختلف درخواست راستے ہیں۔

تبدیل کرنے سے پہلے مسترد ہونے اور مطلوبہ پالیسی کو پڑھیں۔ CONNECT رسائی کو ہر پورٹ تک بڑھانا ایک بڑی تبدیلی ہے؛ ریپر کی ناہمواری کے لیے یہ طے شدہ جواب نہیں ہونا چاہیے۔

اگر ایپلیکیشن میں مقامی HTTP پراکسی معاونت ہے، تو اس کا استعمال سادہ متن HTTP کے لیے غیر ضروری عام سرنگ سے بچا سکتا ہے۔ اگر اسے واقعی خام TCP سرنگ درکار ہو، تو وہ فراہم کرنے والا منظور شدہ پراکسی پروٹوکول اور پورٹ پالیسی منتخب کریں۔

کامیاب براؤزر درخواست پراکسی کی رسائی اور ایک معاون درخواست طریقہ کے بارے میں مفید ثبوت ہے۔ لیکن یہ ثابت نہیں کرتی کہ ہر سرنگ طریقہ، ہدف پورٹ یا ایپلیکیشن پروٹوکول اس پراکسی کے ذریعے اجازت یافتہ ہے۔