کنترل خاکستری NetworkManager؟ پیش از مجوزها مالکیت را بررسی کنید
یک کلید مرده می‌تواند دستگاه مدیریت‌نشده، عامل احراز مجوز ناموجود یا افزونهٔ ویرایشگر ناموجود باشد. سه بررسی فقط‌خواندنی می‌گویند کدام است.
کلیدهای خاکستری VPN در منوی میزکار می‌گویند چیزی اشتباه است و هیچ نمی‌گویند که چه. این یک مشاهده است، نه تشخیص. سه مرز متفاوت می‌توانند همان کنترل مرده را بسازند: ممکن است NetworkManager مالک دستگاه نباشد، جلسه مجوز تغییر آن را نداشته باشد، یا افزونهٔ ویرایشگر VPN اصلاً نصب نشده باشد. تغییر مرز نادرست همان چیزی است که یک اصلاح پنج‌دقیقه‌ای را به یک بعدازظهر نصب دوبارهٔ بسته‌ها تبدیل می‌کند.
سه فرمان فقط‌خواندنی پیش از هر تغییری این حالت‌ها را جدا می‌کنند.
سه پرسش را به ترتیب مطرح کنید
nmcli device status
nmcli general permissions
nmcli connection showاین‌ها فرمان‌های بازرسی برای سامانه‌ای هستند که واقعاً از NetworkManager استفاده می‌کند و اجرایشان به‌عنوان کاربر عادی بی‌خطر است. اگر خروجی را جایی می‌چسبانید، جزئیات خصوصی اتصال را از گزارش‌های عمومی دور نگه دارید.
وضعیت دستگاه پاسخ می‌دهد که آیا رابط مدیریت‌شده و قابل استفاده است. نمای مجوزها پاسخ می‌دهد که جلسهٔ فراخواننده اجازهٔ چه کاری را دارد. فهرست اتصال‌ها نشان می‌دهد چه نمایه‌هایی وجود دارند؛ اما ثابت نمی‌کند که ویرایشگر VPN یا افزونهٔ درون‌ریزی متناظر نصب شده است.
مالکیت و مجوز دو خطای متفاوت‌اند
دستگاهی که مدیریت‌نشده علامت خورده از کنترل NetworkManager بیرون است و هیچ مقدار مجوزی کلید کارکننده نمی‌سازد. افزونهٔ ifupdown یکی از علت‌های رایج است: تنظیم مدیریت‌شدهٔ آن تعیین می‌کند که مدخل‌های پروندهٔ interfaces چگونه رفتار شوند و یک بلوک باقی‌مانده می‌تواند رابط را زیر ابزار قدیمی نگه دارد. وجود پرونده دستور حذف محتوای آن نیست و پاک کردن مدخل‌هایی که خودتان ننوشته‌اید راه خوبی برای از دست دادن اتصال است.
مجوز یک محور جداست. NetworkManager فراخوانندگان غیر root را از طریق PolicyKit مجاز می‌کند و پاسخ گزارش‌شده می‌تواند بله، auth یا خیر باشد. جلسه‌ای که عامل احراز هویت ندارد auth گزارش می‌کند و سپس در میزکار بی‌صدا شکست می‌خورد، که شبیه کنترل خراب به نظر می‌رسد نه عامل ناموجود.
هیچ‌کدام را با اجرای میزکار به‌عنوان root درست نکنید
اجرای کل جلسه به‌عنوان root برای کار کردن یک کلید، مدل امنیتی هر برنامه روی ماشین را تغییر می‌دهد. همچنین پیکربندی نادرست زیربنایی را به‌جای مستند کردن پنهان می‌کند. اگر یک کنش به احراز مجوز مدیریتی نیاز دارد، همان طراحی درست است و اصلاح به سیاست یا به شیوهٔ آغاز عامل تعلق دارد.
به همین شکل، نسخهٔ دوم NetworkManager یا یک سرویس رقیب را اجرا نکنید. دو مدیر که بر سر یک دستگاه نزاع دارند وضعیتی می‌سازند که استدلال درباره‌اش سخت و پشتیبانی از آن سخت‌تر است. اگر سرویس دوم تنها راه بازگرداندن یک کنترل به نظر می‌رسد، پیکربندی مدیر اول است که باید اصلاح شود. پیش از تغییر هر چیز دیگری سرویس اضافه را متوقف کنید، وگرنه آزمون بعدی هر دو را همزمان می‌سنجد.
پرسش افزونه دربارهٔ ویرایشگر هم هست
ساختن یا درون‌ریزی یک اتصال VPN به افزونه‌ای نیاز دارد که آن نوع اتصال را فراهم می‌کند و روی میزکار معمولاً به یکپارچه‌سازی با ویرایشگر هم نیاز دارد. بستهٔ سمت سرویس می‌تواند موجود باشد در حالی که فرم ویرایشگر نیست، و به همین دلیل یک مدخل منو می‌تواند وجود داشته باشد و باز هم شکست بخورد. هر دو نیمه را با بسته‌بندی توزیع بسنجید نه با این فرض که یک بسته همه‌چیز را نصب می‌کند.
یک فایل دودویی کلاینت مستقل هم مدرک نیست. نصب یک فایل دودویی OpenVPN به‌خودی‌خود به ویرایشگر میزکار فرمی برای ساختن نمایهٔ OpenVPN نمی‌دهد.
مرز مسئول را اصلاح کنید و سپس بررسی
وقتی دانستید کدام مرز نادرست است، تنها همان را تغییر دهید. علامت زدن دستگاه به‌عنوان مدیریت‌شده، دادن مجوز یا نصب بستهٔ ویرایشگر سه عمل متفاوت با سه نمایهٔ ریسک متفاوت‌اند و آمیختنشان نتیجه را غیرقابل نسبت‌دادن می‌کند. اگر مالکیت باید جابه‌جا شود، این کار را با دسترسی کنسول یا دسترسی خارج از باند انجام دهید، چون خطا در آنجا می‌تواند شبکه‌ای را که با آن اصلاح می‌کنید از میان ببرد.
سپس با حساب واقعی و نمایهٔ واقعی بررسی کنید: مسیر، نمای DNS و محل نگهداری راز را تأیید کنید. دکمه‌های فعال وضعیت رابط هستند نه مدرکی بر کار کردن تونل. وضعیت دستگاه، پاسخ مجوز و نسخهٔ افزونه را در تیکت ثبت کنید تا نفر بعد بداند کدام مرز واقعاً تغییر کرده است.