مشترکہ CA، الگ دروازے: فی داخلہ فائل ایک سروس

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

قابل اعتماد زنجیر سروس کی رکنیت کے بارے میں کچھ نہیں بتاتی

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

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

اختیاری اوور رائیڈز کو داخلہ گیٹ بنائیں

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

client-config-dir /etc/openvpn/service-a/clients
ccd-exclusive

کمیونٹی ایڈیشن OpenVPN 2.6 ccd-exclusive اپنے مینوئل صفحے میں بالکل اسی شرط کو درج کرتا ہے، اور نامزد فائل کی تلاش مؤثر کلائنٹ شناخت پر منحصر ہے۔ دیگر بلڈز اور مصنوعات کے زیر انتظام سرور مختلف ہو سکتے ہیں، لہٰذا کہیں اور اسی معنی پر بھروسہ کرنے سے پہلے نصب شدہ ورژن کی تصدیق کریں۔

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

ہر سروس کے لیے ایک ڈائریکٹری، ایک مشترکہ فہرست نہیں

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

DEFAULT اندراج وہ معاملہ ہے جو لوگوں کو گمراہ کرتا ہے۔ نامزد فائل نہ ملنے پر یہ متبادل ترتیبات دیتا ہے، لیکن یہ وہ نامزد فائل نہیں ہے جو گیٹ چاہتا ہے، اس لیے یہ اکیلے کلائنٹ کو داخل نہیں کر سکتا۔ ایسے کلائنٹ کی جانچ کریں جس کا کوئی اندراج نہیں ہے اور انکار کی تصدیق کریں؛ اگر وہ کلائنٹ داخل ہو جائے تو متبادل لاگو ہے اور ccd-exclusive اس مثال میں نافذ نہیں ہے۔

مؤثر شناخت طے کرتی ہے کہ کون سی فائل پڑھی جائے گی

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

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

انکار، داخلہ اور منسوخی کو الگ الگ دیکھیں

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

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

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