وارد کردن در NetworkManager با فایل‌های OpenVPN و WireGuard شکست می‌خورد

من در تنظیمات GNOME گزینهٔ وارد کردن از فایل… را انتخاب کردم، نمایه‌ای برگزیدم که با کارخواه ارائه‌دهنده کار می‌کند، و گفتگو بدون افزودن چیزی به فهرست بسته شد. روی لپ‌تاپ دوم وارد کردن کامل شد، اتصال با نام نمایه ظاهر شد و سپس در نخستین درخواست احراز هویت شکست خورد. NetworkManager هرگز فایل .ovpn یا wg-quick شما را همان‌گونه که هست اجرا نمی‌کند. فایل را به یک تجزیه‌گر می‌سپارد، تجزیه‌گر آن را به قالب اتصال خود NetworkManager تبدیل می‌کند و از آن پس تونل از همان شیء تجزیه‌شده ساخته می‌شود: رازها، مسیرها، DNS و همه‌چیز. پس پرسش سودمند این نیست که چرا فایل خراب است، بلکه این است که آیا تجزیه رخ داد و چه چیزی را نگه داشت.

وارد کردن در واقع چه کاری با فایل می‌کند

برای OpenVPN تجزیه‌گر در بستهٔ افزونه زندگی می‌کند و اتصالی که می‌سازد به یک سرویس D-Bus مانند org.freedesktop.NetworkManager.openvpn اشاره می‌کند. بدون افزونه تجزیه‌گری نیست: نوع برای nmcli ناشناخته است و فهرست گرافیکی افزودن VPN ممکن است هیچ مدخل واردکردنی نشان ندهد. WireGuard در یک نکتهٔ مهم تفاوت دارد — NetworkManager از سری 1.30 تنظیمات WireGuard خودش را دارد، پس بستهٔ افزونهٔ جداگانه‌ای نیست، اما خوانندهٔ wg-quick فقط در بناهایی هست که آن را عرضه می‌کنند.

در هر حال فایل یک بار خوانده می‌شود. نتیجه به‌صورت keyfile زیر /etc/NetworkManager/system-connections/ نوشته می‌شود، به نام اتصال، متعلق به root و برای دیگر کاربران ناخوانا چون مواد کلید را در خود دارد. این keyfile اکنون خودِ اتصال است؛ ویرایش فایل اصلی .ovpn پس از آن چیزی را تغییر نمی‌دهد.

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

پیش از اشکال‌زدایی نمایه، افزونه را تأیید کنید

افزونهٔ گمشده درست مثل نمایهٔ خراب به نظر می‌رسد، پس نخست بسته را بررسی کنید. در Debian و Ubuntu پشتیبانی OpenVPN به‌صورت network-manager-openvpn به‌همراه یک کمک‌کنندهٔ میزکار عرضه می‌شود؛ در Fedora بسته‌ها NetworkManager-openvpn و NetworkManager-openvpn-gnome هستند؛ در Arch همان networkmanager-openvpn است.

dpkg -l network-manager-openvpn-gnome | tail -n 2
rpm -q NetworkManager-openvpn
pacman -Q networkmanager-openvpn

سپس از مسیر مطلق وارد کنید: nmcli connection import type openvpn file /home/you/profile.ovpn. مسیرهای نسبی معمولاً کار می‌کنند، اما پوسته‌ای که پوشه را عوض کرده یک واردکردن سریع را به دور زدن تبدیل می‌کند. برای WireGuard nmcli --version را بررسی کنید و مطمئن شوید سمت هسته با modprobe wireguard وجود دارد؛ واردکردنی که روی ماشین بدون ماژول موفق می‌شود شما را با اتصالی می‌گذارد که دستگاهش هرگز پیدا نمی‌شود. مرجع nmcli زیرفرمان import و نام‌های نوع پذیرفته‌شده را مستند می‌کند. اگر type wireguard یکسره رد شود، بنا از این قابلیت قدیمی‌تر است و گام درست یک بستهٔ توزیع یا backport است — نه کپی کردن پیکربندی به پوشه‌ای دلخواه به امید اینکه چیزی آن را بخواند.

اتصال OpenVPN را بخوانید، نه فایل .ovpn را

وقتی اتصال وجود دارد، تنظیمات تجزیه‌شده را بخوانید نه اینکه فایل را دوباره بخوانید: nmcli connection show "Work VPN" | grep -E '^vpn\.'. remote و درگاه، ترابری، مواد هویت — ca، cert، key، tls-auth یا tls-crypt — و روش احراز هویت را می‌خواهید. در نمایه‌ای با گذرواژهٔ کلید خصوصی، sudo nmcli --show-secrets connection show "Work VPN" را بیفزایید و پرچم‌های secret را ببینید: 0 یعنی none، پس راز در keyfile است؛ 1 یعنی agent-owned؛ 2 یعنی not-saved، یعنی هرگز در keyfile نوشته نمی‌شود؛ 4 یعنی not-required، یعنی اصلاً رازی لازم نیست. این‌ها بیت‌اند نه مقیاس، پس 3 یعنی همان agent-owned به‌علاوهٔ not-saved. رازی که یک بار در هر نشست می‌پرسد agent-owned (1) است و عامل آن را می‌طلبد؛ شمارهٔ پرچم جداگانه‌ای برای آن نیست. ناسازگاری پرچم‌ها دلیل معمول اتصال نمایه از اپلت میزکار و شکست آن از اسکریپت یا هنگام راه‌اندازی است.

سریع‌ترین راه دیدن آنچه تجزیه‌گر انداخته این است که از افزونه بخواهید فایل را دوباره بنویسد و سپس آن را مقایسه کنید: nmcli connection export "Work VPN" /tmp/roundtrip.ovpn. دستورالعمل‌هایی که در آن تفاوت ناپدید می‌شوند هنگام اتصال وجود نخواهند داشت. قلاب‌ها مظنونان معمول‌اند — script-security، up، down و route-up انتظار اسکریپتی با امتیازات بالا دارند و عمداً منتقل نمی‌شوند. تأیید را پایین نیاورید و برای موفقیت یک واردکردن امتیاز اضافی ندهید؛ گزینهٔ پشتیبانی‌نشده معمولاً مجموعهٔ قابلیت‌های افزونه را نشان می‌دهد نه سروری دست‌نیافتنی. این رفتار را به اسکریپت dispatcher شبکهٔ NetworkManager یا به سیاست سمت سرور منتقل کنید.

همچنین تأیید کنید که فیلدهای هویت جان سالم به در برده‌اند: ارجاع CA، remote-cert-tls و هر بررسی نامی که نمایه به آن تکیه داشت. اتصالی که بدون آن‌ها بالا می‌آید شاید با هر چیزی که در آن نشانی پاسخ می‌دهد سخن بگوید.

اتصال WireGuard را بخوانید، نه فایل wg-quick را

فایل wg-quick قالبی با معناشناسی پوسته است؛ اتصال واردشده مجموعه‌ای از تنظیمات است. PrivateKey کلید خصوصی واسط می‌شود، Address یک یا چند نشانی IPv4 و IPv6 می‌شود، DNS به ویژگی‌های resolver در NetworkManager نگاشت می‌شود، MTU به wireguard.mtu نگاشت می‌شود (مقدار پیش‌فرض خود wg-quick برابر 1420 است)، و هر بلوک peer تبدیل می‌شود به مدخل peer با کلید عمومی، endpoint، IPهای مجاز و persistent keepalive. آنچه ذخیره شده را با nmcli --show-secrets connection show wg0 چاپ کنید؛ اگر فهرست peer در آن خروجی پیدا نشد، keyfile را بخوانید:

sudo sed -n '/^\[wireguard\]/,/^\[/p' /etc/NetworkManager/system-connections/wg0.nmconnection

آنچه نمی‌ماند نیمهٔ پوستهٔ wg-quick است. PreUp، PostUp، PreDown، PostDown و Table رفتار آن ابزارند نه ویژگی‌های واسط WireGuard، پس پس از واردکردن چیزی آن‌ها را اجرا نمی‌کند. اگر نسخهٔ اصلی از Table = off استفاده می‌کرد تا مسیر پیش‌فرض را به حال خود بگذارد، نسخه‌های تازهٔ NetworkManager برای همان هدف ip4-auto-default-route و ip6-auto-default-route را عرضه می‌کنند؛ آن‌ها را صریح تنظیم کنید به‌جای اینکه فرض کنید اتصال مثل اسکریپت رفتار می‌کند. قلابی که مسیر سفارشی می‌افزود به آن مسیر در تنظیمات مسیریابی اتصال نیاز دارد، وگرنه به‌سادگی غایب خواهد بود.

به اتصال دقیقاً یک مالک بدهید

خرابی کلاسیک بعدی اتصالی است که تا راه‌اندازی بعدی کار می‌کند و سپس به حلقه می‌افتد. معمولاً [email protected] از آزمایشی پیشین هنوز فعال بود، یا کارخواه ارائه‌دهنده دیمن خودش را راه می‌انداخت، و دو مالک برای یک مقصد مسیر و DNS می‌نوشتند. NetworkManager resolver را از راه خودش تنظیم می‌کند، wg-quick از طریق resolvconf می‌نویسد، و آخرین نویسنده برنده است — پس تحلیل نام کار می‌کند، سپس می‌ایستد، سپس دوباره کار می‌کند. systemctl status wg-quick@wg0، nmcli connection show --active و ip link show type wireguard را بررسی کنید، سپس مالک دوم را غیرفعال کنید نه اینکه متریکش را تنظیم کنید.

اگر واقعاً به هر دو نیاز دارید، به آن‌ها واسط‌های جدا و IPهای مجاز ناهمپوشان بدهید و بگذارید دقیقاً یکی از آن‌ها مسیر پیش‌فرض را نصب کند. دو مسیر پیش‌فرض با متریک‌های متفاوت تونل شکافته نیست؛ مسابقه‌ای است که سرویسی که دوم راه می‌افتد آن را تعیین می‌کند. و پس از اتصال دوباره، وضعیت اعمال‌شده را بازبینی کنید — یک ویرایش دستی یک‌بارهٔ resolver که کارها را راه می‌اندازد مدرکی بر کامل بودن واردکردن نیست.

با ترافیک تأیید کنید و از راه‌اندازی مجدد جان سالم به در ببرید

اتصال را با nmcli connection up "Work VPN" بالا بیاورید، سپس وضعیت، نشانی و مسیرها را بخوانید به‌جای اعتماد به نماد: nmcli device show wg0 | grep -E 'GENERAL.STATE|IP4.ADDRESS|IP4.ROUTE'، ip route show default و یک پرس‌وجوی واقعی برای نامی که فقط درون تونل تحلیل می‌شود. دست‌دادن یا ping موفق فقط ثابت می‌کند رمزنگاری کار می‌کند؛ دربارهٔ ارسال، پیشوندهای تونل شکافته یا DNS خصوصی چیزی نمی‌گوید، و همین‌ها بخش‌هایی هستند که معمولاً می‌شکنند.

سپس راه‌اندازی مجدد کنید و تکرار کنید. رفتار autoconnect، واسطی که نامش عوض شده و افزونه‌ای که پس از دستگاه بار می‌شود همه خرابی‌هایی هستند که فقط در راه‌اندازی تمیز می‌بینید. journalctl -u NetworkManager -b --no-pager | tail -n 40 نشان می‌دهد دیمن در این راه‌اندازی با این اتصال چه کرد. برای رایانهٔ دوم keyfile را کپی کنید و آن را در مالکیت root با حالت 600 نگه دارید، یا برای OpenVPN از nmcli connection export استفاده کنید و .ovpn حاصل را دوباره وارد کنید — مسیر برون‌بری معادلی در WireGuard ندارد، پس آن جهت یک کپی فایل یا واردکردن تازه از نسخهٔ اصلی محافظت‌شده است.

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