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

پرانے ٹکڑے آپ کی توجہ سے پہلے ہی غلط تھے۔ کیبل نکالنے نے انہیں صرف نظر آنے لائق بنایا۔

کرنل سے پوچھیں کہ پیکٹ کہاں جائے گا

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

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

ip route show default
ip route get 1.1.1.1
ip route get 10.20.30.40

حل کنندہ بھی مردہ لنک رکھتا ہے

systemd-resolved والے ہوسٹ پر DNS سرور ایک عالمی فہرست کی بجائے لنکوں سے تعلق رکھتے ہیں۔ گر چکی VPN لنک کچھ وقت اپنے سروروں کے ساتھ رجسٹر رہ سکتی ہے، اور پھر ہر تلاش ایسے پتے کا انتظار کرتی ہے جو کبھی جواب نہیں دے گا۔ وہ تاخیر مردہ نیٹ ورک جیسی محسوس ہوتی ہے اور لوگوں کو راستوں کی طرف دیکھنے بھیجتی ہے جبکہ راستہ درست ہے۔

resolvectl status
resolvectl query intranet.example.com

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

رجسٹریشن درست کریں، نہ کہ /etc/resolv.conf۔ موجودہ Ubuntu اور Fedora انسٹال میں وہ راستہ حل کنندہ کی رن ٹائم حالت کا سمبولک لنک ہے، اس لیے ترمیم یا نظر انداز ہوتی ہے یا اگلی نیٹ ورک واقعہ میں دوبارہ لکھ دی جاتی ہے۔

VPN کبھی خود شروع نہیں ہوتا

NetworkManager بنیادی کنکشن کے اوپر VPN اٹھاتا ہے، اور یہ سیکھتا ہے کہ کس کے پیچھے جانا ہے، connection.secondaries اسی بنیاد پر۔ کنکشن سیٹنگز کا حوالہ واضح کہتا ہے کہ VPN پروفائلز کے لیے خودکار کنکشن نافذ نہیں کیا گیا۔ اسی قسم کی خرابی کے پیچھے یہی پوری کارروائی ہے: بنیاد بدلیں، اور VPN کو دوبارہ جوڑنا پڑے گا یا ہاتھ سے دوبارہ فعال کرنا پڑے گا۔

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

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

اپ گریڈ پیغام کے بغیر سیٹنگز گرا سکتا ہے

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

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

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

تین حالتیں، تین مختلف مرمتوں

کچھ بھی چھونے سے پہلے طے کریں کہ آپ کس حالت میں ہیں، کیونکہ ری بوٹ ثبوت مٹا دیتا ہے اور اگلی نیٹ ورک تبدیلی پر خرابی لوٹ آتی ہے۔

What the lookup showsWhat it meansRepair
A default route via a device that exists but is unusedLeftover route from an earlier activationRemove the stale entry, or bounce the profile that installed it
A tunnel device with no client processThe client skipped its cleanupFix the disconnect path, then clear the leftover device state
No tunnel device and no active profileMissing base connection or broken pairingBring up the base, then pair the VPN with it again

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

متعلقہ مضامین