دو سرورز پر ایک VPN اکاؤنٹ: حالت کے تین رجسٹر

ایک اکاؤنٹ جو دو VPN نوڈز میں سے کسی ایک پر بھی سائن اِن کر سکتا ہو، سافٹ ویئر کا سوال بننے سے بہت پہلے ڈیزائن کا سوال اٹھاتا ہے۔ اکاؤنٹ کا منظر، ہر نوڈ کا اپنا نیٹ ورک اور منسلک کلائنٹ کا سیشن حالت کی تین مختلف قسمیں ہیں، اور انہیں ایک جگہ سے دوسری جگہ نقل کرنے پر یہ مختلف طریقوں سے ناکام ہوتی ہیں۔ تینوں کو ایک ہی نظام میں نقل کرنا ان میں سے ایک کھو دینے کا عام طریقہ ہے۔

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

کون جڑ سکتا ہے: ایک اختیار، کئی نوڈز

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

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

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

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

نوڈ کے پاس کیا ہے: پتے اور راستے

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

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

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

ایک دستاویزی مصنوع کی مثال یہاں مدد کرتی ہے۔ Pritunl کی نقل کی دستاویز VPN نیٹ ورک کو ہر نقل کے لیے شے سمجھتی ہے، اور مختلف نقلوں پر کلائنٹس کو ایک دوسرے تک پہنچنے کے لیے اضافی راستے اور رابطہ درکار ہوتا ہے۔ یہ مصنوع کے لیے مخصوص بندوبست ہے، Community OpenVPN کے لیے نسخہ نہیں، مگر یہ دکھاتا ہے کہ نقل شامل کرنا صرف اکاؤنٹ کے ذخیرے کو نہیں بلکہ نیٹ ورک کو بھی بدلتا ہے۔

سیشن کیا ہے: قطار نہیں، زندہ حالت

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

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

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

تین رجسٹروں کی جانچ

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

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

کثیر نوڈ اکاؤنٹ ڈیزائن صرف اُس وقت مکمل ہے جب تینوں رجسٹروں کا واضح مالک، تبدیلی کا راستہ اور ناکامی کا رویہ ہو۔ نوڈز کے درمیان ترتیب کی فائل نقل کرنا اِن سوالوں میں سے کسی کا جواب نہیں دیتا۔