شفاف TCP سے SOCKS فارورڈنگ میں اصل منازل

فائر وال بدل سکتا ہے کہ TCP کنکشن کہاں اترتا ہے۔ لیکن صرف اسی تبدیلی سے وہ اصل ایپلیکیشن کو SOCKS بولنا نہیں سکھا سکتا۔

عام SOCKS سرور درخواست کردہ منزل بیان کرنے والی بات چیت کا انتظار کرتا ہے۔ پراکسی سے ناواقف ایپلیکیشن اس کے بجائے فوراً اپنے پروٹوکول بائٹس بھیج دیتی ہے۔ اِن بائٹس کو سیدھا SOCKS سننے والے کی طرف بھیجیں تو دونوں فریق پہلے پیغام پر متفق نہیں ہوں گے۔

غائب جزو ایک مترجم ہے

شفاف TCP سے پراکسی جزو اِن انٹرفیسوں کے درمیان بیٹھتا ہے۔ یہ وہ منزل تلاش کرتا ہے جو ایپلیکیشن نے ابتدا میں طلب کی تھی، مناسب SOCKS یا HTTP CONNECT سیشن قائم کرتا ہے، اور پھر بننے والے بہاؤ پر ایپلیکیشن کا ڈیٹا منتقل کرتا ہے۔

اپنے Linux iptables راستے پر، redsocks کا سورس محفوظ منزل SO_ORIGINAL_DST کے ذریعے حاصل کرتا ہے۔ دیگر آپریٹنگ سسٹم اور ری ڈائریکشن کے طریقے مختلف میکانزم استعمال کرتے ہیں۔ یہ ری ڈائریکٹر اور نیٹ ورک سیٹ اپ کی خصوصیت ہے، عام SOCKS کلائنٹ کی خصوصیت نہیں۔

اصل منزل کی معلومات یہ بھی بتاتی ہیں کہ ری ڈائریکشن قاعدے کو پراکسی میزبان سے غیر متعلق گیٹ وے پر منتقل کرنا ہمیشہ مساوی کیوں نہیں ہوتا۔ وصول کرنے والے عمل کو وہ میٹا ڈیٹا درکار ہوتا ہے جس کا تقاضا اس کا مداخلت کا طریقہ کرتا ہے۔ کہیں اور دوبارہ لکھا گیا پتہ شاید وہ معلومات متوقع شکل میں اب نہ دے۔

مترجم کا دائرہ واضح رکھیں۔ کام کرنے والا ری ڈائریکٹ شدہ TCP کنکشن کسی بھی UDP، ICMP یا ہر ریزولور راستے کی حمایت ثابت نہیں کرتا۔ اپ اسٹریم پراکسی پروٹوکول اور مترجم کا نفاذ اب بھی معاونت یافتہ کارروائیاں طے کرتے ہیں۔

جب کنکشن کے فوراً بعد سیٹ اپ ناکام ہو، تو رسائی کے قواعد وسیع کرنے سے پہلے پروٹوکول کی حد جانچیں۔ مکمل طور پر قابل رسائی SOCKS سننے والا بھی ایسے بائٹس مسترد کر سکتا ہے جو کبھی SOCKS درخواست نہ تھے۔