IPv6 برانچ سابقہ: سرور پر iroute-ipv6 یا route-ipv6؟

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

دو ہدایات، دو مختلف کام

route-ipv6 ایک عام روٹ کی تنصیب ہے: سرور ایک کرنل روٹ شامل کرتا ہے جو سابقے کو اپنے ٹنل انٹرفیس کی طرف اشارہ کرتا ہے۔ iroute-ipv6 کسی مخصوص کلائنٹ کے سیاق سے تعلق رکھتی ہے اور اندرونی ملکیت کا اعلان کرتی ہے، تاکہ ڈیمن جان لے کہ اس سابقے کی ٹریفک کو کسی خاص کلائنٹ کو بھیجنا چاہیے نہ کہ اس پیر کو جسے کرنل روٹ اتفاقاً نام دیتا ہے۔

ایک کرنل کے فارورڈنگ ٹیبل سے متعلق ہے، دوسری ڈیمن کے اندرونی روٹنگ ماڈل سے۔ انہیں الگ رکھنا بتاتا ہے کہ مکمل دکھنے والی کنفیگریشن بھی سابقہ کیوں گرا سکتی ہے۔ یہ بھی بتاتا ہے کہ وہی نیٹ ورک ہر کام کرنے والی مثال میں دو بار کیوں آتا ہے۔ دونوں سطروں میں سے کوئی بھی زائد نہیں۔

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

ip -6 route show | grep fd00:7a
ip -6 route get fd00:7a::1

کون کہاں جاتا ہے

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

ایسا فائل نام جو اصل شناخت سے نہ ملے کبھی نہیں پڑھا جاتا، اور علامت بالکل غائب iroute جیسی ہوتی ہے۔ وہ شناخت دیکھیں جو سرور نے تصدیق کی، پھر فائل کا نام حرف بہ حرف دیکھیں۔

# /etc/openvpn/server/server.conf
route-ipv6 fd00:7a::/64
client-config-dir /etc/openvpn/server/ccd

# /etc/openvpn/server/ccd/branch-b
iroute-ipv6 fd00:7a::/64

پول اور برانچ سابقے کو الگ رکھیں، کیونکہ ان کا اوورلیپ ایسی پہیلی بناتا ہے جسے کوئی ہدایت حل نہیں کر سکتی۔

دوسرے کلائنٹ کو کیا چاہیے

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

اسے خود برانچ کو نہ بھیجیں، کیونکہ اس ڈیوائس کے پاس سابقہ پہلے سے منسلک نیٹ ورک کے طور پر موجود ہے۔

اسے سب کو بھیجنا نتائج والا انتخاب ہے: پھر ہر کلائنٹ سمجھتا ہے کہ برانچ ٹنل سے قابلِ رسائی ہے، ان کلائنٹس سمیت جنہیں آپ نے کبھی یہ رسائی دینا نہیں چاہی تھی۔ اعلان عملاً رسائی کا فیصلہ ہے، اگرچہ ہدایت پلمبری کے کام جیسی لگتی ہے۔ سرور اختیارات کا حوالہ iroute-ipv6 کو کلائنٹ مخصوص ملکیت کے طور پر دستاویز کرتا ہے، اور یہی وہ فرق ہے جسے رکھنا قابلِ قدر ہے۔

برانچ ڈیوائس پر واپسی کا راستہ

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

وہ واپسی کا راستہ IPv6 میں اس گمشدہ روٹ مسئلے کا ہم منصب ہے جس کا سامنا لوگ IPv4 میں کرتے ہیں۔

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

جب جوڑا اب بھی کافی نہ ہو

کچھ تعیناتیاں یہ راستہ بالکل استعمال نہیں کرتیں۔ کرنل کا ڈیٹا راستہ اور پروڈکٹ کے زیرِ انتظام سرورز اپنی معاون روٹ ہینڈلنگ رکھتے ہیں، اور userspace کی مثال براہِ راست منتقل نہ ہو سکے۔

دوسرے کے لیے لکھی گئی گائیڈ سے ہدایات نقل کرنے سے پہلے تصدیق کریں کہ آپ کا بلڈ کون سا ڈیٹا راستہ استعمال کرتا ہے۔

اور آخر میں، پتوں کے دائرے کو یاد رکھیں: منفرد مقامی سابقہ جیسے fd00:7a::/64 ڈیزائن کے لحاظ سے نجی ہے اور عوامی IPv6 رسائی کے بارے میں کچھ نہیں کہتا۔ اسے اندرونی رسائی سمجھیں، اور انٹرنیٹ سے باہر جانے کو اپنی پالیسی والا الگ معاملہ رکھیں۔