استيراد NetworkManager يفشل مع ملفات OpenVPN وWireGuard

اخترت استيراد من ملف… في إعدادات GNOME، واخترت ملفًا شخصيًا يعمل مع عميل المزوّد، وأُغلق الحوار دون إضافة أي شيء إلى القائمة. على حاسوب محمول ثانٍ اكتمل الاستيراد، وظهر الاتصال باسم الملف الشخصي، ثم فشل عند أول طلب مصادقة. لا يشغّل NetworkManager ملف .ovpn أو wg-quick لديك كما هو أبدًا. بل يسلّم الملف إلى محلّل، ويحوّله المحلّل إلى صيغة الاتصال الخاصة بـ NetworkManager، ومنذ ذلك الحين يُبنى النفق من ذلك الكائن المحلّل: الأسرار والمسارات وDNS وكل شيء آخر. لذا فالسؤال المفيد ليس لماذا الملف تالف، بل هل جرى التحليل وماذا احتفظ به.

ما يفعله الاستيراد فعليًا بالملف

بالنسبة إلى OpenVPN يعيش المحلّل في حزمة الإضافة، والاتصال الذي ينشئه يشير إلى خدمة D-Bus مثل org.freedesktop.NetworkManager.openvpn. لا إضافة، لا محلّل: النوع غير معروف لدى nmcli، وقد لا تعرض القائمة الرسومية لإضافة VPN أي إدخال استيراد على الإطلاق. يختلف WireGuard في نقطة مهمة: يحمل NetworkManager إعدادات WireGuard الخاصة به منذ سلسلة 1.30، لذا لا توجد حزمة إضافة منفصلة، لكن قارئ 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" وانظر إلى أعلام السرّ: 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 صيغة بدلالات shell؛ والاتصال المستورد مجموعة إعدادات. يصبح 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، أو استخدم nmcli connection export لـ OpenVPN وأعد استيراد ملف .ovpn الناتج — فمسار التصدير لا مقابل له في WireGuard، لذا فذلك الاتجاه نسخ ملف أو استيراد جديد من الأصل المحمي.

النسخة القصيرة بالترتيب: تأكّد من الإضافة أو إصدار NetworkManager، واستورد من مسار مطلق، واقرأ الإعدادات المحلّلة بما فيها أعلام السرّ، وقارن تصدير OpenVPN بالأصل، وافحص الخطافات والمسارات في جانب WireGuard، وعطّل أي مالك ثانٍ، ثم تحقّق بعد إعادة التشغيل من تحليل اسم وجدول المسارات. وعندما يجتاز اتصال كل ذلك، يمكن لملف الملف الشخصي الذي بدأه أن يعود إلى التخزين المحمي.