DS-Lite اندر آنے والی IPv4 ہوسٹنگ کو روکتا ہے، باہر جانے والی VPN کو نہیں

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

کون سا فریق کنکشن شروع کرتا ہے

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

کنکشنز کا انتظار کرنے والے سرور کے پاس ایسی حالت بنانے کو کچھ نہیں ہوتا۔ باہر سے کسی کو ایسے پتے اور پورٹ تک پہنچنا ہوتا ہے جنہیں نقشہ کرنے پر فراہم کنندہ راضی نہیں ہوا، اور یہ بالکل مختلف درخواست ہے۔

باہر جانے والی درخواست کی پیروی کریں

فنِ تعمیر RFC 6333 دونوں سروں کے نام بتاتی ہے۔ صارف کی طرف کا عنصر B4 ہے، جو IPv4 کو IPv6 کے اندر سمو دیتا ہے۔ فراہم کنندہ کی طرف کا عنصر AFTR ہے، جو پتے کا ترجمہ کرتا ہے اور پیکٹ کو IPv4 کے طور پر آگے بھیجتا ہے۔

Client's IPv4 VPN packet
  → Customer B4
  → IPv4 carried over the provider's IPv6 network
  → AFTR address translation
  → IPv4 VPN server

VPN سرور کو فراہم کنندہ کے مترجم شدہ پتے سے ایک عام IPv4 کنکشن ملتا ہے۔ اسے DS-Lite موڈ، خاص پورٹ یا یہ جاننے کی ضرورت نہیں کہ صارف کا رسائی نیٹ ورک صرف IPv6 ہے۔ لوگ یہی حصہ چھوڑ دیتے ہیں: دوسرا سرا اسے جان نہیں سکتا۔

کلائنٹ کی اپنی ترتیب بھی اتنی ہی عام ہے۔ اسے B4 اور AFTR فراہم کردہ، سرور تک کام کرنے والا IPv4 راستہ چاہیے، اور سرور کا ہوسٹ نام IPv4 پتے میں حل ہونا چاہیے۔

اندر آنے والی ہوسٹنگ ہی ناکام ہونے والا کیس کیوں ہے

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

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

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

رسائی کا منصوبہ بدلنے سے پہلے تشخیص کریں

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

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

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

فراہم کنندہ کی تبدیلیاں غور سے پڑھیں

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

دوہرا اسٹیک فعال کرنے کی ہدایت تب تک مبہم ہے جب تک کوئی تصدیق نہ کرے کہ فراہم کنندہ واقعی کیا فراہم کرتا ہے۔ اسے IPv4 VPN کلائنٹس کے لیے عالمگیر شرط سمجھنا ایک اندازے کو پالیسی بنا دیتا ہے۔

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