در ترمینال پیامی دربارهٔ systemd-tty-ask-password-agent ظاهر می‌شود و تونل بالا نیست. خوانش فریبنده این است که VPN رمز عبور را رد کرده و چیزی اکنون منتظر اصلاح است. دقیق‌تر آن است که بگوییم سرویسی از systemd ورودی تعاملی خواسته و درخواست هنوز پاسخ داده نشده است. کدام سرویس پرسیده و کدام راز را می‌خواهد دو پرسشی است که می‌توانید پیش از تایپ کردن هر چیزی حل کنید.

دو شرط تعیین می‌کند چه کسی باید پاسخ دهد

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

وقتی هر دو پاسخ روشن باشد، تصمیم ساده است: از مسیر درخواست پشتیبانی‌شدهٔ خود سرویس پاسخ دهید. وقتی یکی نامشخص باشد، حرکت درست بررسی است نه تایپ کردن رمز در درخواستی که نمی‌توانید به آن نسبت دهید.

این تمام قاعده است و ارزش دارد پیش از دستورها گفته شود. هر چیزی که در ادامه می‌آید از آن ناشی می‌شود.

پیش از تایپ هر چیزی درخواست را فهرست کنید

عامل می‌تواند بدون پاسخ دادن به چیزی، آنچه در انتظار است را برشمارد. sudo systemd-tty-ask-password-agent --list درخواست‌های باقی‌مانده را چاپ می‌کند و آن خروجی همان مدرکی است که برای پیوند دادن یک درخواست به یک واحد لازم دارید. آن را پیش از ارائهٔ داده ورود بخوانید و شرح درخواست‌ها را از هر جای‌گذاری تشخیصی عمومی بیرون نگه دارید.

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

به درخواستی که نمی‌توانید به آن نسبت دهید پاسخ ندهید. هزینهٔ انتظار تأخیر است، در حالی که هزینهٔ پاسخ دادن به درخواست اشتباه، داده ورود در جای اشتباه است.

نمونه واقعاً به کدام راز نیاز دارد؟

auth-user-pass به احراز هویت حساب در سرویس VPN مربوط است و بدون پروندهٔ داده ورود، رفتار مستندشده پرسیدن در کنسول است. askpass در عوض عبارت عبوری را می‌گیرد که مواد کلید محافظت‌شده را باز می‌کند و این کار را پیش از آن انجام می‌دهد که فرایند به پس‌زمینه برود. این دو راز متفاوت با عمرهای متفاوت‌اند.

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

پیش از تصمیم دربارهٔ آنچه تایپ می‌کنید بررسی کنید نمونه از کدام دستور استفاده می‌کند. نام دستور به شما می‌گوید درخواست برای کدام راز است.

--query چه می‌کند که --list نمی‌کند

--query هر درخواست در انتظار را روی ترمینال فراخوان پردازش می‌کند، که اقدامی بسیار گسترده‌تر از پاسخ دادن به یک درخواست است. این یک انتخابگر OpenVPN نیست و روی ماشین شلوغ می‌تواند به درخواست‌های متعلق به واحدهای دیگر پاسخ دهد. حالت نمایش حتی گسترده‌تر است، چون به پردازش درخواست‌ها هنگام رسیدن ادامه می‌دهد.

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

تبدیل یک درخواست یک‌باره به عامل سراسری بی‌ناظر فقط به این خاطر که اعلانی یک بار ظاهر شده، همان راهی است که یک آزار موقت به طراحی دائمی تبدیل می‌شود. همان احتیاط دربارهٔ غیرفعال کردن واحدهای اعلان رمز عبور در سراسر میزبان صدق می‌کند.

تصمیم بگیرید، سپس انتخاب را ثبت کنید

برای استقرار بی‌ناظر، منبع داده ورود، مجوزهای پرونده و برنامهٔ تمدید را با صاحب اتصال توافق کنید. یک عامل دوم تعاملی ممکن است به یک شخص یا هویت سرویس اختصاصی نیاز داشته باشد. سرکوب درخواست آن احراز هویت را تولید نمی‌کند و حذف auth-user-pass فقط سرویسی را که به آن نیاز دارد می‌شکند.

پس از تعامل، به همان نمونه برای رویداد بعدی‌اش نگاه کنید و منبع خصوصی را بیازمایید. اگر چیزی در انتظار نیست، به جای روشن کردن هر واحد OpenVPN روی میزبان به وضعیت نمونه بازگردید.

مقالات مرتبط