جب میزبان باہر جانے والا VPN چلاتا ہے تو مقامی SSH برقرار رکھیں

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

نیچے دیے گئے مراحل فرض کرتے ہیں کہ منتظم اسی LAN پر ہے۔دور سے انتظام ایک الگ جواب والا الگ مسئلہ ہے۔

SSH کو اُس پتے پر باندھیں جو منتظمین استعمال کرتے ہیں

سننے والے سے شروع کریں۔ss -ltnp | grep :22 دکھاتا ہے کہ sshd کس سے بندھا ہے، اور 0.0.0.0 پر سننے والا سرنگ سمیت ہر انٹرفیس سے رابطے قبول کرتا ہے۔ LAN پتے پر باندھنا زیادہ تنگ ہے اور ارادہ ظاہر کرتا ہے:ListenAddress 192.168.10.20 میں sshd_config، پھر کنفیگریشن جانچ اور دوبارہ لوڈ۔ اُس پتے میں ٹائپو وائلڈ کارڈ سے زیادہ نظر آتا ہے، کیونکہ پتہ نہ ہونے پر sshd شروع ہونے سے انکار کرتا ہے۔

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

LAN راستہ سرنگ سے باہر رکھیں

192.168.10.0/24 پر پتہ رکھنے والے میزبان کے پاس اُس سابقے کے لیے جڑا ہوا راستہ ہوتا ہے، اور اسی جدول میں زیادہ مخصوص راستہ VPN کے طے شدہ کو ہرا دیتا ہے۔ اسی لیے سرنگ اوپر آنے پر مقامی SSH اکثر خود بخود کام کرتا رہتا ہے۔ اندازہ لگانے کے بجائے اس کی تصدیق کریں:ip route get 192.168.10.50 اُس انٹرفیس اور ماخذ پتے کا نام بتاتا ہے جو کرنل استعمال کرے گا، اور جواب سرنگ نہیں بلکہ LAN ڈیوائس ہونا چاہیے۔ منتظم کی مشین سے بھی جانچ دہرائیں، کیونکہ پیکٹ پہنچتے ہیں یا نہیں یہ اُس کا اپنا جدول طے کرتا ہے۔ ایک ہی تار پر دو میزبان اس بات پر متفق نہیں ہو سکتے کہ کون سی سمت قابلِ رسائی ہے۔

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

روٹ شدہ انتظامی VLAN دوسرا معاملہ ہیں۔ اگر منتظم مقامی روٹر کے پیچھے 192.168.50.0/24 پر بیٹھا ہے تو سرور کو اُس سابقے کے لیے 192.168.10.1 کے ذریعے واضح راستہ درکار ہے، اور اُس راستے کو دوبارہ رابطے سے بچنا ہوگا۔ استثنا کو انتظامی سابقے تک مخصوص رکھیں؛ نجی حدود کے لیے وسیع استثنا سرنگ کا مقصد باطل کر دیتا ہے۔

فائر وال استثنا کو اصول جتنا تنگ بنائیں

اگر میزبان پر فائر وال چل رہا ہے تو SSH کو صرف انتظامی ماخذ سے اور صرف LAN انٹرفیس پر اجازت دیں۔ جو اصول 22 پورٹ کو ہر جگہ سے اجازت دیتا ہے وہ ضرورت سے وسیع ہے اور جائزے میں جواز پیش کرنا مشکل ہے۔ nftables میزبان پر اصول اِن پٹ چین میں انٹرفیس اور ماخذ کے مطابق ہوتا ہے؛ iptables میزبان پر متبادل -i اور -s پر دو مماثلتوں کا جوڑا ہے۔ اصول پر اُس منتظم گروپ کی تبصرہ لکھیں جس کی وہ خدمت کرتا ہے، تاکہ اگلے آڈٹ کو اندازہ نہ لگانا پڑے کہ 22 پورٹ کیوں کھلا ہے۔

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

دونوں حالتوں کی جانچ کریں

جانچ دو بار چلائیں: ایک بار سرنگ منسلک ہونے پر اور ایک بار منقطع ہونے پر۔ ہر حالت میں سننے والا، راستہ اور منتظم کی مشین سے حقیقی SSH لاگ اِن کی تصدیق کریں۔ جو راستہ صرف سرنگ کے اوپر رہنے تک کام کرتا ہے وہ مقامی انتظامی راستہ نہیں؛ وہ محض اتفاق ہے۔

پھر SSH سیشن کھلا رہنے کے دوران سرنگ دوبارہ شروع کریں۔ بچ جانے والا سیشن ثابت کرتا ہے کہ روٹنگ مستحکم ہے؛ گرنے والا سیشن بتاتا ہے کہ کلائنٹ دوبارہ رابطے پر راستے یا فلٹر دوبارہ لکھ رہا ہے، جسے واقعے کے دوران نہیں بلکہ پہلے جاننا بہتر ہے۔

جس ماخذ پتے سے آپ نے جانچ کی اسے درج کریں، کیونکہ 192.168.10.50 کے لیے لکھا گیا اصول منتظم کا لیپ ٹاپ دوسرے سب نیٹ میں جانے پر خاموشی سے ناکام ہو جاتا ہے۔

بازیابی کا راستہ runbook میں لکھیں

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

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