.ovpn فائل میں ترمیم کرنا سرور پر MFA کیوں فعال نہیں کر سکتا

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

درخواست صرف یہ ثابت کرتی ہے کہ کلائنٹ نے پوچھا، اس سے زیادہ نہیں

.ovpn فائل کلائنٹ کی طرف کی دستاویز ہے۔ یہ کلائنٹ کو کہہ سکتی ہے کہ اسناد طلب کرے، انہیں کیش کرے یا ایسا کرنا بند کر دے۔ لیکن یہ کسی صارف کو رجسٹر نہیں کر سکتی، PAM ماڈیول نصب نہیں کر سکتی، یا سرور کو ایسا دوسرا عامل مانگنے پر مجبور نہیں کر سکتی جو وہ ابھی نہیں جانچتا۔

فون پر تصدیقی ایپ نصب کرنا بھی وہ تعلق نہیں بناتا۔ Google Authenticator PAM منصوبہ OTP کی تصدیق کا جزو ہے جو OpenVPN کے پیچھے بیٹھ سکتا ہے؛ یہ درآمد شدہ پروفائل پر Google اکاؤنٹ لاگ ان چپکانے کا طریقہ نہیں ہے۔

رجسٹریشن وہ حصہ ہے جو پروفائل نہیں کر سکتی

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

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

PAM پر مبنی ڈیزائن کو ہر VPN صارف کے لیے الگ Unix اکاؤنٹ بنانے کی ضرورت نہیں۔ ماڈیول کی دستاویزات متبادل خفیہ راستوں اور فائل تک رسائی کے لیے مخصوص اکاؤنٹ کی حمایت کرتی ہیں، جو فائل سسٹم کی شناخت ہے، تصدیق ہونے والی لاگ ان شناخت نہیں۔

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

PAM اسٹیک پڑھیں اور دیکھیں کہ واقعی کیا ضروری ہے

account required pam_permit.so جیسی سطر اکاؤنٹ کی اہلیت نافذ نہیں کرتی اور کوئی عامل شامل نہیں کرتی۔ یہ اُس PAM اکاؤنٹ انتظام مرحلے کی اجازت دیتی ہے، جو مرحلے کے بارے میں بیان ہے، آپ کے صارفین کے بارے میں نہیں۔

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

کلائنٹ کے تعامل کو سرور کے ڈیزائن سے ہم آہنگ کریں

auth-user-pass

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

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

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

دوبارہ جڑنا، ٹوکن اور وہ امتحان جو معاملہ طے کرتا ہے

پہلے کامیاب لاگ ان کے بعد کیا ہوگا اس کی منصوبہ بندی کریں۔ پہلے قبول کیا گیا کوڈ اگلی تصدیق پر ختم ہو چکا یا تکرار کے طور پر مسترد ہو سکتا ہے۔ auth-nocache اسناد کی حفاظت کو کنٹرول کرتا ہے اور MFA نصب نہیں کرتا، اور reneg-sec 0 فورم کے دھاگوں میں کتنی ہی بار آئے، TOTP حمایت کی تعریف نہیں ہے۔

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

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