ایک VPN ڈیزائن بریف لکھیں جس کا کوئی واقعی جائزہ لے سکے

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

پہلا، سوال فیصلہ ہے یا خواہش

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

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

اگر جواب کوئی نہیں ہے تو یہیں رک جائیں، کیونکہ مالک کے بغیر فیصلہ سب سے اونچی آواز میں شکایت کرنے والا دوبارہ بنائے گا۔ یہ ڈیزائن کا مسئلہ نہیں، حکمرانی کا مسئلہ ہے۔

دوسرا، بہاؤ اور انکار کے نام لیں

ہر اس بہاؤ کے لیے ماخذ، منزل اور ایپلیکیشن کی فہرست بنائیں جو کام کرنا چاہیے۔ پھر ان بہاؤ کی فہرست بنائیں جو ناکام ہوتے رہنا چاہئیں، کیونکہ جو ڈیزائن خاموشی سے ان کی اجازت دیتا ہے اس نے بتائے بغیر ضرورت بدل دی ہے۔ پتوں کا باہمی تداخل اور اوپر تک رسائی اس فہرست میں حیرت کے بجائے پابندی کے طور پر آتی ہیں۔

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

کلائنٹ اور ان کی انتظامی حالت بھی نوٹ کریں، کیونکہ ایجنٹ والا زیرِ انتظام آلہ وہ کام کر سکتا ہے جو خود لایا گیا لیپ ٹاپ نہیں کر سکتا۔

فہرست کو جانچنے کے قابل حد تک مختصر رکھیں۔ جو دس بہاؤ آپ تصدیق کر سکتے ہیں وہ ان چالیس سے بہتر ہیں جو نہیں کر سکتے۔

جانچ 3: حقائق کو مفروضوں سے الگ کریں

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

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

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

ip route get 10.50.0.10
traceroute -n -m 6 10.50.0.10
nc -vz 10.50.0.10 443

چوتھا، ناکامی کا معاہدہ لکھیں

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

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

بحالی کا ہدف سادہ زبان میں شامل کریں، جیسے کوئی سائٹ کتنی دیر بگڑی ہوئی حالت میں چل سکتی ہے اور واقعے کا اعلان کون کرتا ہے۔

جانچ 5 اور 6: سیم چنیں اور تبدیلی درج کریں

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

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

git diff --stat design/vpn-brief.md
grep -n 'assumption' design/vpn-brief.md
ip route get 10.50.0.10

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