OpenVPN کے CA کی دستخطی کلید کو /etc/openvpn سے باہر رکھیں

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

CA کے ورک اسپیس میں کیا ہوتا ہے

PKI ڈائریکٹری جاری کنندہ کی حالت ہے، ترتیب نہیں۔ اس میں CA کی نجی کلید اور سرٹیفکیٹ، ترتیب فائل، جاری سرٹیفکیٹوں کی فہرست، اور ہر شناخت کا وہ مواد ہے جو ان سے بنایا گیا۔

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

CA کا عوامی سرٹیفکیٹ مختلف ہے۔ یہ تقسیم کے لیے ہے، اور کلائنٹ اور سرور اسی سے ایک دوسرے کی جانچ کرتے ہیں۔

ڈیمون آغاز پر کیا پڑھتا ہے

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

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

systemctl show -p User -p Group -p ReadOnlyPaths [email protected]
stat -c '%a %U:%G' /etc/openvpn/server/server.key
runuser -u openvpn -- test -r /etc/openvpn/server/server.key; echo $?

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

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

CA کلید سرور پر نقل کرنا بعد میں کیوں ناکام ہوتا ہے

نقل عام طور پر ڈیبگنگ کے قدم کے طور پر شروع ہوتی ہے: کسی کو VPN ہوسٹ پر کلائنٹ کی تجدید کرنی ہے، چنانچہ CA کلید /etc/openvpn میں پہنچ جاتی ہے اور تجدید چل جاتی ہے۔ فوری کام کامیاب ہوتا ہے، اور حد ختم ہو جاتی ہے۔

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

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

اکاؤنٹس، ڈائریکٹریاں، بیک اپ

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

منسوخی کے بعد سرور ترتیب میں درج CRL فائل کو اپ ڈیٹ کریں، پھر سروس کو دوبارہ لوڈ کریں تاکہ نئی کنکشنز اسے پڑھیں۔ Easy-RSA ڈاکیومنٹیشن ورک اسپیس کی ترتیب اور دستخط کے بہاؤ کا احاطہ کرتی ہے؛ اس کے گرد ملکیت کے قواعد آپ کے ہوسٹ کے بارے میں فیصلہ ہی رہتے ہیں۔ سروس نے کیا لوڈ کیا اس کی تصدیق openssl crl -in /etc/openvpn/crl.pem -noout -lastupdate -nextupdate سے کریں، یہ ماننے کے بجائے کہ دوبارہ لوڈ نے اسے اٹھا لیا۔

تقسیم کو ثابت کرنے والا امتحان

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

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