جب اسپلٹ ٹنل کے راستے اوورلیپ ہوں: کون سا سابقہ جیتتا ہے

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

1. منزل اور ماخذ لکھیں

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

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

2. کرنل سے پوچھیں کہ کون سا راستہ چنا

روٹ جدول پڑھ کر جواب کا اندازہ نہ لگائیں۔ وہی سوال پوچھیں جو اسٹیک پوچھتا ہے، اسی ماخذ پتے کے ساتھ: Linux پر ip route get 10.20.4.10 from 10.8.0.2، یا PowerShell میں Find-NetRoute -RemoteIPAddress 10.20.4.10۔ آؤٹ پٹ اُس راستے کا نام بتاتا ہے جو واقعی استعمال ہوگا، اور وہ اکثر وہ نہیں ہوتا جس کی جدول پڑھتے وقت آپ نے توقع کی تھی۔

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

3. جانچیں کہ کسی پالیسی قاعدے نے تلاش کو کہیں اور موڑا

روٹ جدول دیکھے جانے سے پہلے کرنل اپنے پالیسی قواعد سے گزرتا ہے۔ کوئی قاعدہ کسی دیے گئے ماخذ، صارف یا فائر وال نشان کی ٹریفک کو بالکل کسی دوسرے جدول میں بھیج سکتا ہے، اس لیے مرکزی جدول کا جیتنے والا سابقہ اس بہاؤ کے لیے کبھی نہ دیکھا جائے۔ ip rule show انہیں تشخیصی ترتیب میں فہرست کرتا ہے، اور ip route show table 100 دکھاتا ہے کہ منتخب جدول میں واقعی کیا ہے۔

یہاں دو جال ہیں۔ خالی جدول کی طرف اشارہ کرنے والا قاعدہ ایسی تلاش بناتا ہے جو اگلے قاعدے پر گر جاتی ہے، اس لیے قاعدہ کچھ نہ کرتا نظر آتا ہے۔ دوسرا جال ترجیحی نمبر بذات خود ہے: قواعد بڑھتی ترتیب میں پڑھے جاتے ہیں، اور اندرونی اقدار 0 local، 32766 main اور 32767 default ہیں۔ 32767 سے کم نمبر والا قاعدہ سب کچھ پکڑنے والے طے شدہ قاعدے سے پہلے دیکھا جاتا ہے۔ 32767 سے زیادہ نمبر والا قاعدہ اس کے پیچھے بیٹھتا ہے اور تبھی پہنچتا ہے جب پہلے کا کوئی جدول جواب نہ دے، جسے main میں عام طے شدہ راستہ روکتا ہے، اس لیے عملاً وہاں کبھی نہیں پہنچا جاتا اور نصب دکھائی دیتے ہوئے خاموشی سے کچھ نہیں کرتا۔ اگر کلائنٹ نے قاعدہ اور راستہ دونوں لکھے ہیں تو دونوں جانچیں، اور دوبارہ جڑنے کے بعد پھر جانچیں، کیونکہ دوبارہ لکھی گئی پروفائل مختلف ترجیح والا دوسرا قاعدہ شامل کر سکتی ہے۔

4. راستوں کی برابری کو دہرائے گئے پتے کے منصوبے سے الگ کریں

کبھی کبھی سابقہ بالکل مسئلہ نہیں ہوتا۔ دونوں مقامات کا 192.168.1.0/24 استعمال کرنا مطلب یہ ہے کہ ایک ہی پتہ دو مختلف میزبانوں کی نشاندہی کرتا ہے، اور کوئی راستہ انہیں الگ نہیں کر سکتا۔ دو جوابات میں سے ایک کی طرف میزبان کا راستہ تب تک ہی کام کرتا ہے جب تک دوسرا مقام اسی نام کا جواب نہ دے، اور پھر استثنا خاموشی سے خود خرابی بن جاتا ہے۔

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

5. تصدیق کریں کہ حل کنندہ راستے سے متفق ہے

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

حل کنندہ سے براہ راست پوچھیں اور جواب دینے والے سرور کو نوٹ کریں۔ کم TTL والا کیش جواب یہ بھی سمجھا سکتا ہے کہ دوبارہ جڑنے کے بعد پہلی درخواست پانچویں سے مختلف کیوں برتاؤ کرتی ہے۔

6. دوبارہ جڑیں، نافذ حالت دیکھیں، پھر دونوں بہاؤ جانچیں

درستی کے بعد دوبارہ جڑیں اور پروفائل ایڈیٹر پر بھروسہ کرنے کے بجائے دیکھیں کہ کلائنٹ نے واقعی کیا نصب کیا۔ قواعد، جدول اور اس سے بننے والا ip route get جواب دوبارہ پڑھیں۔ دوسرا کلائنٹ جڑتے وقت اپنا راستہ دوبارہ نصب کر سکتا ہے اور تصادم پھر بنا سکتا ہے، اس لیے حالت کی جانچ آخری کلائنٹ کے جڑنے کے بعد ہونی چاہیے، اس سے پہلے نہیں۔

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