Nebula کو تین فائلیں درکار ہیں: CA، میزبان کی سند اور میزبان کی کلید

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

تین فائلیں، تین مختلف کام

CA سند اعتماد کی لنگر ہے: جب کوئی دوسرا میزبان اپنی شناخت پیش کرتا ہے تو یہ میزبان کو بتاتی ہے کہ کن اداروں پر بھروسہ کرنا ہے۔ میزبان کی سند خود نوڈ کی سند ہے، جس پر وہی ادارہ دستخط کرتا ہے۔ میزبان کی کلید اس کا ملتا جلتا نجی نصف ہے، اور یہ ٹھیک ایک مشین کی ہے۔ CA سند اور اپنی جوڑی رکھنے والا نوڈ overlay میں شامل ہو کر ثابت کر سکتا ہے کہ وہ کون ہے۔ کسی اور کی کلید رکھنے والا نوڈ بھی خود کو وہی شخص کہہ سکتا ہے، اور یہی وہ خرابی ہے جسے روکنے کے لیے یہ ترتیب ہے۔

اس لیے چلتی ہوئی میزبان ڈائریکٹری کو دوسری مشین پر نقل کرنا کوئی شارٹ کٹ نہیں۔ یہ قابلِ اندازہ نتیجے والی نقلی شناخت ہے۔

دستخط کی کلید کبھی سفر نہیں کرتی

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

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

میزبان کی سند کے اندر کیا ہوتا ہے

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

nebula-cert print -path host.crt دکھاتا ہے کہ واقعی کیا جاری ہوا۔ یہ ماننے سے پہلے کہ سند میں آپ کا مطلوبہ پتہ ہے، اسے پڑھیں۔

دوبارہ لوڈ کرنا ہمیشہ کافی نہیں ہوتا

کچھ PKI ترتیبات سگنل پر دوبارہ لوڈ ہوتی ہیں، کچھ نہیں۔وہ سند جس کا overlay پتہ بدل گیا ہو وہی کلاسیکی صورت ہے جس میں دوبارہ لوڈ کرنے کے بجائے عمل دوبارہ شروع کرنا پڑتا ہے۔

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

شناخت ہٹانے کے لیے بلاک لسٹ درکار ہے

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

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