OpenVPN لیب میں نجی IPv6 شامل کریں، ایک وقت میں ایک چیک پوائنٹ

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

پہلا چیک پوائنٹ: وہ کنکشن جو پہلے سے کام کرتا ہے

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

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

دوسرا چیک پوائنٹ: اندرونی سابقے منتخب کریں

سائٹ کے لیے ایک ULA /48 منتخب کریں اور اس میں سے دو /64 کاٹیں: ایک سرنگ کلائنٹس کے لیے، ایک اس LAN حصے کے لیے جس میں IPv6 ورک لوڈ ہے۔ مثال کا سابقہ نقل کرنے کے بجائے 40 بٹ عالمی ID بنائیں، اور دونوں ذیلی نیٹ کو ہر اس نیٹ ورک کے ساتھ جانچیں جسے سائٹ پہلے سے روٹ کرتی ہے:

Outer transport: IPv4 OpenVPN UDP
IPv4 pool:       10.90.0.0/24
IPv6 VPN pool:   fd73:93bc:b6e9:77::/64
IPv6 LAN:        fd73:93bc:b6e9:60::/64
Server LAN IPv6: fd73:93bc:b6e9:60::1

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

تیسرا چیک پوائنٹ: مددگار اور روٹ پش شامل کریں

کچھ بھی شامل کرنے سے پہلے موجودہ سرور کنفیگریشن پڑھیں۔ موجودہ ہدایت کی دوسری نقل پہلی کے ساتھ ضم نہیں ہوتی، اور آنے والی غلطی IPv6 نہیں ہدایت کا نام لیتی ہے۔ موجودہ IPv4 مددگار کے ساتھ دو سطریں اسے بڑھاتی ہیں۔ ہر ایک الگ سوال کا جواب دیتی ہے:

server-ipv6 fd73:93bc:b6e9:77::/64
push "route-ipv6 fd73:93bc:b6e9:60::/64"

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

مددگار مستقل IPv6 پول یا nopool کے ساتھ اکٹھا نہیں رہتا۔ اگر تعیناتی جان بوجھ کر پتے مستقل طور پر تقسیم کرتی ہے تو وہ پالیسی رکھیں اور مثال کے مطابق بنانے کے لیے پالیسی ہٹانے کے بجائے IPv6 مساوی کو واضح طور پر ڈیزائن کریں۔

چوتھا چیک پوائنٹ: آگے بھیجنا اور جواب کا راستہ

سرور پر IPv6 آگے بھیجنا نظام کے اپنے کنفیگریشن مالک کے ذریعے چالو کریں، نہ کہ ایک بار کی رن ٹائم تحریر سے جو آپ بھول جائیں گے۔ رن ٹائم شکل تیز جانچ کے لیے مفید ہے۔ مستقل کنفیگریشن تقسیم کے نیٹ ورک مالک کی پڑھی جانے والی drop-in فائل میں ہوتی ہے:

sysctl -w net.ipv6.conf.all.forwarding=1

آگے بھیجنا پیکٹ روٹ کرنے سے بڑھ کر میزبان کے IPv6 رویے کو بدلتا ہے۔ جو میزبان بطور کلائنٹ راؤٹر اعلانات قبول کرتا تھا وہ آگے بھیجنا شروع کرتے ہی اسی طرح قبول کرنا بند کر دیتا ہے۔ اس لیے جس مشین کا IPv6 اپ لنک RA پر منحصر ہے اسے اس اپ لنک کے لیے واضح منصوبہ درکار ہے۔

پھر LAN کو سرنگ پول کی طرف واپسی کا راستہ دیں۔ ورک لوڈ کا IPv6 گیٹ وے VPN سرور نہیں LAN راؤٹر ہے، اس لیے راستہ اسی راؤٹر پر ہے اور سرور کے LAN پتے کی طرف اشارہ کرتا ہے:

ip -6 route add fd73:93bc:b6e9:77::/64 via fd73:93bc:b6e9:60::1

لنک کو درکار ICMPv6 اقسام، راستہ-MTU رائے سمیت رکھیں۔ IPv4 فائر وال قاعدہ IPv6 قاعدہ نہیں ہے، اور IPv6 کی مکمل بندش ہمسایہ کی کھوج کو راستہ خرابی جیسا دکھائی دینے والے انداز میں توڑ دیتی ہے۔

پانچواں چیک پوائنٹ: کلائنٹ پڑھیں، پھر جانچیں

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

ip -6 addr show tun0
ip -6 route get fd73:93bc:b6e9:60::20

سرنگ منتخب کرنے والا راستہ ثابت کرتا ہے کہ کلائنٹ جانتا ہے پیکٹ کہاں بھیجنا ہے۔ یہ ثابت نہیں کرتا کہ سرور اسے آگے بھیجتا ہے، LAN راؤٹر کے پاس واپسی راستہ ہے، یا ایپلیکیشن کو جواب دینے کی اجازت ہے۔

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

AAAA ریکارڈ صرف اس وقت شائع کریں جب IPv6 راستہ شروع سے آخر تک جواب دے۔ IPv4 پر پوچھا گیا DNS اب بھی IPv6 پتہ لوٹا سکتا ہے، اس لیے حل ہونے والا نام اس بات کا ثبوت نہیں کہ کوئی چیز سن رہی ہے۔ RFC 4193 ULA رہنمائی ان سابقوں کو نقل کے بجائے آپ کا بنانے والے عالمی ID کی تخلیق کا احاطہ کرتی ہے۔