چرا ویرایش یک فایل .ovpn نمی‌تواند MFA را روی سرور روشن کند
درخواست کلاینت فقط نشان می‌دهد که کلاینت پرسیده است. سرور باید هویت را ثبت کند و کد را بررسی کند، و کد اشتباه باید پیش از آنکه آن را 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 نیست، هر چند وقت یک‌بار هم که در تاپیک‌های انجمن ظاهر شود.
برخی استقرارها پس از بررسی اولیه توکن‌های احراز هویت صادر می‌کنند تا اتصال‌های مجدد دوباره نپرسند. این تصمیمی طراحی با پنجره اعتبار و داستان ابطال خودش است، نه پیش‌فرضی که به ارث می‌برید.
سپس سیاست پذیرش را با کلاینتی که مردم واقعاً استفاده می‌کنند بیازمایید. کاربر ثبت‌نام‌شده با گذرواژه، گواهی و کد جاری درست باید متصل شود. کد اشتباه، کاربر بدون ثبت‌نام و حساب ممنوع باید هر یک شکست بخورند و دلیل باید در گزارش سرور دیده شود. تا زمانی که آن ردها را ندیده‌اید، یک درخواست دارید نه یک سیاست.