OpenVPN ٹنل کے ذریعے IPv6: گھریلو راؤٹر کا مرحلہ وار جائزہ

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

وہیں سے شروع کریں جہاں کلائنٹ ہے

سرور کو چھونے سے پہلے کلائنٹ دیکھیں۔ ip -6 addr کو پول سے ٹنل کا پتہ دکھانا چاہیے، اور ip -6 route کو ٹنل ڈیوائس کی طرف اشارہ کرنے والا دھکیلا گیا سابقہ دکھانا چاہیے۔ جب پتہ ہو مگر راستہ نہ ہو، تو دھکیلنا غائب ہے یا کلائنٹ نے اسے نظرانداز کیا۔ جب دونوں میں سے کوئی نہ ہو، سرور نے بالکل کچھ مختص نہیں کیا۔

پھر دیکھیں کہ کلائنٹ باہر کی دنیا کے بارے میں کیا سمجھتا ہے۔ ٹنل پر ڈیفالٹ راستہ تمام IPv6 ٹریفک کا دعویٰ کرتا ہے، جبکہ 2000::/3 کے لیے راستہ صرف عالمی یونیکاسٹ کا دعویٰ کرتا ہے۔ دونوں درست ہو سکتے ہیں، اور وہ رساؤ کے بارے میں مختلف سوالوں کے جواب دیتے ہیں۔

بغیر کسی IPv6 ڈیفالٹ والا کلائنٹ ہر عوامی جانچ میں ناکام ہوتا ہے جبکہ ٹنل خود بالکل صحت مند ہے۔ یہ پالیسی کا خلا ہے، ٹوٹی ہوئی ٹنل نہیں۔

وہ پول جانچیں جسے سرور واقعی روٹ کر سکتا ہے

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

پول اور دھکیلنا ساتھ چلتے ہیں۔ server-ipv6 2001:db8:80:10::/64 پتے مختص کرتا ہے، اور push "route-ipv6 2000::/3" کلائنٹس کو بتاتا ہے کہ ٹنل میں کیا بھیجنا ہے۔ 2000::/3 دھکیلنا عالمی یونیکاسٹ کو ڈھانپتا ہے اور link-local اور multicast حدود کو ٹنل سے باہر رکھتا ہے۔

منتخب سابقہ تعیناتی ریکارڈ میں لکھیں۔ اگلی بار ISP کی حوالگی بدلنے والے کو جاننا ہوگا کہ ٹنل کون سا /64 پہلے سے لے رکھی ہے۔

دوسرے خاندان کے لیے فارورڈنگ آن کریں

IPv4 فارورڈنگ کا مطلب IPv6 فارورڈنگ نہیں ہے۔ net.ipv6.conf.all.forwarding=1 سیٹ کریں اور وہ سب کچھ دہرائیں جس کی IPv4 FORWARD پالیسی پہلے سے اجازت دیتی ہے۔ جس راؤٹر کی FORWARD زنجیر ڈیفالٹ طور پر گرا دیتی ہے، وہاں قواعد کا مجموعہ غائب ہونا بالکل مردہ ٹنل جیسا لگتا ہے۔

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

ip6tables -A FORWARD -i br0 -o tun0 -j ACCEPT
ip6tables -A FORWARD -i tun0 -o br0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
ip6tables -A FORWARD -i tun0 -o wan0 -j ACCEPT

ایک ضمنی اثر ان لوگوں کو پکڑتا ہے جو آخر میں ٹنل کو مورد الزام ٹھہراتے ہیں۔ فارورڈنگ آن کرنے پر کرنل Router Advertisement کے ذریعے پتے کی تشکیل چھوڑ دیتا ہے، جب تک اسے کچھ اور نہ کہا جائے، اور اس طرح سیکھا گیا ڈیفالٹ راستہ اس کے ساتھ غائب ہو جاتا ہے۔ یا تو WAN انٹرفیس پر واضح ڈیفالٹ راستہ پن کریں، یا وہاں جان بوجھ کر accept_ra کو 2 پر رکھیں۔ کسی بھی تبدیلی کے بعد، کلائنٹ دوبارہ جانچنے سے پہلے تصدیق کریں کہ راؤٹر کے پاس اب بھی باہر جانے کا قابل استعمال IPv6 راستہ ہے۔

جب اوپر والا حصہ روٹ نہ کرے تو ہمسایہ دریافت کا جواب دیں

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

OpenVPN مختص شدہ پتہ client-connect ہک کو دیتا ہے، اس لیے اندراجات ہاتھ سے رکھی گئی فہرست کی بجائے اصل پول کی پیروی کر سکتے ہیں۔ ہک ip -6 neigh add proxy $ifconfig_pool_remote_ip6 dev eth0 شامل کرتا ہے، اور مماثل client-disconnect ہک اسے ہٹا دیتا ہے۔ ہٹائے بغیر پراکسی جدول پرانا ہو جاتا ہے اور بعد میں آنے والا کلائنٹ ایسے پتے کا اندراج ورثے میں پا سکتا ہے جو اسے کبھی نہیں ملا۔ ip -6 neigh show proxy سے حالت کی تصدیق کریں۔

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

باہر کی طرف راستہ فالو کریں، ایک ایک ہاپ

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

ٹنل کے MTU پر نظر رکھیں، کیونکہ راستے کے IPv6 راؤٹر آپ کی طرف سے ٹکڑے نہیں کریں گے۔ بہت بڑا MTU صاف ناکامی کی بجائے packet-too-big خرابی اور رکا ہوا TLS بن کر ظاہر ہوتا ہے۔ اسے واضح طور پر سیٹ کریں اور حد کے قریب پے لوڈ کے ساتھ جانچیں۔