صرف پاس ورڈ والی OpenVPN پروفائل میں کون سی CA فائل جاتی ہے؟

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

ترتیب اہم ہے: آخری دو سوال اسی وقت معنی رکھتے ہیں جب آپ جانیں کہ کون سا مواد ہونا چاہیے۔

پروفائل پہلے سے کیا رکھتی ہے اس سے شروع کریں

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

ca /absolute/path/operator-ca.crt
auth-user-pass
remote-cert-tls server

پروفائل جن فائلوں کا حوالہ دیتی ہے ان کے لیے فراہم کردہ پیکج چیک کریں: ایک CA سرٹیفکیٹ، کبھی کبھی الگ کلائنٹ سرٹیفکیٹ اور کلید، اور ممکنہ طور پر tls-auth یا tls-crypt فائل۔ چار فائلوں کا حوالہ دینے والی پروفائل اگر دو کے ساتھ آئے تو نامکمل ہے، اور فیلڈز کی طرف اشارہ کرنے کی کوئی مقدار اسے درست نہیں کرتی۔ اتفاقاً آپ کے پاس موجود سرٹیفکیٹ بدلنے کی بجائے آپریٹر سے گمشدہ حصہ مانگیں۔

مواد کی چار اقسام الگ کریں

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

صرف پاس ورڈ سے تصدیق بدلتی ہے کہ چاروں میں سے کون سی آپ کو درکار ہے، ان کا مفہوم نہیں۔ auth-user-pass اور remote-cert-tls server کے ساتھ کلائنٹ اب بھی CA کے خلاف سرور کی تصدیق کرتا ہے، اسی لیے کلائنٹ سرٹیفکیٹ نہ ہونے پر بھی CA فیلڈ ظاہر ہوتی ہے۔ کلائنٹ سرٹیفکیٹ بھی درکار ہے یا نہیں یہ آپریٹر کی پالیسی طے کرتی ہے، اور کوئی مکالمہ آپ کو یہ نہیں بتا سکتا۔

کلائنٹ کو اعتماد فائل کی طرف موڑیں

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

<ca>
-----BEGIN CERTIFICATE-----
...operator-provided public CA...
-----END CERTIFICATE-----
</ca>

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

وہی خرابی نہیں، اگلی خرابی پڑھیں

درست CA فراہم کرنے کا مقصد خرابی بدلنا ہے، اسے غائب کرنا نہیں۔ CA لوڈ ہونے کے بعد سرور شناخت کی ناکامی کا مطلب ہے کہ سرٹیفکیٹ متوقع نام یا remote-cert-tls توقع سے مطابقت نہیں رکھتا تھا، جو پاس ورڈ مسترد ہونے سے مختلف مرمت ہے۔ پاس ورڈ مسترد ہونا مطلب TLS پرت کامیاب رہی اور اسناد غلط ہیں۔ پہلا نیا پیغام رکھیں؛ وہی مفید ہے۔

جو کلائنٹ جڑتا ہے مگر کہیں نہیں پہنچتا وہ اعتماد سے مکمل گزر چکا ہے اور اب روٹنگ یا DNS سوال کا سامنا کر رہا ہے۔

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