Keyfile یا Netplan: نمایه VPN واقعاً کجا ذخیره می‌شود؟
یک VPN ذخیره‌شده می‌تواند در یک keyfile یا در فایل Netplan تولیدشده زندگی کند. پیش از ویرایش چیزی که بازنویسی می‌شود، UUID اتصال را به صاحب واقعی آن نسبت دهید.
پیدا کردن فایلی که وارد کردید بخش آسان ماجراست و اغلب شروع نادرست. آنچه اهمیت دارد این است که NetworkManager امروز کدام فایل را به‌عنوان اتصال ذخیره‌شده می‌خواند، و این به یک شناسه اتصال و به آن بک‌اند پیکربندی بستگی دارد که بسته‌های نصب‌شده واقعاً استفاده می‌کنند. ویرایش ورودی پیش از پاسخ به آن پرسش، همان راهی است که یک VPN کارآمد به دو پیکربندی نیمه‌درست تبدیل می‌شود.
فایل واردشده همان نمایه ذخیره‌شده نیست
سه نام دور هر مشکل VPN می‌چرخد: نام اتصال، نام فایلی که وارد کردید، و رابط مجازی که هنگام بالا آمدن تونل پدیدار می‌شود. هیچ‌یک از آن‌ها پیکربندی ذخیره‌شده را مشخص نمی‌کند، و نام اتصال را می‌توان ویرایش کرد در حالی که فایل پشت آن شناسه اصلی خود را نگه می‌دارد.
با یک فهرست فقط‌خواندنی شروع کنید و VPN موردنظر را بر اساس شناسه و نه برچسب انتخاب کنید:
nmcli -f NAME,UUID,TYPE connection showنام میزبان‌های نقطه پایانی و برچسب‌های هویت را از هر فهرستی که در یک تیکت می‌چسبانید بیرون بگذارید. بخش مفید نوع و شناسه است؛ بقیه زمینه‌ای است که یک غریبه به آن نیاز ندارد. بقیه را پیش از اشتراک‌گذاری پوشانده و بگویید که این کار را کرده‌اید، تا کسی در شگفت نماند که جای خالی‌ها چه معنایی دارد.
مکان‌های keyfile یک معنا ندارند
با افزونه بومی keyfile، فایل‌های اتصال می‌توانند در سه پوشه ظاهر شوند، و تفاوت میان آن‌ها ماندگاری است، نه راحتی.
| Location | Role |
|---|---|
/etc/NetworkManager/system-connections/ | Administrator-owned persistence |
/usr/lib/NetworkManager/system-connections/ | Package-supplied defaults, replaced on upgrade |
/run/NetworkManager/system-connections/ | Runtime state, regenerated and not durable |
ویرایش نسخه زمان اجرا تا شروع بعدی موفق به نظر می‌رسد، در آن لحظه تغییر تبخیر می‌شود و فایل به‌طرز مرموزی بازگردانده‌شده به نظر می‌رسد. ویرایش نسخه‌ای که بسته ارائه می‌دهد تا زمانی کار می‌کند که به‌روزرسانی آن را جایگزین کند، که نسخه‌ای کندتر و گیج‌کننده‌تر از همان درس است.
مستندات keyfile جزئیاتی را اضافه می‌کند که شایسته احترام است: آن فایل‌ها می‌توانند کلیدهای خصوصی و عبارت‌های عبور داشته باشند، و NetworkManager هر keyfile را که کاربران غیر از root بتوانند بخوانند یا بنویسند نادیده می‌گیرد. گسترش مجوزهای پوشه برای جستجوی یک تنظیم، همان رفتار بارگذاری را که می‌خواستید بررسی کنید خراب می‌کند.
وقتی Netplan مالک ماندگاری است
در اوبونتو، یکپارچگی NetworkManager که در مستندات Netplan توصیف شده و از 23.10 به بعد در دسترس است، جای نسخه پایدار را تغییر می‌دهد. برای اتصال‌های غیرموقت این را می‌نویسد: /etc/netplan/90-NM-<connection UUID>.yaml و یک نمایه زودگذر NetworkManager زیر این مسیر تولید می‌کند: /run/NetworkManager/system-connections/.
این یکپارچگی یک توزیع است، نه قاعده‌ای برای هر نصب NetworkManager. پیش از رفتن به دنبال فایل YAML تأیید کنید که بسته‌های نصب‌شده واقعاً از آن استفاده می‌کنند. همچنین به یاد داشته باشید که نمایه زمان اجرا ممکن است نمایشی تولیدشده از چیز دیگری باشد، نه منبعی که ارزش ویرایش دارد. دو فرمان بررسی، یک ساعت ویرایش فایل اشتباه را صرفه‌جویی می‌کند.
مثال مستندشده یک اتصال OpenVPN را از طریق نوع Netplan nm-devices با داده‌های عبور NetworkManager ذخیره می‌کند. اینکه Netplan تفسیر اختصاصی از یک فیلد VPN خاص ندارد به این معنا نیست که VPN ذخیره‌شده شما از دست رفته است؛ یعنی آن فیلد به‌صورت داده‌های مبهم سفر می‌کند.
رابط‌های گذرا نمایه نیستند
فعال‌سازی اتصال‌ها و رابط‌های مجازی موقتی می‌سازد که هرگز قرار نبود ماندگار شوند. یکپارچگی عمداً برای هر یک فایل YAML تازه نمی‌نویسد، پس نبودشان در /etc/netplan چیزی درباره ذخیره‌شدن نمایه والد نمی‌گوید.
اگر در پی فایلی هستید که ظاهر و ناپدید می‌شود، احتمالاً یکی از این‌ها را می‌بینید، نه پیکربندی خود را. پیش از هر نتیجه‌گیری از محتوای آن، بررسی کنید که آیا از راه‌اندازی مجدد جان سالم به در می‌برد. فایل زمان اجرایی که با ری‌استارت ناپدید می‌شود به شما می‌گوید هرگز منبع نبوده است، و همین مشاهده واحد کل بررسی را بازجهت می‌دهد. همچنین توضیح می‌دهد چرا ویرایش در آن زمان موفق به نظر می‌رسید.
رازها و مالکیت
یک نمایه می‌تواند به گواهی یا کلیدی اشاره کند که کاملاً جای دیگری ذخیره شده است، و یک گذرواژه می‌تواند متعلق به NetworkManager باشد، توسط یک عامل راز نشست کاربر تأمین شود، یا عمداً ذخیره نشده باشد. بنابراین یافتن یک فایل واحد چیز زیادی را درباره آنچه آغاز بدون نظارت لازم دارد روشن نمی‌کند.
ارجاع‌ها و پرچم‌های راز را بدون چاپ مقادیر محرمانه بررسی کنید. ورود به میزکار می‌تواند عاملی را در دسترس بیاورد که هنگام بوت نبود، و کپی یک فایل زمان اجرای تولیدشده آن عامل را بازتولید نمی‌کند. نشانه عملی تونلی است که وقتی کسی وارد می‌شود وصل می‌شود و وقتی دستگاه تنها شروع به کار می‌کند شکست می‌خورد. این الگو به مالکیت رازها اشاره دارد، نه به مسیریابی.
تغییرات تأییدشده را از طریق مدیریتی انجام دهید که اتصال را در اختیار دارد، سپس هم شناسه ذخیره‌شده و هم اتصال مؤثر را بررسی کنید. یک مالک پایدار واحد نگه دارید، زیرا ویرایش مستقل ورودی، یک keyfile تولیدشده و یک منبع YAML سه توضیح رقیب درباره آنچه اتصال بعدی استفاده خواهد کرد باقی می‌گذارد. آنچه واقعاً پایدار می‌ماند را انتخاب کنید، فقط همان را ویرایش کنید، و در تیکت بنویسید کدام فایل را معتبر دانستید. نفر بعدی از شما برای یک خط منشأ سپاسگزار خواهد بود.