IPv4 VPN سرور کے ذریعے IPv6 کو پھر بھی حقیقی IPv6 ایگزٹ درکار ہے

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

علامت: پتہ ہے، راستہ نہیں

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

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

انکیپسولیشن کھلنے کے بعد پیکٹ کا پیچھا کریں

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

IPv4 پر IPv6 کے انکیپسولیشن کی میکانیات RFC 4213 میں بیان کی گئی ہے، اور وہاں کی اہم تفصیل یہ ہے کہ سروں کو ٹنل کے دوسری طرف اب بھی حقیقی IPv6 رابطہ درکار ہے۔ ہیڈر لپیٹنے سے upstream جادو سے پیدا نہیں ہوتا۔

ٹنل کی دو تہیں، دو خودمختار جانچیں

ہر تہہ کو الگ الگ جانچیں، کیونکہ چلتی بیرونی ٹنل ٹوٹی اندرونی ٹنل چھپا دیتی ہے۔ بیرونی راستہ کلائنٹ سے سرور تک IPv4 پنگ سے جانچیں اور جو پورٹ آپ استعمال کرتے ہیں اس کی تصدیق کریں۔ پھر سرور پر اندرونی راستہ جانچیں، جہاں ip -6 route کوئی ڈیفالٹ یا حقیقی upstream سے سیکھا ہوا مخصوص راستہ دکھنا چاہیے، اور ip -6 addr کوئی ایسا ماخذ سابقہ دکھنا چاہیے جو upstream قبول کرتا ہو۔ اس سے کم کچھ بھی انٹرفیس پر محض سجاوٹ ہے۔

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

یہی بات کلائنٹ پر بھی لاگو ہوتی ہے: ip -6 route get 2001:4860:4860::8888 ٹنل ڈیوائس کا نام بتانا چاہیے، اور اگر جسمانی ڈیوائس کا نام بتائے تو کلائنٹ IPv6 کے لیے VPN بالکل استعمال نہیں کر رہا۔

ماخذ سابقہ، حجم اور ICMPv6

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

آپ کا اسٹیک واقعی جو اضافی انکیپسولیشن استعمال کرتا ہے اس کے لیے بجٹ رکھیں، اور ICMPv6 کو Packet Too Big سمیت چلتا رکھیں۔ دوسرا ہیڈر قابلِ استعمال پے لوڈ کم کرتا ہے، اس لیے چھوٹی پنگ کا جواب دینے والا راستہ فائل منتقلی میں پھر بھی ناکام ہو سکتا ہے، اور تمام ICMPv6 پھینکنے والا فائر وال قابلِ اصلاح حجم کے مسئلے کو سیاہ شگاف میں بدل دیتا ہے۔ سروس کا اعلان کرنے سے پہلے ایک بڑی منتقلی آزمائیں۔

کون سی چیز بالکل مختلف مسئلہ ہے

صرف IPv4 چلانے والی ایپلیکیشن تک صرف IPv6 چلانے والے کلائنٹ سے پہنچنا ترجمہ ہے، ٹنل نہیں، اور اس کے لیے جان بوجھ کر تعینات کی گئی NAT64 جیسی ترتیب چاہیے۔ منزل صرف اس لیے اضافی ٹنل ہیڈر نہیں سمجھے گی کہ آپ نے ایک اضافہ کیا۔ تاریخی منتقلی خدمات بھی اتنی ہی توجہ کی مستحق ہیں: RFC 7526 نے 6to4 anycast ریلے ماڈل کو منسوخ کیا، لہٰذا اس کے گرد لکھی گئی رہنمائی ایسی چیز بیان کرتی ہے جس کے پاس اب کوئی برقرار رکھا گیا عوامی ریلے نہیں ہے۔

اگر سرور کے پاس قابلِ استعمال IPv6 upstream نہیں ہے تو اختیارات ہیں معاون upstream، کوئی دوسرا ایگزٹ، یا یہ دستاویزی فیصلہ کہ IPv6 ٹنل سے باہر رہے گا۔ ناقابلِ قبول وہ ہے کہ کلائنٹس کو بتایا جائے کہ IPv6 سروس موجود ہے، جبکہ ان کا عام IPv6 کنکشن خاموشی سے VPN کو نظرانداز کر رہا ہو۔