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

یقین: منسوخ اور معطل ایک ہی چیز ہیں

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

فرق شخص کا نہیں، اسناد کا ہے۔ جو چابی اب بھی درست ہاتھوں میں ہے اسے اعتماد کے کسی نقصان کے بغیر روکا اور دوبارہ شروع کیا جا سکتا ہے۔ جو چابی کاپی ہو چکی ہو سکتی ہے اسے کبھی بحال نہیں کرنا چاہیے، کیونکہ بحالی یہ دعویٰ کرتی ہے کہ نقل موجود نہیں۔

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

انتظامی انٹرفیس سے چلتا ہوا سیشن گرا دیں

OpenVPN ایک انتظامی انٹرفیس دیتا ہے جو سیشن کی فہرست بنا سکتا ہے اور ان میں سے ایک کو عام نام سے مار سکتا ہے۔ اسے localhost پر فعال کریں، عوامی انٹرفیس سے دور رکھیں، اور جب کسی سیشن کو ابھی غائب ہونا ہو تو مارنے کا حکم بھیجیں۔ یہ حکم صرف اسی ٹنل کو بند کرتا ہے، اور باقی ہر کلائنٹ کام کرتا رہتا ہے۔

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

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

printf 'status 2\nquit\n' | nc 127.0.0.1 7506
printf 'kill kiosk-14\nquit\n' | nc 127.0.0.1 7506

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

CRL اصل میں کیا کنٹرول کرتا ہے

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

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

آخری کاپی کی گئی فائل کے وقت پر بھروسا کرنے کی بجائے فہرست کا معائنہ کریں کہ سرور واقعی کیا نافذ کرے گا۔ اہم حصہ سلسلہ نمبروں کی گنتی ہے۔

openssl crl -in /etc/openvpn/server/crl.pem -noout -text | sed -n '1,14p'
ls -l /etc/openvpn/server/crl.pem

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

ریکارڈ کی بحالی، احتیاط سے

سرٹیفکیٹ کی بحالی کا مطلب ہے جاری کرنے کے ڈیٹا بیس میں ریکارڈ کو اُلٹنا اور نئی فہرست شائع کرنا۔ easy-rsa 3 وہ ڈیٹا بیس PKI ڈائریکٹری کے تحت index.txt کے طور پر رکھتا ہے، جبکہ پرانے ترتیبات مختلف طریقہ استعمال کرتے تھے۔ قطار حالت کے حرف اور میعاد ختم ہونے کی تاریخ سے شروع ہوتی ہے۔ منسوخ شدہ قطار سلسلہ نمبر، سرٹیفکیٹ فائل کا نام اور امتیازی نام کے ساتھ آگے بڑھنے سے پہلے منسوخی کا وقت درج کرتی ہے۔ قطار کو واپس رکھنے کا مطلب ہے وہ وقت مٹانا اور حرف اُلٹنا، جبکہ باقی سب کچھ بحال رکھنا۔

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

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

cp /etc/easy-rsa/pki/index.txt /root/index.txt.$(date +%F-%H%M)
grep -c '^R' /etc/easy-rsa/pki/index.txt
easyrsa gen-crl

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

جانچیں کہ معاملہ کس لیور کا حقدار ہے

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

پھر نتیجے کو ترتیب کے فرق سے نہیں، کنکشن کی کوشش سے جانچیں۔ فرق بتاتا ہے کہ آپ کا ارادہ کیا تھا، اور کنکشن بتاتا ہے کہ سرور کیا نافذ کرتا ہے۔

openssl crl -in /etc/openvpn/server/crl.pem -noout -text | grep -c 'Serial Number'
printf 'status 2\nquit\n' | nc 127.0.0.1 7506

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

متعلقہ مضامین