کیا آپ SSH کے ذریعے VPN کلائنٹ شروع کر رہے ہیں؟ پہلے اپنا راستہ پن کریں

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

شروع کرنے سے پہلے راستہ ریکارڈ کریں

ip route show default موجودہ گیٹ وے اور انٹرفیس بتاتا ہے، جبکہ ip route get 203.0.113.9 دکھاتا ہے کہ کرنل آپ کے سیشن کے لیے کون سا انٹرفیس اور ماخذ پتہ استعمال کرے گا۔ دونوں آؤٹ پٹ رکھیں۔ ٹنل کے اوپر آنے کے بعد بھی اُن دو کمانڈز کو جسمانی راستہ بیان کرنا چاہیے، اور اگر وہ اس کے بجائے ٹنل بیان کریں، تو سیشن پہلے ہی اُدھار لیے وقت پر جی رہا ہے۔

اہم بات پہلے سے قائم کنکشن ہے، اس لیے صرف نئے لاگ اِن سے تصدیق نہ کریں۔ نیا سیشن کچھ دیر کے لیے اُس حالت سے کامیاب ہو سکتا ہے جو پرانے کے پاس اب نہیں ہے۔

پتہ خود کلائنٹ کی کنفیگریشن میں پن کریں

ہاتھ سے شامل کیا گیا راستہ ری بوٹ پر غائب ہو جاتا ہے اور کلائنٹ کے اپنے جدول کی اپ ڈیٹس سے مقابلہ کرتا ہے، اس لیے استثنا وہاں رکھیں جہاں جدول کا انتظام ہوتا ہے۔ OpenVPN میں net_gateway کلیدی لفظ اُس گیٹ وے میں حل ہوتا ہے جو ٹنل سے پہلے موجود تھا، اس لیے route 203.0.113.9 255.255.255.255 net_gateway اس کے باہر بالکل ایک پتہ رکھتا ہے۔ WireGuard کو مختلف طریقہ درکار ہے کیونکہ wg-quick خود راستوں کا انتظام کرتا ہے: Table = off سیٹ کریں اور استثنا PostUp میں شامل کریں، ساتھ میں اُسے ہٹانے والا مطابق PostDown بھی۔ دونوں شکلیں ایک ہی نیت ظاہر کرتی ہیں، اور دونوں استثنا کو ہر چیز کے لیے ٹنل کمزور کرنے کے بجائے ایک پتے تک محدود رکھتی ہیں۔

IPv6 کے لیے وہی خیال ایک ہوسٹ کا سابقہ لیتا ہے، اور لپٹی ہوئی ترسیل کا معاملہ یاد رکھنے کے قابل ہے: اگر ٹنل کا اپنا بیرونی کنکشن کسی مستقل پتے پر ہے، تو وہ پتہ اُس ٹنل سے باہر ہی رہنا چاہیے جو اُسے اٹھاتا ہے، ورنہ کلائنٹ اپنی ترسیل کو اپنے ہی اندر روٹ کرتا ہے۔

یا مرکزی جدول کو مساوات سے نکال دیں

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

دونوں ایک ہوسٹ راستے سے زیادہ مشینری ہیں، اور دونوں اُس وقت قابلِ قدر ہیں جب مشین پر ایک سے زیادہ چیزوں کو ٹنل سے بچنا ہو۔

فرض کریں کہ پننگ ناکام ہو سکتی ہے

آپ کے موجودہ عوامی پتے سے بندھا راستہ اُس لمحے ٹوٹ جاتا ہے جب آپ کا فراہم کنندہ اُسے دوبارہ تفویض کرتا ہے۔ تب دور دراز سرور کو ایسا راستہ درکار ہوتا ہے جو اُس پتے پر منحصر نہ ہو: ایک کنسول، دوسرا انتظامی انٹرفیس، یا ٹنل سے باہر رہنے والا جمپ ہوسٹ۔

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

اُسی ترتیب سے تصدیق کریں جو اہم ہے

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

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