ٹنل اب بھی قائم ہے، راستہ گیا: دو VPN ناکامیوں کو الگ کرنا

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

ایک ہی واقعہ جیسے لگنے والے تین مراحل

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

اسی لیے پہلا سوال یہ ہے کہ کون سا مرحلہ ٹوٹا، نہ کہ کون سا پروٹوکول قصوروار ہے۔ جواب طے کرتا ہے کہ واقعہ کس کا ہے اور اگلی جانچ کون سا اوزار استعمال کرے گی۔

پہلے نصب شدہ راستہ پڑھیں

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

ip route get 10.20.5.10
ip route show 10.20.0.0/16

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

پھر پروٹوکول کا اپنا نظریہ دیکھیں

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

vtysh -c "show bgp summary"
vtysh -c "show bgp ipv4 unicast 10.20.0.0/16"

خلاصہ بتاتا ہے کہ سیشن قائم ہے یا نہیں، سابقے کے مطابق منظر بتاتا ہے کہ سابقہ قبول ہوا یا نہیں، اور کرنل کی تلاش بتاتی ہے کہ وہ نصب ہوا یا نہیں۔ انہیں اسی ترتیب میں پڑھنا سیشن کی تھرتھراہٹ کو واپس لینے اور واپس لینے کو پالیسی کی بنیاد پر مسترد ہونے سے خلط ملط ہونے سے روکتا ہے۔

جب گھڑیاں متفق نہ ہوں

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

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

لوپ کے بغیر بحالی

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

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