Privoxy: HTTP پراکسی کلائنٹ کو SOCKS سرنگ سے جوڑنا

SSH متحرک سرنگ، بشمول PuTTY کی متحرک فارورڈنگ، SOCKS انٹرفیس فراہم کرتی ہے۔ صرف HTTP پراکسی قبول کرنے والی ایپلیکیشن اس پورٹ کو محض HTTP کہہ کر استعمال نہیں کر سکتی۔

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

Privoxy اس ترتیب کو اپنے فارورڈنگ اصولوں کے ذریعے دستاویز کرتا ہے۔ موجودہ مقامی SOCKS5 سرنگ کے لیے کنفیگریشن کا ٹکڑا یہ ہے:

forward-socks5 / 127.0.0.1:1080 .

ایپلیکیشن Privoxy کے HTTP سننے والے سے جڑتی ہے، پورٹ 1080 سے نہیں۔ اس سننے والے کو مطلوبہ رسائی پالیسی کے تحت مقامی رکھیں۔ اصول میں آخری نقطے کا ایک دستاویزی مطلب ہے؛ یہ کسی غائب انٹرنیٹ ہوسٹ نام کا پلیس ہولڈر نہیں ہے۔

یہ پروٹوکول ترجمہ ہے

Privoxy کی فارورڈنگ دستاویز SOCKS فارورڈنگ نحو اور ہوسٹ ناموں کی نشست بتاتی ہے۔ عام TCP پورٹ فارورڈنگ وہی ترجمہ نہیں کرتی: یہ کلائنٹ کے HTTP بائٹس کو بغیر تبدیلی SOCKS سننے والے تک پہنچاتی ہے، جو اب بھی SOCKS گفت و شنید کی توقع رکھتا ہے۔

پل بھی اس کنفیگریشن کا حصہ بن جاتا ہے جسے آپ کو سمجھنا ہے۔ Privoxy کی اپنی مواد فلٹرنگ اور رسائی کی ترتیبات ہو سکتی ہیں۔ اسے شامل کرنا اصل ایپلیکیشن میں مقامی طور پر SOCKS کی حمایت کے برابر نہیں ہے۔

HTTPS سائٹس کے لیے ایپلیکیشن عام طور پر HTTP پل سے CONNECT مانگتی ہے، اور پل SOCKS کے ذریعے منزل کا کنکشن حاصل کرتا ہے۔ سائٹ کا عام TLS ایپلیکیشن اور سائٹ کا رشتہ ہی رہتا ہے؛ اس راستے کے لیے پل کو سائٹ کا روپ دھارنے کی ضرورت نہیں۔

اگر ایپلیکیشن براہ راست SOCKS استعمال کر سکتی ہے، تو اضافی جزو غیر ضروری ہو سکتا ہے۔ پل کو حقیقی پروٹوکول عدم مطابقت حل کرنے کے لیے استعمال کریں، سننے والے اور بالائی بہاؤ کو واضح طور پر الگ رکھتے ہوئے۔