VPN کہتا ہے منسلک ہے مگر کچھ روٹ نہیں ہوتا: دیکھنے کی دو جگہیں

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

پہلے kernel سے پوچھیں کہ کون سا آلہ استعمال کرے گا

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

دوسرا کیس عام طور پر تب ہوتا ہے جب کیبل بے تار کی جگہ لے، اور یہ خود کو خراب VPN کے طور پر پیش کرتا ہے۔

ip route show default
ip route get 203.0.113.9

اس کے بعد ڈیفالٹ اندراجات پڑھیں، کیونکہ پچھلے بنیادی کنکشن کا شامل کردہ روٹ link کی تبدیلی سے زیادہ زندہ رہ سکتا ہے اور نئے کے آگے کھڑا ہو سکتا ہے۔ بند آلے کے ذریعے ڈیفالٹ روٹ کسی بھی ڈیفالٹ روٹ کے نہ ہونے سے بدتر ہے، کیونکہ kernel اب بھی اسے ترجیح دیتا ہے۔ ہر اندراج کے ساتھ میٹرک دیکھیں، کیونکہ وہ ترتیب interface کے ناموں سے زیادہ تیزی سے ترجیح کی وضاحت کرتی ہے۔

پھر resolver ہر link کے لیے پڑھیں، نہ کہ ہر فائل کے لیے

ناموں کا حل اپنی حالت اور اپنی پرانی ہونے کی حالت ساتھ رکھتا ہے۔ resolver جو ہر link کے لیے DNS سرور درج کرتا ہے، ایسے ٹنل link کے سرور رکھے رہتا ہے جو بند ہے مگر اب بھی رجسٹرڈ ہے، اور ہر تلاش پھر ایسے سرور کا انتظار کرتی ہے جو جواب نہیں دے گا۔ علامت ایسا نیٹ ورک ہے جو مردہ محسوس ہوتا ہے جبکہ روٹ ٹیبل بے عیب دکھائی دیتا ہے۔

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

resolvectl status
resolvectl query app.internal.example

اگر پتے حل ہوں اور کنکشن ناکام ہوں، resolver ٹھیک ہے اور روٹ نہیں۔ اگر پتے بالکل حل نہ ہوں، تو شروع کرنے کی درست جگہ یہی ہے۔

پرانا روٹ تبدیلی سے کیسے بچتا ہے

کلائنٹ اکیلا نیٹ ورک کا مالک نہیں ہوتا۔ NetworkManager والے میزبان پر VPN پروفائل بنیادی کنکشن کے اوپر فعال ہوتا ہے، اور کنکشن کی ترتیبات اس بنیاد کو اجازت دیتی ہیں کہ وہ اس VPN کا نام لے جسے اس کی پیروی کرنی چاہیے۔ جب بنیاد اس لیے بدلے کہ کوئی دوسرا پروفائل ترجیحی ہو جائے، ٹنل نئی بنیاد پر چلا جاتا ہے یا کسی کے بغیر رہ جاتا ہے۔

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

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

nmcli device status
nmcli connection show --active
nmcli connection up office-vpn

پرانی حالت کو غائب والد سے الگ پہچانیں

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

دوبارہ شروع کرنا چھپا دیتا ہے کہ تینوں میں سے کون سی حالت آپ کے پاس تھی، اور یہی وجہ ہے کہ یہ مرمت جیسا لگتا ہے۔

مرمت کے بعد kernel سے ایک عوامی اور ایک داخلی پتہ مانگیں، پھر کوئی داخلی نام تلاش کریں۔ جب پتہ کام کرے اور نام نہ، تو آپ نے resolver میں ڈومین کی حد کا مسئلہ پایا ہے نہ کہ روٹنگ کا۔ نوٹ کریں کہ کون سی حالت ملی، کیونکہ اگلی نیٹ ورک تبدیلی وہی دہرائے گی جو آپ نے چھوڑ دی تھی۔