VPN کی نجی کلید کہاں رہنی چاہیے: فائل، CNG یا TPM؟

دو سوال طے کرتے ہیں کہ VPN کی نجی کلید کہاں کی ہے: کیا کلید کا مواد میزبان سے نقل کیا جا سکتا ہے، اور کیا کوئی عمل اسے کی بورڈ پر کسی کے بغیر استعمال کر سکتا ہے۔ ذخیرے کا مارکیٹنگ لیبل دونوں کا جواب نہیں دیتا۔ ٹنل ڈیمون جسے دوبارہ آغاز کے بعد واپس آنا ہو، بے نگرانی استعمال چاہتا ہے، جو ہر اس چیز کو خارج کرتا ہے جو انسان کے ٹائپ کردہ PIN پر منحصر ہو۔

نقل اور استعمال میں سے چنیں

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

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

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

ذخیرے کو ٹنل ڈیمون سے ہم آہنگ کریں

ڈیمون اسے تحفظاتی پالیسی سے زیادہ محدود کرتا ہے۔ WireGuard فائل یا wg set کی ان پٹ سے base64 نجی کلید لیتا ہے اور سرٹیفکیٹ ذخیرے تک کوئی راستہ نہیں رکھتا، اس لیے TPM کی تائید والی انٹرفیس کلید زیر بحث نہیں۔ OpenSSL 3 کے خلاف بنایا گیا OpenVPN کلید کو فراہم کنندہ URI سے لوڈ کر سکتا ہے، اور strongSwan PKCS#11 تائید کے ساتھ TPM پلگ ان دیتا ہے، مگر دونوں اس پر منحصر ہیں کہ آپ کا پیکج کیسے مرتب ہوا۔

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

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

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

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

openssl x509 -in vpn.crt -noout -subject -ext subjectAltName
openssl pkey -in vpn.key -check -noout
openssl x509 -in vpn.crt -noout -pubkey | openssl sha256
openssl pkey -in vpn.key -pubout | openssl sha256

آخری دو خلاصے یکساں ہونے چاہئیں۔ اگر نہ ہوں تو ڈیمون ترتیب مکمل کرتا ہے اور پھر ہر کوشش میں سرٹیفکیٹ یا دستخط کی خرابی سے ناکام ہوتا ہے جو اصل وجہ کے قریب کہیں اشارہ نہیں کرتی۔ WireGuard کا متبادل مختصر ہے، کیونکہ عوامی کلید براہ راست نجی سے اخذ ہوتی ہے: wg pubkey < /etc/wireguard/wg0.key کو وہ ہم منصب کلید چھاپنی چاہیے جو آپ کا سرور پہلے سے محفوظ رکھتا ہے۔

اجازتیں اسی فہرست کا حصہ ہیں۔ stat -c '%a %U:%G' /etc/wireguard/wg0.key کو 600 root:root واپس کرنا چاہیے، اور جو کچھ گروپ یا دنیا کے لیے پڑھا جا سکے اس کا مطلب ہے کہ کلید پہلے ہی ایسے عملوں کو دستیاب تھی جن کا آپ نے کبھی تصور نہیں کیا۔

ذخیرہ اور استعمال کا راستہ جانچیں

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

certutil -store -user My
certutil -csp "Microsoft Platform Crypto Provider" -key -user
certutil -verifykeys -user My
ipsec listcerts

Windows پر پہلی کمانڈ ذاتی ذخیرہ فہرست کرتی ہے اور ہر اندراج کے ساتھ کلید فراہم کنندہ چھاپتی ہے، اور وہیں ایسا سرٹیفکیٹ نظر آتا ہے جو ہارڈ ویئر سے محفوظ لگتا ہے مگر سافٹ ویئر فراہم کنندہ میں بیٹھا ہے۔ دوسری پلیٹ فارم کرپٹو فراہم کنندہ کی کلیدیں فہرست کرتی ہے، اس لیے وہاں غائب VPN شناخت جبکہ اس کا سرٹیفکیٹ موجود ہو، یعنی نجی نصف کہیں اور رہتا ہے۔ Linux گیٹ وے پر ipsec listcerts بتاتا ہے strongSwan نے کیا لوڈ کیا، بشمول TPM پلگ ان سے آئی کلیدیں۔ اندراجات کی تعداد پر بھروسے کے بجائے فنگر پرنٹس یا عوامی کلید ہیش فہرست سے موازنہ کریں۔

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

تجدید اور واپسی لکھیں

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

ختم ہونے کو رکاوٹ بننے سے پہلے جانچیں: openssl x509 -in vpn.crt -noout -checkend 2592000 غیر صفر کوڈ سے ختم ہوتا ہے جب سرٹیفکیٹ تیس دن میں ختم ہو، اس لیے یہ سیدھا نگرانی کی جانچ میں آ جاتا ہے۔ اس سطر کا ہفتہ وار اجرا وہ تجدید پکڑتا ہے جسے کسی نے شیڈول نہیں کیا تھا۔

ہٹانا سرور پر ہوتا ہے: ہم منصب حذف کریں یا سیریل نمبر منسوخ کریں، پھر تصدیق کریں کہ ٹنل ناکام ہوتی ہے، کیونکہ کیش شدہ سیشن والا کلائنٹ آدھی مکمل منسوخی کو کچھ دیر چھپا سکتا ہے۔ منسوخی کو صرف CA ڈیٹابیس تک نہیں، کنسنٹریٹر کے CRL یا OCSP راستے تک بھی پہنچنا چاہیے۔ سرٹیفکیٹ عوامی دستاویز ہے، اور RFC 5280 پروفائل بتاتا ہے کہ اس کی تصدیق کیسے ہوتی ہے؛ اس تصدیق کا کوئی حصہ گردش سے پہلے نقل شدہ نجی کلید کی حفاظت نہیں کرتا۔

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