ولې د .ovpn فایل سمول نشي کولی په سرور کې MFA فعال کړي

تاسو auth-user-pass یو پروفایل ته اضافه کوئ، بیا نښلئ، او کلاینټ د کاروونکي نوم او پټنوم غواړي. داسې ښکاري چې MFA فعال دی. بیا تاسو د غلط حساب کوډ یا هغه کوډ ولیکئ چې لس دقیقې دمخه پای ته رسیدلی، او تونل بیا هم پورته کیږي. دا هغه نښه ده: کلاینټ بدل شو، سرور نه. یو ځلي پټنوم یوازې هغه وخت فکتور دی چې په سرور کې یو تاییدوونکی پریکړه کوي چې ایا دا د هغه هویت لپاره معتبر دی چې ادعا یې کوي.

غوښتنه یوازې دا ثابتوي چې کلاینټ پوښتلی، نور نه

.ovpn فایل د کلاینټ اړخ سند دی. دا کولی شي کلاینټ ته ووایي چې اعتبارنامه وغواړي، هغه په کیش کې وساتي یا دا کار بند کړي. دا نشي کولی کاروونکی ثبت کړي، PAM ماډل نصب کړي، یا سرور اړ کړي چې دوهم فکتور وغواړي چې اوس یې نه ګوري.

په تلیفون کې د تصدیق اپلیکیشن نصبول هم هغه اړیکه نه جوړوي. د Google Authenticator PAM پروژه د OTP تایید برخه ده چې کولی شي د OpenVPN شاته کیني؛ دا د ګوګل حساب ننوتلو د وارد شوي پروفایل سره د نښلولو لاره نه ده.

ثبت هغه برخه ده چې پروفایل یې نشي کولی

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 ملاتړ تعریف نه دی.

ځینې پلي کول د لومړني ګوتنې وروسته د تصدیق ټوکنونه صادروي ترڅو بیا نښلول بیا ونه پوښتي. دا د خپل اعتبار وینډو او لغوه کولو کیسې سره ډیزاین تصمیم دی، نه هغه ډیفالټ چې تاسو یې میراث ترلاسه کوئ.

بیا د داخلې تګلاره د هغه کلاینټ سره وازموئ چې خلک یې واقعا کاروي. ثبت شوی کاروونکی چې سم پټنوم، سند او اوسنی کوډ لري باید ونښلي. غلط کوډ، بې ثبت کاروونکی او بند شوی حساب باید هر یو ناکام شي، او دلیل باید د سرور لاګ کې ښکاره وي. تر هغه چې تاسو هغه ردونه نه وي لیدلي، تاسو یوه غوښتنه لرئ، تګلاره نه.