روٹ شدہ VPN پر IPv6 پڑوسیوں کی دریافت کیوں ناکام ہوتی ہے

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

دائرہ کار ترتیب سے پہلے آتا ہے

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

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

جھانسہ یہ گمان ہے کہ سابقہ لنک پر ہے

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

ایک ہی سروس کے لیے /128 سب سے کم حیران کن ترتیب ہے، اور یہ ابہام کو مکمل طور پر دور کر دیتا ہے۔ پڑوسیوں کی دریافت کی تفصیل پیغامات کے مجموعے اور اس کا فیصلہ کرنے والے لنک پر موجود جھنڈے کی وضاحت کرتی ہے۔

پل بندی جان بوجھ کر قواعد بدلتی ہے

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

دریافت نظر آئے اس کے لیے پروفائل کو TUN سے TAP میں بدلنا غلط ترتیب ہے۔ سرور، کلائنٹ اور پتوں کا منصوبہ سب کو متفق ہونا چاہیے، اور موبائل کلائنٹ TAP انٹرفیس بالکل پیش نہیں کرتے، اس لیے ایسا ڈیزائن لیپ ٹاپ پر چلتا ہے اور فون پر ناکام ہوتا ہے۔ پڑوسی پراکسی اور ریلے اپنی ضروریات والے الگ میکانزم ہیں، اور وہ ایپ کی ترتیبات کے نہیں بلکہ نیٹ ورک منتظم کی دستاویزی ترتیب کے ہیں۔

اسی پتے سے جانچیں جو ایپلیکیشن استعمال کرتی ہے

ip -6 route get سے راستے کی تصدیق کریں، ip -6 neigh سے پڑوسی اندراج دیکھیں، پھر روٹ شدہ راستے پر سروس کی تصدیق کریں۔ DNS اور واپسی کا راستہ الگ جانچ ہیں، اور صحت مند پڑوسی اندراج ان میں سے کسی کو ثابت نہیں کرتا۔

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

لکھیں کہ آپ کے پاس کون سا ڈیزائن ہے

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

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