DHCP کی تجدید کے بعد VPN گرتا ہے؟ پتوں کا موازنہ کریں

لیز کی تجدید اور VPN کی ناکامی لاگز میں اکثر ساتھ دکھائی دیتی ہیں، جس سے لوگ یہ نتیجہ نکالتے ہیں کہ ایک دوسرے کی وجہ ہے۔ وقت کا میل حقیقی ہے؛ سببی تعلق عام طور پر نہیں۔ تجدید اُس سرور کو بھیجی گئی یک پتہ درخواست ہے جس نے لیز جاری کی، کہ وہی بائنڈنگ جاری رکھی جائے، اور سرور کلائنٹ کے ایک بھی پتے کو بدلے بغیر اسے بڑھا سکتا ہے۔ واقعے کے آس پاس کلائنٹ کی اپنی اقدار کا جائزہ خاموشی سے تجدید شدہ لیز کو اُس نیٹ ورک سے الگ کرتا ہے جو چلتی سرنگ کے نیچے واقعی بدلا۔

اُس کلائنٹ سے شروع کریں جو گرا

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

ٹائم لائن یاد رکھنے کے بجائے چلتے چلتے لکھیں۔ مختلف اوزاروں کے ٹائم اسٹیمپ شاذ و نادر ہی پوری طرح ملتے ہیں، اور فرق ہی کبھی کبھی وضاحت ہوتا ہے۔

واقعے کے آس پاس چار اقدار کا موازنہ کریں

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

ip -4 -brief addr show dev wlan0
ip -4 route show default
resolvectl status | grep -A3 'DNS Servers'
journalctl -u NetworkManager --since -10m --no-pager | grep -i dhcp

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

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

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

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

جب کلائنٹ موافق نہ آ سکے

جس کلائنٹ نے اپنی نقل و حمل پرانے پتے سے باندھی، ساتھی تک پرانا راستہ کیش کیا یا انٹرفیس کی شناخت محفوظ رکھی، وہ ایسے راستے پر بار بار کوشش کر سکتا ہے جو اب موجود نہیں۔ یہ موافقت کی خرابی ہے، اور میزبان کی اُس پتے تک نہ پہنچنے والے پتے کی طرف بار بار دوبارہ ترسیل کے طور پر دکھائی دیتی ہے۔ کچھ کلائنٹ اسے ڈیزائن ہی سے سنبھالتے ہیں: مثلاً WireGuard ساتھی کا آخری نقطہ اُس وقت اپ ڈیٹ کرتا ہے جب نئے ماخذ سے درست طور پر تصدیق شدہ پیکٹ آئے۔

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

الزام لگانے سے پہلے واقعہ دہرائیں

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

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