اپنے /64 کو تقسیم کرنا IPv6 کو VPN کلائنٹس تک روٹ نہیں کرتا

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

افسانہ: آپ کے /64 کا ایک حصہ پہلے ہی قابل رسائی ہے

کہانی دلکش ہے: سرور کے پاس عوامی /64 ہے، اسے آدھا کاٹیں، دوسرا آدھا VPN پول کو دیں، اور وہ کلائنٹس اب انٹرنیٹ پر ہیں۔ پریفکس تقسیم کرنا واقعی تصادم کے بغیر پتے مختص کرتا ہے۔ لیکن یہ نہیں بدلتا کہ upstream نیٹ ورک کیسے فیصلہ کرتا ہے کہ ان پتوں میں سے ایک کے لیے پیکٹ کہاں جانا چاہیے۔

IPv6 کے پاس کوئی طے شدہ ترجمہی پرت نہیں جس پر انحصار کیا جا سکے، اس لیے واپسی کا راستہ روٹنگ کے طور پر یا لنک سطح کی ترسیل کے طور پر موجود ہونا چاہیے۔ کسی کلائنٹ کے ٹنل پتے پر بھیجا گیا پیکٹ upstream راؤٹر تک پہنچتا ہے، اور وہ راؤٹر اپنی جدول سے فارورڈنگ کا فیصلہ کرتا ہے۔ اگر جدول جسمانی لنک کی طرف اشارہ کرے تو پیکٹ وہیں جاتا ہے، چاہے آپ کا VPN سرور کچھ بھی سمجھے۔

یہی پوری ناکامی ہے: آگے کی سمت کام کرتی ہے کیونکہ آپ کا سرور اسے بھیجتا ہے، اور واپسی کی سمت ایک ہاپ کے فاصلے پر مر جاتی ہے کیونکہ upstream کو کبھی معلوم نہیں ہوا کہ کلائنٹ موجود ہے۔

لنک پر ترسیل واقعی کیا مانگتی ہے

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

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

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

روٹ کی گئی ترسیل کیا مانگتی ہے

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

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

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

درست کرنے کے لیے دو خودمختار راستے

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

server-ipv6 2001:db8:42:100::/64
push "redirect-gateway ipv6 !ipv4"

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

آپ جو بھی پالیسی لاگو کریں، IPv6 جس کنٹرول ٹریفک پر انحصار کرتا ہے اسے چلتا رکھیں۔ Packet Too Big پیغامات صرف TCP اور UDP کی اجازت دینے والے فائر وال کا روایتی شکار ہیں، اور انہیں گرا دینے سے ایسے کنکشن بنتے ہیں جو قائم ہو کر بڑی منتقلیوں میں رک جاتے ہیں۔

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

ڈیزائن ریکارڈ کریں تاکہ دوبارہ تعمیر اسے دہرا سکے

تین اشیاء الگ الگ لکھیں: کلائنٹ مختص، کلائنٹ کا منزل راستہ، اور مختص کے لیے upstream کی ترسیل کا طریقہ۔ تینوں رکھنے والا قاری تنصیب دوبارہ بنا سکتا ہے؛ صرف پول ترتیب رکھنے والا قاری اصل بگ دہرائے گا۔

پھر واپسی سمت کا واضح طور پر تجربہ کریں، ایسے پیکٹ سے جسے باہر سے واپس آنا ہو۔ openvpn(8) دستی server-ipv6 اور redirect کے اختیارات کا احاطہ کرتا ہے، اور آپ کے فراہم کنندہ کی روٹنگ تصدیق اس نصف کا احاطہ کرتی ہے جو دستی نہیں کر سکتا۔