SSH فارورڈنگ دراصل کس ایپ کی ٹریفک لے جاتی ہے؟

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

کسی چیز کا موازنہ کرنے سے پہلے انٹرفیس کا نام لیں

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

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

ان میں سے کوئی بھی راستہ نصب نہیں کرتا۔ ایسا پروگرام جو پراکسی کی ترتیبات کو نظر انداز کرتا ہے، یا UDP بولتا ہے، یا نام خود حل کرتا ہے، وہ فعال SSH سیشن سے متاثر نہیں ہوتا۔ یہ SSH میں کوئی خرابی نہیں؛ یہ آپ کے منتخب کردہ انٹرفیس کی حد ہے۔

مقامی، دور دراز اور متحرک فارورڈنگ اس بات میں مختلف ہیں کہ کون سنتا ہے

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

ssh -N -L 5432:db.internal.example:5432 [email protected]
ssh -N -D 1080 [email protected]
ss -ltnp | grep -E '5432|1080'

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

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

ٹنل ڈیوائس موڈ ہی واحد حقیقی نیٹ ورک استثنا ہے

OpenSSH -w ٹنل ڈیوائس فارورڈنگ کی بھی حمایت کرتا ہے، جو TCP سننے والے کی بجائے نقطہ بہ نقطہ انٹرفیس گزرتی ہے۔ یہ حقیقی نیٹ ورک ٹنل ہے، اور یہ جان بوجھ کر ترتیب دی جاتی ہے، شیل کھولنے کا ضمنی اثر نہیں۔

sudo ssh -w 0:0 [email protected]
ip addr show tun0

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

پھر بھی ٹنل دور دراز میزبان پر ختم ہوتی ہے۔ SSH نقل و حمل نے جو بھی تحفظ دیا وہیں ختم ہوتا ہے، اور اگلا رابطہ الگ چھلانگ ہے۔ VPN گیٹ وے کی سرحد بھی وہی شکل رکھتی ہے، اسی لیے موازنہ دائرے اور اختتام کے بارے میں ہونا چاہیے، نہ کہ اس بارے میں کہ کون سا آلہ زیادہ مضبوط ہے۔ اس سرحد کا بلند آواز میں نام لینا اس بحث کو بھی طے کرتا ہے کہ آیا ٹنل «سب کچھ انکرپٹ کرتی ہے»، کیونکہ واضح طور پر نہیں کرتی۔

جانچیں کہ آپ کی ایپ آپ کے بنائے ہوئے انٹرفیس کو استعمال کرتی ہے

تصدیق ہر ایپ کے لیے ہے، سیشن کے لیے نہیں۔ کام کرنے والی فارورڈنگ ثابت کرتی ہے کہ پورٹ بندھا ہوا ہے اور دور کا سرا ڈائل کر سکتا ہے؛ یہ ثابت نہیں کرتی کہ آپ کے لیے اہم پروگرام اس کے ذریعے جڑا۔

curl -sS --socks5-hostname 127.0.0.1:1080 -o /dev/null -w '%{http_code}\n' https://app.internal.example/health
psql "host=127.0.0.1 port=5432 dbname=app sslmode=require" -c 'select 1'

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

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