استيراد ملف تعريف لا يعني الشيء نفسه كاستبدال عميل. يخزّن NetworkManager نوع إضافة برمجية إلى جانب بيانات خاصة بالإضافة والأسرار، والإضافة التي تملك ذلك النوع هي التي تقرّر ما يمكن للاتصال فعله. كل ما تضيفه تطبيقات المورّد فوق ذلك، من التسجيل إلى الحجب الدائم، يعيش خارج الملف. وما إذا كان التبديل آمنًا يعتمد على أي من تلك الطبقات تعتمد عليه فعلًا.

الملف يسمّي إضافة برمجية، لا مجموعة ميزات

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

قارن المتطلبات بدلًا من الأغلفة إذن. السؤال ليس هل يستطيع البديل الاتصال، لأنه يستطيع عادة؛ بل هل كل متطلب جعل العميل الأصلي مقبولًا يصمد بعد الانتقال. اكتب تلك المتطلبات قبل تثبيت أي شيء، وإلا تحوّل المقارنة إلى بحث عمّا ينكسر أولًا.

ما تضيفه تطبيقات المورّد حول النفق

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

المزيد من المكوّنات لا يعني أمانًا أكبر، والقليل لا يعني ضعفًا أكبر. السؤال هو أي مكوّن يفرض السياسة التي طُلب منك اتباعها. وإذا سأل مدقّق ما الذي يحجب الحركة عندما يسقط النفق، وجب أن يسمّي الجواب شيئًا يفعله فعلًا، وملف تعريف يتصل فقط ليس ذلك الجواب.

أين تختلف الملكية فعليًا

اقرأ هذا كخريطة ملكية لا كقائمة تحقّق، لأن الإخفاقات أدناه فجوات ملكية ولا يغلقها أي قدر من إعداد العميل. كل صف يسمّي الطبقة، والجهة التي تحملها عادة اليوم، وأين تظهر الفجوة أولًا.

LayerVendor applicationNetworkManager connectionWhere the gap shows up
Enrollment and posturebuilt into the clientabsent unless something else supplies ita managed device fails its next posture check
Address and resolver authoritythe client sets boththe plugin plus dispatcher scriptsnames resolve through the wrong resolver after a state change
Blocking on dropa bundled enginenothing by defaulttraffic continues in the clear after the tunnel dies
Upgrade paththe vendor's own channelthe distribution package and its plugina plugin update changes behaviour with no vendor note
Diagnostics and supportvendor tooling with client statejournal and dispatcher outputsupport cannot see why negotiation failed

اقرن كل صف بملاحظة يمكنك تكرارها لا بشعور تجاه العميل. اسم يُحلّ عبر المحلّل المقصود، ومسار يختفي عندما يتوقف النفق، واتصال محجوب بعد انقطاع محاكى، ثلاث ملاحظات تغطي معًا معظم الجدول. اكتب الملاحظة بجانب المتطلب الذي تثبته، واحتفظ بالتي فشلت، لأن الملاحظة الفاشلة هي الجزء الوحيد من السجل الذي يتنبّأ بالحادث التالي.

التبديل دون تداخل الملكية

تشغيل عميل المورّد واتصال NetworkManager للخدمة نفسها في الوقت نفسه هو الطريق الأكثر شيوعًا لخروج هذه المقارنات عن الصواب. كلاهما يثبّت مسارات، وكلاهما قد يضبط DNS، وكلاهما قد يمسّ حالة الجدار الناري. وما تقيسه حينئذ ترتيب ثالث لا يطابق السلوك الموثّق لأي من العميلين.

nmcli -f NAME,UUID,TYPE connection show
nmcli connection show work --show-secrets | grep -E "^vpn\."
journalctl -u NetworkManager -b --since "10 min ago"

يخبرك الأمر الأول هل ملف التعريف من نوع VPN أصلًا. ويعرض الثاني نوع خدمة الإضافة والأسرار المخزّنة، وهذا يهم عندما يُتوقّع مفتاح من وكيل بدلًا من الملف. والسجل هو المكان الذي ستقول فيه إضافة حُمّلت لكنها فشلت في التفاوض ذلك صراحة. وإذا لم يُظهر أي من الثلاثة مشكلة، فالفجوة في طبقات السياسة فوق النفق لا في الاتصال.

افصل العميل القديم قبل تفعيل الاتصال الجديد، وأبقِ نقاط النهاية والحساب متطابقة، واكتب أي مكوّن يملك المسارات وإعدادات المحلّل والحجب. تلك الملاحظة هي ما يمنع التحديث التالي من الانتهاء بمالكين اثنين.

مقالات ذات صلة