ایک پروکسی پورٹ HTTP اور SOCKS دونوں کیسے قبول کر سکتا ہے

ملا جلا پروکسی سننے والا ایک ہی TCP پورٹ پر HTTP اور SOCKS قبول کر سکتا ہے کیونکہ سرور ابتدائی پروٹوکول بائٹس کا معائنہ کرتا ہے۔ پورٹ نمبر وہ شناخت نہیں کرتا۔

HTTP پروکسی کی درخواست HTTP طریقے سے شروع ہوتی ہے، جیسے GET یا CONNECT۔ SOCKS سلام بائنری پروٹوکول فیلڈز سے شروع ہوتا ہے۔ ان ان پٹس کے لیے بنایا گیا سافٹ ویئر کنکشن کو مناسب ہینڈلر تک بھیج سکتا ہے۔

یہ ایک واضح نفاذ کی خصوصیت ہے۔ عام Squid HTTP سننے والا اپنا پورٹ 1080 میں بدلنے سے ملا جلا نہیں ہوتا، اور صرف SOCKS والا سننے والا براؤزر کی ترتیب سے HTTP نہیں سیکھتا۔

TLS ایک اور حد شامل کرتا ہے: خفیہ کردہ پروکسی کنکشن TLS سے شروع ہوتا ہے، نظر آنے والے HTTP طریقے سے نہیں۔ اسی اینڈ پوائنٹ پر اس کی حمایت کے لیے اضافی جان بوجھ کر ہینڈلنگ درکار ہے؛ سادہ HTTP اور SOCKS کو پہچاننا اس صلاحیت کو ثابت نہیں کرتا۔

اینڈ پوائنٹ کے لیے دستاویزی کلائنٹ پروٹوکول استعمال کریں۔ اگر دونوں کام کریں تو یہ اس سرور کے ملے جلے سننے والے کا ثبوت ہے، ہر کلائنٹ میں پروٹوکول غیر متعین چھوڑنے کی وجہ نہیں۔

Glider کا ملا جلا سننے والا ایک ٹھوس مثال دیتا ہے: یہ ایک بائٹ کو استعمال کیے بغیر اس پر نظر ڈالتا ہے، 0x05 اپنے SOCKS5 ہینڈلر کو بھیجتا ہے، اور بصورت دیگر اپنا HTTP پارسر بلاتا ہے۔ وہ پارسر اب بھی آنے والی درخواست کی تصدیق کرتا ہے؛ بھیجنے کا انتخاب من مانی ان پٹ کو درست HTTP نہیں بناتا۔

TCP سننے والے کو شیئر کرنا بذات خود SOCKS5 UDP تعلق فراہم نہیں کرتا۔ Glider اپنا UDP سننے والا الگ شروع کرتا ہے۔ TCP پروٹوکول کا انتخاب اور بعد میں ڈیٹا گرام کی ترسیل الگ صلاحیتیں ہیں۔