دو اپ لنکس کے fe80::1 مشترک ہونے پر IPv6 پالیسی روٹنگ

آپ کے پاس دو اپ لنکس ہیں، اور ip -6 route show دونوں پر ایک ہی اگلی ہاپ چھاپتا ہے: default via fe80::1 dev uplink0 اور default via fe80::1 dev uplink1۔ یہ پتے کے دہرائے جانے کا تصادم نہیں، اور محض اگلی ہاپ fe80::1 کو پالیسی جدول میں نقل کرنا کرنل کو نہیں بتاتا کہ آپ کا مطلب کون سا لنک ہے۔ اصل سوال علامت کے اشارے سے زیادہ تنگ ہے: دوسرے جدول کو ایک لنک چاہیے یا دونوں، اور دوبارہ آغاز کے بعد ان روٹوں کو کیا زندہ رکھتا ہے۔ ترتیب سے جانچی گئی تین شرطیں بیشتر صورتیں حل کر دیتی ہیں۔

وہی fe80::1 دو مختلف پڑوسی ہیں

لنک کے مقامی پتے صرف ایک لنک تک محدود ہیں، اس لیے fe80::1 دو بار چھپا ہوا ایک ہی پتہ نہیں؛ یہ دو پڑوسی ہیں جو اتفاق سے ایک ہی لاحقہ بانٹتے ہیں۔ زون انڈیکس ہی میزبان کا یہ بتانے کا طریقہ ہے کہ کون سا مطلوب ہے، اس لیے fe80::1%uplink0 اور fe80::1%uplink1 کرنل کے لیے مختلف منزلیں ہیں، اور وہ لاحقہ کبھی دور کے روٹر تک نہیں جاتا۔ RFC 4007 اس کے پیچھے کا زون ماڈل بیان کرتا ہے، اور اسی لیے پالیسی جدول کو ہر لنک کے مقامی اگلی ہاپ کے ساتھ آلہ بھی لے کر چلنا پڑتا ہے۔

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

آلہ ہٹا دیں تو روٹ لکھنے کے قابل نہیں رہتا۔ ip -6 route add default via fe80::1 table 200 گیٹ وے حل نہیں کر سکتا، اور iproute2 اسے Error: Nexthop has invalid gateway. غلطی سے مسترد کرتا ہے۔ dev uplink0 شامل کریں تو حکم کامیاب ہوتا ہے، کیونکہ اگلی ہاپ کو ان دو پڑوسیوں میں سے ایک سے باندھنے والا آلہ ہی ہے۔ جو آلہ نہیں بتا سکتا وہ یہ ہے کہ uplink0 اس جدول کے لیے درست لنک ہے یا نہیں، اور دوسرے میزبان سے نقل کیا گیا روٹ اُس میزبان کے انٹرفیس نام ساتھ لے آتا ہے، اصل غلطیاں یہیں سے آتی ہیں۔

شرط ایک: جدول میں ایک لنک یا دو

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

اُس دوسری صورت میں قاعدہ طے کرتا ہے کہ جدول کب دیکھا جائے، اور روٹ طے کرتا ہے کہ پیکٹ کہاں جائے گا:

ip -6 rule add fwmark 0x2 table 201
ip -6 route add default via fe80::1 dev uplink1 metric 100 table 201
ip -6 route add 2001:db8:100::/48 dev uplink1 metric 100 table 201
ip -6 route show table 201

کوئی شے دوسری کا متبادل نہیں، اور صرف ڈیفالٹ رکھنے والا جدول بھی اپنا گیٹ وے حل نہیں کر سکتا۔ اگر اضافہ مسترد ہو، یا روٹ ہو مگر ناقابل استعمال ہو، تو اُس انٹرفیس کا منسلک پریفکس اسی جدول میں رکھیں، یا ہاپ کو onlink سے نشان زد کریں (جب وہ پریفکس کہیں اور روٹ ہو)۔ اوپر کے بلاک میں 2001:db8:100::/48 کوئی من مانا منزل نہیں، بلکہ uplink1 پر وہی منسلک پریفکس ظاہر کرتا ہے۔ fwmark قاعدہ صرف وہ نشان استعمال کرتا ہے جو کسی اور نے لگانا ہو: فارورڈنگ راستے کا nftables یا iptables قاعدہ، یا SO_MARK ساکٹ کا نشان، اس لیے نشان کے ماخذ کے بغیر نقل شدہ بلاک کسی چیز سے نہیں ملتا۔

شرط دو: میٹرک مردہ فراہم کنندہ کو نہیں پکڑتے

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

جدول بننے کے بعد انتخاب کی تصدیق کریں، اور اُسی طرح کریں جیسے کرنل اسے دیکھے گا۔ ip -6 route get 2001:db8:100::1 وہ روٹ چھاپتا ہے جو استعمال ہوتا، جس میں آلہ اور منتخب ماخذ پتہ شامل ہیں، اور یہ پالیسی قواعد کا احترام کرتا ہے۔ غلط اپ لنک کا ماخذ پتہ عام طور پر اس بات کا اشارہ ہے کہ قاعدہ آپ کی توقع سے پہلے مل گیا۔

شرط تین: طے کریں کہ استحکام کا مالک کون ہے

روٹ ip -6 route add کے ذریعے شامل کیا گیا روٹ دوبارہ آغاز تک یا جب تک کوئی اسے صاف نہ کرے قائم رہتا ہے۔ روٹر اعلانات سے سیکھا گیا ڈیفالٹ عمر رکھتا ہے اور روٹر اسے واپس لے سکتا ہے، جبکہ ہاتھ سے شامل کیا گیا ڈیفالٹ کبھی خود ختم نہیں ہوتا۔ دونوں کو ایک جدول میں ملانا ہی وہ طریقہ ہے جس سے پرانا مستقل روٹ نئے اعلان شدہ سے آگے نکلنے لگتا ہے، اُس اپ لنک کے بہت عرصہ بعد بھی جو اُس نے بیان کیا تھا۔

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

ip -6 route flush table 201
ip -6 rule del fwmark 0x2 table 201

دوسرے میزبانوں کے لیے فارورڈ کرنے والے روٹر پر، جدول کو قصوروار ٹھہرانے سے پہلے net.ipv6.conf.all.forwarding دیکھیں۔ اگر فارورڈنگ بند ہو تو دوسرے نیٹ ورک کے لیے پتہ شدہ پیکٹ جدول 201 کتنا ہی درست ہو، پھینک دیے جاتے ہیں۔

ڈیزائن درج کریں تاکہ اگلا شخص اس کا آڈٹ کر سکے

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

جدول کو مکمل کہنے سے پہلے، پڑوسی کی ip -6 neigh show dev uplink0 سے تصدیق کریں، ip -6 rule show دوبارہ پڑھیں — ترتیب کے حادثات کے لیے، اور ڈیفالٹ روٹ لینے والے ping کی بجائے قاعدے سے ملنے والے ٹریفک سے جانچیں۔ پھر ایک اپ لنک جان بوجھ کر بند کریں اور دیکھیں کرنل کس روٹ پر واپس جاتا ہے؛ جواب آپ کے لکھے ہوئے سے ملنا چاہیے۔