ایک Pi پر دو VPN ہاپ: کون سا روٹ کون سا ساتھی لے جاتا ہے

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

مختلف حاملین درکار تین منزلیں

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

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

پتوں کی گنتی نہیں، کردار ہوتے ہیں

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

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

ip -4 addr show
ip -4 route show table all
ip rule show

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

فعالیت کی ترتیب مقررہ انتظار کو ہراتی ہے

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

کرنل tun0 اور tun1 جیسے نام تخلیق کی ترتیب سے دیتا ہے، اور یہ ترتیب دوبارہ شروع یا دوبارہ جڑنے کے دوران بدل سکتی ہے۔ ترتیب کو اُس شناخت سے باندھیں جو اوزار فراہم کرتا ہے، یا اُس نام سے جو آپ دانستہ دیتے ہیں۔ آپ کا چنا نام معاہدہ ہے؛ کرنل کا چنا نام حادثہ ہے۔

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

بیرونی ہاپ مرنے پر کیا ہوتا ہے

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

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

DNS اور دوسرا پتہ خاندان اسی فیصلے کا حصہ ہیں۔ مقامی طور پر پیدا کردہ تلاش میزبان کی اپنی پالیسی کی پیروی کرتی ہے، منتقل شدہ کلائنٹ کی نہیں، اس لیے منتقل شدہ ٹریفک کے لیے کام کرنے والا حل کنندہ وہ نہیں ہو سکتا جو میزبان خود استعمال کرتا ہے۔

ہر پرت کو اُسی ترتیب سے قبول کریں جس میں آپ نے اسے بنایا

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

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