موجودہ HTTP پراکسی تک SSH مقامی فارورڈ: دو loopback پتے

آپ کی منظور شدہ پراکسی ایک جمپ ہوسٹ پر چلتی ہے جہاں وہ صرف loopback پر سنتی ہے، اس لیے اُس مشین سے باہر کوئی چیز اُس تک نہیں پہنچ سکتی۔ آپ کو VPN یا نئی پراکسی کی ضرورت نہیں؛ آپ کو اُس مشین کا ایک پورٹ اپنے ایک پورٹ تک لے جانا ہے۔ مقامی فارورڈ بالکل یہی کرتا ہے، اور اِس کے لیے ایک کمانڈ اور ایپلیکیشن کی ایک سیٹنگ درکار ہے۔ الجھن عموماً یہ ملانے سے ہوتی ہے کہ کون سا loopback پتہ کس مشین کا ہے۔

فیصلہ کریں کہ آیا کوئی مقررہ پراکسی پہلے سے موجود ہے

یہ تکنیک ایسی سروس کو فارورڈ کرتی ہے جو پہلے سے چل رہی ہے۔ اگر دور دراز ہوسٹ پر صرف SSH ڈیمون ہے اور پراکسی نہیں، تو کتنا ہی فارورڈ کریں وہ بنتی نہیں، اور کنکشن دور دراز طرف سے مسترد ہو جائے گا۔ تصدیق کریں کہ پراکسی بندھی ہوئی ہے، اُس کا پورٹ کیا ہے، اور وہ 127.0.0.1 پر سنتی ہے یا کسی مخصوص انٹرفیس پتے پر، کیونکہ فارورڈ کو اُسی پتے کو نشانہ بنانا ہے۔

اِسے پہلے تصدیق کر لینا آپ کو ایسی سرنگ کی ڈیبگنگ سے بچاتا ہے جو کبھی کسی چیز سے منسلک ہی نہیں تھی۔

فارورڈ بنائیں اور کمانڈ پڑھیں

آپ کو جو شکل چاہیے وہ آپ کے لیپ ٹاپ پر ایک loopback پورٹ باندھتی ہے اور سرور کی طرف سے اُسے پراکسی کے پتے سے جوڑتی ہے، جیسے سرور اُسے دیکھتا ہے۔

ssh -NT -o ControlPath=none -o ExitOnForwardFailure=yes \
  -L 127.0.0.1:13128:127.0.0.1:3128 [email protected]

-N دور دراز کمانڈ کو دباتا ہے اور -T termios کی تقسیم کو دباتا ہے، کیونکہ آپ کو شیل نہیں بلکہ سرنگ چاہیے۔ پہلا loopback پتہ وہ ہے جہاں لیپ ٹاپ سنتا ہے؛ دوسرا SSH سرور حل کرتا ہے، اس لیے وہاں کا 127.0.0.1 اُس مشین کی پراکسی مراد ہے۔ ExitOnForwardFailure مقامی پورٹ پہلے سے لیے جانے پر کمانڈ کو بلند آواز میں ناکام کرتا ہے، بجائے ایسا سیشن شروع کرنے کے جو کچھ بھی فارورڈ نہ کرے۔ ہدف پتہ ویسے لکھیں جیسے سرور اُسے حل کرتا ہے، کیونکہ ایسا نام جسے صرف آپ کا لیپ ٹاپ حل کر سکتا ہے دوسری طرف ناکام ہو گا۔

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

ایک ایپلیکیشن کو فارورڈ کی طرف موڑیں

ایپلیکیشن کو http://127.0.0.1:13128 پر HTTP پراکسی استعمال کرنے کے لیے ترتیب دیں، اگر دور دراز پراکسی مانگے تو اسناد کے ساتھ۔ HTTPS منزلوں کے لیے ایپلیکیشن کی اپنی سند کی تصدیق برقرار رکھیں، کیونکہ پراکسی سرنگ اُس کی جگہ نہیں لیتی۔ یہ ایک سروس کا مقررہ فارورڈ ہے، اس لیے ایپلیکیشن کو پراکسی کے بارے میں بتانا ہو گا، اُسے خود ڈھونڈنے کے لیے چھوڑنا نہیں چاہیے۔

کسی بھی مستقل ترتیب سے پہلے ایک فوری جانچ: curl -x http://127.0.0.1:13128 -I https://example.com، جو اُس HTTP CONNECT طریقے کی مشق کرتا ہے جسے پراکسی کو سپورٹ کرنا چاہیے۔

اختیار وہیں رکھیں جہاں تھا

دور دراز پراکسی اب بھی فیصلہ کرتی ہے کہ کن منزلوں اور طریقوں کی اجازت ہے، اور SSH لاگ اِن کو ہر اکاؤنٹ کو خاموشی سے عام ویب ریلے نہیں دینا چاہیے۔ لیپ ٹاپ پر 127.0.0.1 پر باندھنے سے پورٹ آپ کے مقامی نیٹ ورک پر شائع ہونے سے بچتا ہے، اور یہ پورٹ کو اُسی مشین کے دیگر عملوں سے نجی نہیں بناتا۔ اُس بندھن کو پراکسی بانٹنے کے لیے wildcard پتے سے بدلنا ہی غیر منظم کھلا ریلے بننے کا طریقہ ہے۔

SSH نقل و حمل سرور تک کی چھلانگ کی حفاظت کرتی ہے۔ اُس مقام کے بعد پراکسی اپنا کنکشن کھولتی ہے، اس لیے کسی منزل کی طرف سادہ HTTP درخواست سرور کے بعد بھی سادہ رہتی ہے، اگرچہ پہلا حصہ خفیہ تھا۔

دونوں سروں کی تصدیق کریں، پھر صفائی کریں

مقامی سرنگ کی ترتیب اور دور دراز سروس کی کامیابی مختلف نتائج ہیں، اور کمانڈ کی اخراجی حالت آپ کو صرف پہلے کے بارے میں بتاتی ہے۔ ss -ltn کے ساتھ جانچیں کہ سننے والا موجود ہے، پھر ایک اجازت یافتہ ایپلیکیشن درخواست اور ایک درخواست کریں جسے پراکسی کو رد کرنا چاہیے۔ اگر دونوں توقع کے مطابق برتاؤ کریں تو راستہ حقیقی ہے؛ اگر سرنگ چل رہی ہو اور ہر درخواست ناکام ہو تو پراکسی انکار کر رہی ہے یا منزل تک نہیں پہنچ سکتی۔

مکمل ہونے پر، اُسے رکھنے والا SSH عمل روکیں، ایپلیکیشن سے پراکسی سیٹنگ ہٹائیں، اور کام سے زیادہ جینے والا سننے والا چھوڑنے کے بجائے مقامی پورٹ کے چلے جانے کی تصدیق کریں۔