آپ کے IPv6 ٹنل کے دوسرے سرے تک پنگ ناکام ہو رہی ہے؟ :: پتہ چیک کریں

آپ کے IPv6 ٹنل کا ایک سرا دوسرے سرے کو پنگ کرتا ہے، اور جواب ہمیشہ صرف ایک سمت دیتا ہے۔ انٹرفیس اٹھا ہوا ہے، راستہ درست لگتا ہے، اور لاگ میں کوئی چیز اس کی وضاحت نہیں کرتی۔ آپ نے جو پتہ تفویض کیا وہ subnet-router anycast پتہ ہے، جو ہوسٹ پتہ ہی نہیں ہے، اور دو سروں والے لنک پر اس کا ٹھیک ایک ترسیلی ہدف ہوتا ہے: بھیجنے والا۔ کوئی ٹائم آؤٹ قدر اسے درست نہیں کرتی، کیونکہ پتہ وہ نہیں کر رہا جو آپ سمجھتے ہیں۔

وہ علامت جو پتے کی طرف اشارہ کرتی ہے

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

تمام صفر والا شناخت کنندہ anycast کے لیے مخصوص ہے

RFC 4291 تمام صفر والے انٹرفیس شناخت کنندہ کو subnet-router anycast پتے کے طور پر رکھتا ہے، اس لیے 2001:db8:4a::/64 جیسا /64 2001:db8:4a:: پر کوئی قابل استعمال ہوسٹ نہیں رکھتا۔ اس مخصوصیت کی اپنی جگہ ہے: router advertisements اور neighbour discovery اسی شکل کو مخاطب کرتے ہیں اور روٹر اپنے پیش کردہ پریفکس کا جواب دیتا ہے۔ یہ قدر ٹنل کے سرے کو دینا روٹر کا کردار کسی پتے کو سونپنا ہے، اسی لیے کچھ واپس نہیں آتا۔ پریفکس میں کوئی بھی دوسرا شناخت کنندہ ہوسٹ کے طور پر کام کرتا ہے، اس لیے درستی عام طور پر ایک ہندسہ ہوتی ہے۔

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

ہوسٹ پتے تفویض کریں اور پریفکس کو روٹ کریں

دونوں سروں کے لیے ::1 اور ::2 منتخب کریں، ip -6 addr add 2001:db8:4a::2/64 dev tun0 سے ایک اضافہ کریں، اور پھر دور کے پریفکس کو روٹ کریں بجائے اس کے کہ اسے پتہ دینے کی کوشش کریں۔ 2001:db8:4a::/64 کے لیے ٹنل سے باہر راستہ دور کے حصے کو قابل رسائی بناتا ہے؛ پتہ بذات خود صرف مقامی انٹرفیس کو ترتیب دیتا ہے۔

مکمل ٹنل کے لیے تیسرا مرحلہ ہے، ڈیوائس کے ذریعے عالمی unicast کے لیے ڈیفالٹ راستہ، جو سب کچھ ٹنل میں بھیجنے کے IPv6 مساوی ہے۔ اسے چھوڑ دیں تو IPv6 جسمانی لنک استعمال کرتا رہتا ہے جبکہ IPv4 ٹنل کے اندر سفر کرتا ہے، اس لیے ہوسٹ بالکل وہی ٹریفک لیک کرتا ہے جسے آپ ڈھکا ہوا سمجھتے تھے۔ ip -6 route get 2001:4860:4860::8888 سے تصدیق کریں اور جواب فرض کرنے کے بجائے پڑھیں کہ یہ کون سی ڈیوائس بتاتا ہے۔

multicast روٹنگ سے پہلے مسترد ہوتا ہے

Android VpnService.Builder کے لیے پتے اور راستے LinkAddress کے ذریعے جانچتا ہے، اور وہ کنسٹرکٹر multicast کو صریحاً مسترد کر دیتا ہے۔ اسے راستے کے طور پر multicast پریفکس دیں تو نتیجہ راستے کے بجائے bad LinkAddress parameters ناکامی ہوتا ہے، جو توثیق کا جواب ہے نیٹ ورک کا نہیں۔ انکار میڈیم سے مطابقت رکھتا ہے: پوائنٹ ٹو پوائنٹ tun ڈیوائس میں link-layer multicast نہیں ہوتا، اس لیے اس پر گروپ راستے کے پاس نصب کرنے کا کوئی ترسیلی ماڈل نہیں۔ گروپ پتے خود اسٹیک بناتا اور استعمال کرتا ہے، ہاتھ سے ترتیب نہیں دیے جاتے۔

IPv6 all-nodes اور solicited-node پتے اسی قاعدے کے تحت آتے ہیں۔ انٹرفیس انہیں اس لیے اٹھائے رکھتا ہے کہ اسٹیک نے وہاں رکھا، اس لیے نہیں کہ کسی پالیسی نے انہیں ارادہ کیا۔

اس کے بجائے ٹنل کیا لے جا سکتا ہے

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

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

کچھ بھی تفویض کرنے سے پہلے تین جانچیں

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

وہ راستہ جو پلیٹ فارم نے کبھی نہیں لگایا اسے زیادہ دیر انتظار سے ٹھیک نہیں کیا جا سکتا، اور وہ پتہ جو کبھی ہوسٹ نہیں تھا بہتر پنگ سے درست نہیں ہو سکتا۔