OpenVPN client-config-dir: فائل کا نام اور سرٹیفکیٹ کا CN

کلائنٹ کے جڑنے سے پہلے ہی دو نام کھیل میں ہوتے ہیں: لیپ ٹاپ پر فائل کا نام (nuc.ovpn) اور وہ شناخت جو سرور اسناد سے اخذ کرتا ہے۔ client-config-dir کی تلاش دوسرے کو استعمال کرتی ہے۔ کلائنٹ پر پروفائل کا نام بدلنا، یا سرور کی فائل میں .conf شامل کرنا، اس بات میں کچھ نہیں بدلتا کہ سرور کون سی فائل کھولتا ہے۔

مفید موازنہ «میں نے کون سا نام استعمال کیا» نہیں بلکہ «سرور کون سا قاعدہ لاگو کرتا ہے» ہے، کیونکہ سرٹیفکیٹ کی تصدیق اور صارف نام/پاس ورڈ کی تصدیق ایک ہی لاگ اِن سے مختلف مؤثر نام بنا سکتی ہیں۔

پروفائل کا نام اور سرٹیفکیٹ کا عام نام

پہلے سے طے شدہ سرٹیفکیٹ پر مبنی ترتیب میں سرور X.509 عام نام لیتا ہے اور client-config-dir کے اندر بالکل اسی نام کی فائل تلاش کرتا ہے۔ جس پروفائل کا نام nuc.ovpn ہے اور جس کا سرٹیفکیٹ tester کہتا ہے، وہ /etc/openvpn/server/ccd/tester میں حل ہوتا ہے۔ کلائنٹ فائل کا نام کبھی حساب میں نہیں آتا۔ عدم مطابقت چھپنے کی پہلی جگہ یہی ہے۔

اسی لیے احتیاط سے نام دیے گئے پروفائلز سے بھری ڈائریکٹری ہر بار چوک سکتی ہے۔ فائل subject، ای میل پتے یا GUI میں دکھائے جانے والے نام سے نہیں ملائی جاتی؛ وہ عام نام کی تار سے ملائی جاتی ہے۔

کیس کے لحاظ سے حساس فائل سسٹم پر Tester اور tester دو مختلف فائلیں ہیں، اور صرف ایک کھلتی ہے۔ عام نام اُس سرٹیفکیٹ سے دیکھیں جو کلائنٹ واقعی پیش کرتا ہے، اپنے نوٹس کی نقل سے نہیں۔

username-as-common-name قاعدہ الٹ دیتا ہے

جب سرور username-as-common-name کے ساتھ صارف نام/پاس ورڈ کی تصدیق چلاتا ہے، تو تصدیق شدہ صارف نام اس تلاش کے لیے سرٹیفکیٹ کے عام نام کی جگہ لیتا ہے۔

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

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

سرور کیا پڑھتا ہے، اور کیا خاموشی سے چھوڑ دیتا ہے

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

OpenVPN جس نام کو تلاش کرتا ہے اس میں .conf شامل نہیں کرتا، لہٰذا tester.conf tester سے مطابقت نہیں رکھتا۔ ایکسٹینشن چھپانے والا ایڈیٹر ایسی فائل چھوڑ سکتا ہے جو فہرست میں صحیح دکھے اور کبھی مطابقت نہ رکھے۔

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

صحیح فائل نام مواد کی تصدیق نہیں کرتا

انتخاب اور مواد الگ الگ ناکامیاں ہیں۔ صحیح فائل کھلنے کے بعد بھی اس کی ہدایات اُس کلائنٹ کے لیے درست رہنی چاہئیں۔

ifconfig-push کو ایسا پتہ دینا چاہیے جو ٹوپولوجی واقعی استعمال کر سکے، اور iroute صرف اُس کلائنٹ کے پیچھے روٹ شدہ ذیلی نیٹ کے لیے معنی رکھتا ہے۔

ایک شناخت، کئی آلات

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

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