VPN فعال رہتے ہوئے دوسرے نجی راستے پر SSH

ایک مشین VPN کے ذریعے دوسری تک پہنچتی ہے، اور اب کوئی وہی شیل فراہم کنندہ کے نجی نیٹ ورک پر چاہتا ہے۔ راستہ موجود ہے، پنگ کامیاب ہوتا ہے، پھر بھی SSH انکار کرتا ہے۔ عام وجہ یہ ہے کہ ڈیمون نے نئے پتے پر کبھی سنا ہی نہیں، اس لیے جڑنے کے لیے کچھ نہیں۔ یہ فائر وال کے مسئلے سے پہلے پتہ بائنڈنگ کا مسئلہ ہے۔

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

سننے والا ساکٹ وہ عمل بناتا ہے جو قبول کرنے والے پتوں کے نام بتاتا ہے۔ راستہ صرف پیکٹوں کو بتاتا ہے کہ کہاں جانا ہے؛ یہ منزل پر سننے والا نہیں بناتا۔ جب sshd ایک ListenAddress کے ساتھ ترتیب دیا جاتا ہے، تو انٹرفیس فعال ہونے کے باوجود کسی بھی دوسرے مقامی پتے پر کنکشن مسترد ہوتے ہیں۔ یہی بات پورٹ رکھنے والی ساکٹ یونٹ پر بھی لاگو ہوتی ہے، اسی لیے پہلی جانچ ہمیشہ یہ ہوتی ہے کہ واقعی کون سن رہا ہے۔

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

پتے اور سننے والے شمار کریں

کچھ بھی ترمیم کرنے سے پہلے میزبان پر موجود پتے اور اب موجود ساکٹ درج کریں۔

ip -br addr
ss -ltnp | grep ':22'

پتوں کی فہرست دکھاتی ہے کہ کون سا نجی پتہ حقیقی ہے اور کس انٹرفیس پر، جبکہ ساکٹ فہرست دکھاتی ہے کہ اس سے کچھ بندھا ہے یا نہیں۔ 0.0.0.0:22 پر سننے والا پہلے ہی ہر پتہ قبول کرتا ہے، اس لیے نئی بائنڈنگ کچھ نہیں بڑھاتی۔ ایک مخصوص پتے پر سننے والا انکار کی وجہ فوراً واضح کرتا ہے۔ اگر پورٹ ڈیمون کی نہیں بلکہ ساکٹ یونٹ کی ہے، تو ڈیمون کی ترتیب پوری کہانی نہیں ہے۔

بائنڈنگ شامل کریں اور پرانی رکھیں

OpenSSH کئی ListenAddress اندراجات قبول کرتا ہے، اس لیے نجی راستہ شامل کرتے وقت VPN راستہ رہ سکتا ہے۔ فائل کو دوبارہ لوڈ کرنے سے پہلے جانچیں۔

sshd -t
systemctl reload sshd

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

پرانا سیشن بند کرنے سے پہلے نیا سیشن تصدیق کریں

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

ssh -v [email protected]

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

SSH نقل و حمل کی حفاظت کرتا ہے، لیکن تنہا یہ دو نیٹ ورک برابر نہیں بناتا۔ اس پر انحصار کرنے سے پہلے فیصلہ کریں کہ نجی گزرگاہ کا بھروسا ڈیٹا سے میل کھاتا ہے یا نہیں۔