چرا سرویس VPN که هنگام بوت راه‌اندازی می‌شود نمی‌تواند حلقه کلید شما را بخواند

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

درخواست را دنبال کنید: چیزی اتصال را پیش از آنکه نشست میزکار وجود داشته باشد آغاز می‌کند، و انبار راز که معمولاً پاسخ می‌دهد هنوز باز نشده است. دو زمینه بر سر اینکه راز از آنِ کیست هم‌داستان نیستند، و نمایه ثبت می‌کند که انتظار می‌رود کدام‌یک آن را تأمین کند.

مسیر بوت در واقع چه می‌خواهد

هنگام بوت، NetworkManager به‌عنوان سرویس سیستمی بدون نشست کاربر، بدون D-Bus نشست و بدون حلقه کلید بازشده راه می‌افتد. نمایه اتصال باز هم می‌تواند بالا بیاید، اما فقط با رازهایی که سرویس خودش به آن‌ها دسترسی دارد. هر چیزی که در اختیار عامل راز باشد تا وقتی انسانی وارد نشود و عامل پدیدار نشود منتظر می‌ماند. سرویس دقیقاً همان کاری را می‌کند که پیکربندی‌اش می‌گوید؛ نمایه چیزی است که باید تغییر کند.

شکست درون اتصال نوشته شده است، نه پنهان در حلقه کلید.

خواندن پرچم‌های راز روی یک اتصال

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

با فهرست نمایه‌ها آغاز کنید، سپس تأیید کنید کدام اتصال برای بالا آمدن خودکار تنظیم شده است. سپس یک اتصال را بیرون بریزید و پرچم‌های رمز را بخوانید:

nmcli -f NAME,UUID,TYPE,AUTOCONNECT connection show
nmcli connection show "Work VPN" | grep -i -E "password|secret|key"
journalctl -b -u NetworkManager --grep "secret"

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

چرا انتقال اتصال به دامنه سیستم پاسخ را تغییر می‌دهد

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

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

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

چه کاری نکنید و در عوض چه کاری بکنید

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

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

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