کاربری روی سرور افزوده شد، گذرواژه درست تایپ شد، و اتصال همچنان با AUTH_FAILED پایان می‌یابد. خط افزونه معمولاً دلیل را توضیح می‌دهد: کلمهٔ پس از مسیر افزونه نام یک سرویس PAM است و تعیین می‌کند کدام پشته از ماژول‌ها به پرسش پاسخ می‌دهد. این یک نام کاربری نیست و اشاره‌گری به فایل گذرواژه هم نیست که OpenVPN خودش آن را بخواند.

کلمهٔ دوم چه چیزی را انتخاب می‌کند

خط پیکربندی یک مسیر افزونه و یک آرگومان می‌گیرد:

plugin /usr/lib/openvpn/plugins/openvpn-plugin-auth-pam.so openvpn

این آرگومان به کتابخانهٔ PAM به‌عنوان نام سرویس داده می‌شود و همین باعث می‌شود پشتهٔ موجود در /etc/pam.d/openvpn اجرا شود. اگر آنجا login بنویسید، در عوض سیاست ورود تعاملی را دریافت می‌کنید، با هر ماژولی که آن سیاست در توزیع شما شامل شود.

از مسیر افزونه‌ای استفاده کنید که بستهٔ نصب‌شده فراهم می‌کند، نه مسیری که از میزبان دیگری کپی شده است. نام فایل و پوشه میان توزیع‌ها متفاوت است و مسیر نادرست در هنگام راه‌اندازی با خطای بارگذاری افزونه شکست می‌خورد، نه در هنگام احراز هویت.

پشته واقعاً حساب‌ها را از کجا می‌خواند

PAM یک توزیع‌کننده است. فایل سرویس ماژول‌ها را به ترتیب فهرست می‌کند و نخستین ماژولی که بتواند پاسخ دهد نتیجه را تعیین می‌کند. پشته‌ای که pam_unix را فراخوانی می‌کند حساب‌های محلی را می‌خواند؛ پشته‌ای که ماژول LDAP یا RADIUS را فراخوانی می‌کند اعتبارنامه‌ها را به جایی کاملاً دیگر می‌فرستد.

فایلی را بخوانید که نام سرویس به آن تجزیه می‌شود، همراه با هر چیزی که شامل آن است:

cat /etc/pam.d/openvpn
grep -H pam_ /etc/pam.d/openvpn /etc/pam.d/common-auth

اگر پشته به یک دایرکتوری واگذار کند، افزودن حساب محلی چیزی را تغییر نمی‌دهد. اگر حساب‌های محلی را بخواند، ساختن کاربر در دایرکتوری هم چیزی را تغییر نمی‌دهد. حساب باید همان‌جایی باشد که پشته نگاه می‌کند، و در بیشتر این گزارش‌ها همین تمام تشخیص است.

یک تلاش، دو گزارش

یک اتصال ناموفق را در هر دو سو به هم ربط دهید. گزارش OpenVPN نتیجهٔ افزونه و رد شدن مشتری را نشان می‌دهد؛ گزارش احراز هویت سامانه نشان می‌دهد کدام ماژول اجرا شد و چه تصمیمی گرفت. خواندن هر دو در یک بازهٔ زمانی همان چیزی است که فایل سرویس گم‌شده را از وقفهٔ سرویس پشتی جدا می‌کند. شکافی در گزارش احراز هویت یعنی هرگز به پشته نرسیده‌اید.

journalctl -u openvpn-server@server --since "-2 min"
journalctl -t sshd -t sudo --since "-2 min"

سرویس را مستقیم با ابزاری که با PAM حرف می‌زند بیازمایید تا هم‌زمان VPN و پشته را عیب‌یابی نکنید. یک آزمون مستقیم موفق با همان نام سرویس و حساب، مشکل را به شیوهٔ انتقال اعتبارنامه‌ها توسط دیمن محدود می‌کند، نه به خود حساب.

pamtester openvpn alice authenticate

اگر آزمون مستقیم با همان اعتبارنامه‌هایی که در کنسول کار می‌کنند شکست بخورد، پشته منبع حسابی را که فرض کرده‌اید نمی‌خواند. اگر موفق شود، به گفت‌وگویی که افزونه اجرا می‌کند و آنچه مشتری واقعاً فرستاده نگاه کنید. یک بار هم با گذرواژه‌ای که عمداً غلط است اجرا کنید تا تفاوت میان رد شدن و خطای ماژول را ببینید. این دو نتیجه در گزارش VPN یکسان و اینجا کاملاً متفاوت به نظر می‌رسند.

سرویس اختصاصی بهتر از ویرایش ورود است

وقتی نیازهای VPN با ورود تعاملی متفاوت است، که معمولاً چنین است، فایل سرویس خودش را به آن بدهید. ویرایش login یا common-auth سیاست را برای هر برنامه‌ای که آن‌ها را شامل می‌شود تغییر می‌دهد، و نفر بعدی که یک مشکل ورود نامرتبط را عیب‌یابی کند تغییر شما را به ارث می‌برد.

ماژول‌های مورد نیازتان را در یک فایل سرویس کوچک کپی کنید، ترتیب را صریح نگه دارید و یادداشت کنید که مالک آن کیست. همان فایل چیزی است که باید بررسی شود وقتی بازنشانی گذرواژه بی‌اثر به نظر می‌رسد.

مشتری چه می‌فرستد و چه نمی‌فرستد

مشتری نام کاربری و گذرواژه را از طریق اعلان یا فایل پشتیبانی‌شدهٔ خود فراهم می‌کند. افزونهٔ سرور آن مقادیر را به گفت‌وگوی PAM می‌فرستد؛ آن‌ها را از پیکربندی سرور نمی‌خواند. خطی در سمت سرور که به نظر می‌رسد گذرواژه‌ای تعریف می‌کند چنین کاری نمی‌کند و هیچ ویرایش نمایه‌ای حساب نمی‌سازد.

نام کاربری و گذرواژه می‌توانند در کنار گواهی‌های مشتری وجود داشته باشند، و فعال‌کردن PAM دلیلی برای توقف بررسی گواهی‌ها نیست. لایه‌هایی را که استقرار در نظر داشت نگه دارید و فقط منبع حساب‌ها را درست کنید.

پذیرش دوطرفه است: حساب مورد نظر موفق می‌شود و حسابی که باید رد شود همچنان شکست می‌خورد. فایل README افزونهٔ auth-pam آرگومان سرویس و سرویس‌های پشتی را که می‌تواند پوشش دهد مستند می‌کند و همان‌جا محل تأیید ترتیبی است که می‌خواهید بسازید.

مقالات مرتبط