کلائنٹ سرٹیفکیٹ کے بغیر OpenVPN: سرور کی پالیسی، پروفائل نہیں

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

پروفائل پالیسی نہیں ہے

Community OpenVPN 2.6 لازمی کلائنٹ سرٹیفکیٹ کے ساتھ آتا ہے، کیونکہ verify-client-cert بطور طے شدہ require ہے۔ اسے none پر سیٹ کرنا ہی سرٹیفکیٹ کے مطالبے کو روکتا ہے اور کلائنٹ کی توثیق کو اس صارف نام اور پاس ورڈ کے انتظام کے حوالے کرتا ہے جو سرور پہلے سے چلا رہا ہے۔ پرانی گائیڈیں اسی خیال کی پرانی ہجے client-cert-not-required کی طرف جاتی ہیں، اس لیے وہ ہدایت استعمال کریں جسے آپ کا نصب شدہ ورژن دستاویز کرتا ہے۔ بہرحال تبدیلی سرور پر ہوتی ہے، اور کوئی کلائنٹ پروفائل اسے نہیں کر سکتا۔

نیچے دیا گیا ٹکڑا سرور کی طرف کی پوری تبدیلی ہے، اور اکیلا یہ کام کرنے والی توثیقی ترتیب نہیں ہے۔ verify-client-cert none سرٹیفکیٹ کا مطالبہ ہٹاتا ہے، جبکہ username-as-common-name اکاؤنٹ کے نام کو وہ شناخت بناتا ہے جو بعد کی کال بیکس اور فی کلائنٹ فائلیں دیکھتی ہیں۔ کوئی سطر پاس ورڈ کی جانچ نہیں کرتی، اس لیے ایک تصدیق کنندہ پھر بھی موجود ہونا چاہیے۔

verify-client-cert none
username-as-common-name

وہ تصدیق کنندہ ایک پلگ ان یا اسکرپٹ ہے جسے auth-user-pass-verify چلاتا ہے، اور اوپر کی کسی بھی سطر کے معنی خیز ہونے سے پہلے اسے اپنی جگہ پر ہونا چاہیے۔ ترتیب الٹنے سے آپ کو ایسی کھڑکی ملتی ہے جس میں سرور نہ کوئی سرٹیفکیٹ مانگتا ہے اور نہ کوئی اکاؤنٹ جانچتا ہے۔

سرور کی تصدیق اب بھی کیا کرتا ہے

کلائنٹ سرٹیفکیٹ چھوڑنا TLS چھوڑنا نہیں ہے۔ سرور اپنا سرٹیفکیٹ اور کلید رکھتا ہے، اور کلائنٹ CA پر اعتماد اور میزبان نام کی جانچ رکھتا ہے جو اسے کسی دھوکے باز سے بات کرنے سے روکتی ہے۔ کلائنٹ کے پاس اب سرٹیفکیٹ نہیں ہے اس لیے remote-cert-tls server یا CA بنڈل ہٹانا ایک عام اور سنگین غلط قرأت ہے، اور 2.6 حوالہ واضح ہے کہ دونوں سمتیں آزاد ہیں۔ ایک سرور کو کلائنٹ پر ثابت کرتی ہے؛ دوسری کلائنٹ کو سرور پر۔

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

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

تصدیق کنندہ کو کیا کرنا چاہیے

سرٹیفکیٹ کا مطالبہ ہٹانے کے بعد سب کچھ تصدیق کنندہ پر ٹکا ہے: پلگ ان، یا auth-user-pass-verify کے ذریعے چلائی جانے والی اسکرپٹ۔ اسے غلط اسناد مسترد کرنی چاہئیں، غیر فعال یا نااہل اکاؤنٹ مسترد کرنے چاہئیں، اور جب اپنے بیک اینڈ تک نہ پہنچ سکے تو بند ہو کر ناکام ہونا چاہیے۔ username-as-common-name اکثر ساتھ فعال کیا جاتا ہے، اور یہ اس شناخت کو بدلتا ہے جو بعد کی کال بیکس اور فی کلائنٹ ترتیبی فائلیں دیکھتی ہیں۔ یہ پاس ورڈ کی تصدیق نہیں کرتا، اور نااہل اکاؤنٹ کو اہل نہیں بناتا۔ یہ الگ کام ہیں، اور انہیں ملانا ہی وہ طریقہ ہے جس سے کوئی منتقلی اپنی خوشگوار راستے کی آزمائش پاس کرتی ہے اور اپنے پہلے حقیقی واقعے میں ناکام ہوتی ہے۔

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

پالیسی، پروفائل اور میپنگ ایک ساتھ بدلیں

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

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

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