اپنے SSH کلائنٹ کے ذریعے دور دراز Pi کو SOCKS پراکسی دیں

دور دراز کی متحرک فارورڈنگ SOCKS سننے والے کو Pi پر رکھتی ہے اور اگلا کنکشن آپ کے لیپ ٹاپ کے منظور شدہ VPN راستے سے کرتی ہے۔ دوسرے SSH سرور کی ضرورت نہیں۔

آپ فرض کرتے ہیں کہ SOCKS پراکسی وہیں چلنی چاہیے جہاں نیٹ ورک تک رسائی پہلے سے موجود ہے۔ OpenSSH سننے والے کو بالکل کسی اور جگہ رکھ سکتا ہے۔ دور دراز کی متحرک فارورڈنگ دور دراز میزبان پر SOCKS پورٹ کھولتی ہے اور ہر کنکشن آپ کے مقامی SSH کلائنٹ سے شروع کرتی ہے، جو آپ کے لیپ ٹاپ کا منظور شدہ VPN راستہ لے کر جاتا ہے۔ Pi کو محدود پراکسی ملتی ہے؛ یہ آپ کی ٹنل یا آپ کے اختیارات کا وارث نہیں ہوتا.

سننے والا اور وہ طرف جہاں سے کنکشن شروع ہوتا ہے مختلف ہو سکتے ہیں

ایک عام ssh -D 1080 سننے والے کو آپ کی اپنی مشین پر چلاتا ہے اور وہیں سے کنکشن بھیجتا ہے۔ دور دراز کی متحرک فارورڈنگ اسے الٹ دیتی ہے: سننے والا دور دراز میزبان پر ظاہر ہوتا ہے، اور جو بھی کنکشن وہ قبول کرتا ہے وہ مقامی طرف سے کھلتا ہے۔ OpenSSH کلائنٹ کی دستی کتاب بغیر کسی مقررہ منزل کے -R کو بالکل اسی SOCKS4/5 ترتیب کے طور پر درج کرتی ہے۔

لیپ ٹاپ سے ایک معاون کمانڈ ایسی دکھتی ہے، جس میں اکاؤنٹ، میزبان اور پورٹ پلیس ہولڈر سمجھے جاتے ہیں:

ssh -NT -S none -o ExitOnForwardFailure=yes \
  -o PermitRemoteOpen=app.corp.example:443 \
  -R 1080 [email protected]

وہاں تین تفصیلات مفید کام کرتی ہیں۔ -S none سیشن کو مشترکہ کنٹرول ماسٹر سے دور رکھتا ہے، ExitOnForwardFailure آپ کو آدھا کھلا سیشن چھوڑنے کی بجائے جلدی ناکام ہوتا ہے، اور PermitRemoteOpen محدود کرتا ہے کہ دور دراز سننے والا کہاں تک پہنچ سکتا ہے۔ مجاز Pi اکاؤنٹ استعمال کریں اور ان میں سے کچھ بھی شامل کرنے سے پہلے میزبان کی کلید کی تصدیق کریں۔

دور دراز سننے والا واقعی کیا ظاہر کرتا ہے

سننے والے پر انحصار کرنے سے پہلے سرور کی فارورڈنگ پالیسی چیک کریں۔ GatewayPorts no کے ساتھ دور دراز فارورڈنگ loopback سے بندھی رہتی ہے، اور یہی وہ نمائش ہے جو آپ چاہتے ہیں۔ وائلڈ کارڈ فارورڈنگ نافذ کرنے کے لیے ترتیب دیا گیا سرور وہی پورٹ ہر انٹرفیس پر شائع کرتا ہے، جو ایک ذاتی پراکسی کو ایسی چیز بنا دیتا ہے جس تک مقامی نیٹ ورک پہنچ سکتا ہے۔

loopback بھی فی صارف حد نہیں ہے۔ Pi پر کوئی دوسرا عمل اگر پورٹ جانتا ہو تو 127.0.0.1:1080 سے جڑ سکتا ہے، اس لیے Pi کے مقامی اکاؤنٹس اور اس پر چلنے والا سب کچھ آپ کے رسائی ڈیزائن کا حصہ ہیں۔ یہ منزلوں کی فہرست تنگ رکھنے کی وجہ ہے، پالیسی جانچ چھوڑنے کی وجہ نہیں۔

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

ایک ایپلیکیشن کو پراکسی کے ذریعے بھیجیں

Pi پر پراکسی سمجھنے والا کلائنٹ پھر درخواست کر سکتا ہے۔ socks5h سابقہ منزل کا نام پراکسی کو دیتا ہے، اس لیے تلاش اور کنکشن دونوں لیپ ٹاپ کی طرف ہوتے ہیں، اور یہ PermitRemoteOpen میں نامزد منزل سے مطابقت رکھتا ہے:

curl --proxy socks5h://127.0.0.1:1080 \
  --noproxy '' https://app.corp.example/

معمول کی سرٹیفکیٹ تصدیق اور ایپلیکیشن کی اپنی توثیق برقرار رکھیں۔ پراکسی بدلتی ہے کہ TCP کنکشن کہاں بنتا ہے؛ یہ بغیر توثیق کی خدمت کو محفوظ نہیں بناتی اور خود دستخط شدہ اختتامی نقطے کو قابل اعتماد نہیں بناتی۔

لیپ ٹاپ کو اب بھی اپنا راستہ اور SSH سرور اور ایپلیکیشن دونوں تک حل کنندہ رسائی درکار ہے۔ اس کے SSH کلائنٹ کی ٹریفک منظور شدہ VPN پالیسی سے منتخب ہونی چاہیے، اور split-tunnel استثنا اس ٹریفک کو اس راستے سے مختلف راستے پر بھیج سکتا ہے جسے آپ نے آزمایا۔

راستہ ثابت کریں اور اسے بند کریں

تصدیق کریں کہ سننے والا وہیں ہے جہاں آپ توقع کرتے ہیں اور صرف مطلوبہ منزل ہی جواب دیتی ہے:

$ ss -ltnp | grep 1080
LISTEN 0 128 127.0.0.1:1080 0.0.0.0:*
$ curl -sS -o /dev/null -w '%{http_code}\n' \
    --proxy socks5h://127.0.0.1:1080 https://app.corp.example/

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

یہ ترتیب صرف TCP لے کر جاتی ہے۔ UDP، ICMP اور پراکسی ترتیبات نظر انداز کرنے والے پروگرام اس سے باہر رہتے ہیں، اور فارورڈنگ اسی لمحے ختم ہوتی ہے جب SSH سیشن ختم ہوتا ہے۔ کام ختم ہونے پر وہ سیشن روکیں اور ایپلیکیشن میں شامل کی گئی پراکسی ترتیب ہٹا دیں۔

مستقل رسائی کے لیے اس کے بجائے نیٹ ورک کے مالک کی معاون رجسٹریشن یا منظم گیٹ وے استعمال کریں۔ VPN کی ڈیوائس یا وسائل کی پابندیوں سے بچنے کے لیے ریورس پراکسی غلط اوزار ہے؛ ان پابندیوں کے اندر استعمال کیا جائے تو یہ واضح حدود والا صرف ایک مجاز ایپلیکیشن راستہ ہے۔

متعلقہ مضامین