سرویس OpenVPN هنگام درخواست گذرواژهٔ کلید خصوصی متوقف می‌شود: راه اصلاح
سرویس ترمینالی ندارد، پس کلید رمزگذاری‌شده به askpass و فایلی خواندنی نیاز دارد. گذرواژهٔ کلید را از ورود به سرور جدا کنید و unit را بررسی کنید.
OpenVPN گذرواژهٔ کلید خصوصی را روی ماشین محلی می‌پرسد، بنابراین یک فایل ورودِ سالم هرگز به آن پاسخ نمی‌دهد. در سرویس ترمینالی برای تایپ وجود ندارد و راه‌اندازی یا معلق می‌ماند یا با قیدی در ژورنال شکست می‌خورد که ورودی را نام می‌برد نه علت را. دو راز در میان است و هرکدام پیش از راه‌اندازی مجدد unit به منبع خواندنی خودش نیاز دارند. مسیر زیر آن دو را جدا می‌کند و سپس هویتی را بررسی می‌کند که واقعاً هر فایل را باز می‌کند.
دو درخواست را از هم جدا کنید
گذرواژهٔ کلید، کلید خصوصی محلی را رمزگشایی می‌کند؛ اطلاعات حساب، نشست را به سرور احراز می‌کند. این دو از جاهای متفاوت می‌آیند، در لحظه‌های متفاوت شکست می‌خورند و پیام‌های متفاوت می‌دهند. اشتباه گرفتنشان مردم را به دنبال بازنشانی گذرواژه می‌فرستد، در حالی که حساب اصلاً دخیل نبوده است. پیش از تغییر هر گزینه‌ای متن درخواست را بخوانید، چون تنها نشانهٔ قابل اعتماد دربارهٔ رازِ غایب همان عبارت است.
در Community OpenVPN 2.x گزینهٔ askpass فایلی را نام می‌برد که گذرواژهٔ کلید را در خط اول نگه می‌دارد، و auth-user-pass فایلی با نام کاربری در یک خط و گذرواژه در خط بعد. هیچ‌کدام نمی‌تواند گزینهٔ دیگری را برآورده کند. یک برنامهٔ دسکتاپ یا نمایهٔ NetworkManager ممکن است هر دو را در مخزن راز خود نگه دارد که کلاینت خط فرمان هرگز آن را نمی‌خواند، پس قبل از نوشتن هر مسیری مشخص کنید کدام کلاینت را پیکربندی می‌کنید.
هر دو گزینه را به فایل‌های خواندنی اشاره دهید
پروفایلی که به هر دو ورودی نیاز دارد در نهایت سه ارجاع فایل دارد: کلید رمزگذاری‌شده، گذرواژه‌ای که آن را باز می‌کند و جفت ورود. آن‌ها را بدون دست زدن به CA و بررسی‌های هویت اضافه کنید، چون آن‌ها تعیین می‌کنند سرور کیست و بخشی از این مشکل نیستند. اگر استقرار اصلاً از اطلاعات حساب استفاده نمی‌کند، افزودن auth-user-pass ورودی‌ای می‌سازد که هیچ‌کس نمی‌تواند فراهم کند.
key /etc/openvpn/client/office.key
askpass /etc/openvpn/client/office-key.pass
auth-user-pass /etc/openvpn/client/office-login.authگزینه‌های بدون آرگومان رفتاری متفاوت از گزینه‌های دارای مسیر دارند و این تفاوت در سرویس مهم است. askpass بدون آرگومان هنوز کنسول را می‌خواند و فایل auth-user-pass که فقط نام کاربری دارد هنوز درخواست گذرواژه را منتظر می‌گذارد. وقتی کلاینت دیمن می‌شود اصلاً نمی‌تواند از ترمینال ورودی بخواهد، پس سرویسی که این‌طور پیکربندی شده بالا نمی‌آید.
مسیرهای مطلق پرسش دربارهٔ پوشهٔ کاری را برمی‌دارند اما دسترسی نمی‌دهند. مالکیت، حالت و عبور از پوشه‌ها بعد می‌آیند و هر سه بر اساس حسابی که فرایند با آن اجرا می‌شود بررسی می‌شوند.
پیکربندی unit را پیش از پروفایل بخوانید
این unit است، نه فایلی که ویرایش می‌کردید، که تعیین می‌کند نمونه کدام پیکربندی را بارگذاری کند. خط فرمان و هر drop-in آن را بخوانید و سپس پوشهٔ کاری را تا پروفایلی که واقعاً استفاده می‌شود دنبال کنید. ارجاع گذرواژه که به فایل .ovpn دیگری اضافه شود برای این نمونه چیزی را تغییر نمی‌دهد.
سه فرمان فقط خواندنی بیشتر آن را پاسخ می‌دهند. اولی unit و هر drop-in را چاپ می‌کند، دومی هویت و تنظیمات سندباکسی را که فرایند را محدود می‌کنند، و سومی اینکه آخرین راه‌اندازی واقعاً از چه شکایت کرد. از نام نمونه‌ای که روی میزبان وجود دارد استفاده کنید:
systemctl cat [email protected]
systemctl show [email protected] -p User -p Group -p WorkingDirectory -p ProtectHome
journalctl -u [email protected] -bبه ProtectHome و به گزینه‌های خود پروفایل user، group و chroot توجه کنید. فایلی زیر پوشهٔ خانه می‌تواند در پوستهٔ شما خواندنی و پس از پنهان شدن پوشه‌های خانه درون سرویس نامرئی باشد. حسابی که systemd با آن آغاز می‌شود همیشه همان حسابی نیست که در پایان کلید را باز می‌کند.
ثابت کنید هویت زمان اجرا می‌تواند هر دو فایل را باز کند
خواندن حالت کافی نیست، چون هر پوشه در مسیر باید برای همان هویت قابل عبور باشد. مسیر را جزء به جزء بپیمایید و سپس باز کردن را با حسابی که فرایند استفاده می‌کند بیازمایید. فایلی با حالت 600 و مالکیت root فقط تا وقتی فرایند هنوز root است کار می‌کند، که پس از کاهش دسترسی که بسیاری از پروفایل‌ها انجام می‌دهند درست نیست. دو فرمان عبور و باز کردن را پوشش می‌دهند:
namei -l /etc/openvpn/client/office-key.pass
sudo -u openvpn test -r /etc/openvpn/client/office-key.pass && echo readableفرمان اول حالت هر جزء را چاپ می‌کند و جایی شکست می‌خورد که حساب نمی‌تواند عبور کند؛ دومی به تنها پرسش مهم پاسخ می‌دهد، یعنی آیا هویت زمان اجرا می‌تواند فایل را برای خواندن باز کند. هیچ‌کدام محتوای فایل را چاپ نمی‌کند و وقتی فایل گذرواژه دارد همین نکتهٔ اصلی است. آزمون را برای فایل ورود تکرار کنید، چون این دو اغلب با مالکیت متفاوت ذخیره می‌شوند.
اگر فرایند از chroot یا namespace محدود استفاده می‌کند، همان آزمون را از درون آن نما اجرا کنید، وگرنه پاسخ سیستم فایل اشتباهی را توصیف می‌کند. گذرواژه‌ای که زیر پوشهٔ خانهٔ پنهان ذخیره شده نمونهٔ معمول آزمونی است که بیرون unit قبول می‌شود و درون آن شکست می‌خورد.
راه‌اندازی اول را بررسی کنید، سپس اتصال دوباره
نمونه را یک بار راه‌اندازی کنید و اولین شکست را بخوانید نه آخرین را. فایل ورودی غایب، رمزگشایی ناموفق کلید و AUTH_FAILED از سمت سرور سه رویداد متفاوت با سه تعمیر متفاوت‌اند. درست کردن یک هشدار مجوز چیزی را دربارهٔ باز شدن کلید ثابت نمی‌کند.
خط ژورنال می‌گوید کدام یک از سه حالت را دارید. تعمیر از این ناشی می‌شود که کدام ورودی شکست خورد:
| What the journal shows | Which input failed | Where to look |
|---|---|---|
| A path that cannot be opened | The file the profile names | Askpass or login path, and the unit's working directory |
| A key decryption error | The key passphrase | First line of the askpass file, and read access for the runtime identity |
AUTH_FAILED from the server | The account credentials | Login file contents, and whether the account is still valid |
سپس چرخهٔ عمری که واقعاً لازم دارید را بیازمایید: راه‌اندازی در بوت و هر اتصال دوبارهٔ پشتیبانی‌شده، نه فقط راه‌اندازی دستی از پوسته. با auth-nocache ورودی‌ها پس از نخستین استفاده دور ریخته می‌شوند، پس اتصال دوبارهٔ بعدی هنوز به منبعی خواندنی نیاز دارد. جاکلیدی که هنگام ورود به دسکتاپ باز می‌شود برای سرویزی که پیش از ورود کسی آغاز شده در دسترس نیست و همین دلیل معمول قبولی آزمون دستی و شکست راه‌اندازی مجدد است. اگر راه‌اندازی اول موفق شد و اتصال دوبارهٔ بعدی شکست خورد، پیش از تغییر دوبارهٔ مجوزها ژورنال را برای رویداد اتصال دوباره بخوانید.
نگه‌داشتن گذرواژه کنار کلید از آنچه رمزگذاری برایتان می‌خرد می‌کاهد، پس آن فایل و نسخه‌های پشتیبانش را محدود کنید. حذف گذرواژهٔ کلید تصمیمی جدا دربارهٔ اعتبارنامه است، نه تعمیر ورودی غایب. استقرارهایی که به تأیید انسانی یا MFA تعاملی وابسته‌اند به عامل یا یکپارچه‌سازی مدیریت پشتیبانی‌شدهٔ خود نیاز دارند؛ کد یک‌بارمصرفی که دائماً ذخیره شود جایگزین هم‌ارز نیست.