Windows پر OpenVPN 3 اور Connect میں cryptoapicert کیوں ناکام ہوتا ہے

آپ ایک کام کرنے والا OpenVPN 2 پروفائل نئے Windows کلائنٹ میں کاپی کرتے ہیں، اور پرانے کلائنٹ کو خود ملنے والا سرٹیفکیٹ اب پیش نہیں کیا جاتا۔ جس سطر نے یہ ممکن بنایا وہ Community 2 کلائنٹ کی Windows-مخصوص منتخب کنندہ ہے، اور نیا اطلاقیہ مختلف اسناد کے راستے والا دوسرا پروگرام ہے۔ پروفائل اسی ایک سطر کے سوا تبدیل نہیں ہوا، اور یہی فرق دیکھنا مشکل بناتا ہے۔

اس رپورٹ میں تین سطحیں ملا دی جاتی ہیں: Community کلائنٹ، بنیادی لائبریری اور کسی کا نصب کردہ فرنٹ اینڈ۔ ان میں سے صرف ایک نے کبھی یہ ہدایت سمجھی۔

یہ اختیار جہاں موجود ہے وہاں اس کا مطلب کیا ہے

Windows پر Community OpenVPN 2 کلائنٹ میں، cryptoapicert ایسے سرٹیفکیٹ کا نام دیتا ہے جو کلائنٹ کو فائل میں نہیں بلکہ Windows سرٹیفکیٹ مخزن میں تلاش کرنا چاہیے۔ یہ Windows-مخصوص سہولت ہے، اور یہ کام کرتی ہے کیونکہ وہ کلائنٹ مخزن کی فہرست بنانا اور حاصل شدہ کلید اپنے TLS اسٹیک کو دینا جانتا ہے۔ اس لیے یہ ہدایت اسی کلائنٹ کی تشکیلاتی زبان کا حصہ ہے، OpenVPN پروٹوکول کی خصوصیت نہیں۔ ترسیلی شکل میں اسے اٹھانے والا کچھ نہیں۔

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

اس کے بجائے بنیادی لائبریری کیا فراہم کرتی ہے

OpenVPN 3 Core ایک لائبریری ہے جسے دوسرے اطلاقیے شامل کرتے ہیں، اور یہ بیرونی اسناد کو مخزن کی تلاش کے بجائے API کے ذریعے سنبھالتی ہے۔ شامل کرنے والا اطلاقیہ سرٹیفکیٹ زنجیر فراہم کرتا ہے اور بعد میں لائبریری سے بیرونی کلید سے دستخط کرنے کو کہتا ہے، اور لائبریری یہ کرنے کے لیے اطلاقیے کو واپس بلاتی ہے۔ یہ زیادہ عمومی ڈیزائن ہے، اور اس کا مطلب ہے کہ فرنٹ اینڈ فیصلہ کرتا ہے کہ کون سے فراہم کنندگان موجود ہیں۔ لائبریری کی اپنی اختیارات کی کارروائی میں cryptoapicert ان ہدایات کے درمیان دکھائی دیتا ہے جو نافذ نہیں کی گئیں، جو اسی ذمہ داری کی تقسیم سے مطابقت رکھتا ہے۔

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

اس کے بجائے Windows فرنٹ اینڈ کیا کرتا ہے

OpenVPN Connect مختلف راستہ اختیار کرتا ہے: آپریٹر PKCS#12 فائل درآمد کرتا ہے جس میں سرٹیفکیٹ اور اس کی نجی کلید ہوتی ہے، اسے اسی مقصد کے لیے بنائے گئے OpenVPN Certificate Store میں رکھتا ہے، پھر بیرونی سرٹیفکیٹ پروفائل کو تفویض کرتا ہے۔ یہ دانستہ درآمد کا مرحلہ ہے، ذاتی مخزن میں موجود کسی چیز کی خودکار دریافت نہیں۔ یہ فرق تب اہم ہوتا ہے جب کوئی سمجھے کہ کسی دوسرے مقصد کے لیے نصب سرٹیفکیٹ بس کلائنٹ کی فہرست میں دکھائی دے گا۔

درآمد کا کلید کی پالیسی پر بھی اثر ہوتا ہے، کیونکہ کلید کو P12 فائل میں برآمد کرنا وہی ہے جسے ناقابل برآمد کلید روکنے کے لیے بنائی گئی ہے۔ یہ تشکیل کا نہیں، پالیسی کا سوال ہے، اور کسی کے درآمد کی کوشش سے پہلے اس کا جواب ضروری ہے۔

کلید کی پالیسی سے مطابقت رکھنے والا راستہ منتخب کریں

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

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

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