مسار VPN مفقود في NetworkManager: سياسة الملف الشخصي أم سكربت؟

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

قرِّر أي مالك هو المسؤول قبل أن تكتب أي شيء.

ثلاثة مالكين، وبادئة واحدة مفقودة

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

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

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

اقرأ الملف الشخصي قبل أن تضيف أي شيء

ابدأ بخصائص الاتصال المحفوظ نفسها. اقرأها دون إفراغ الأسرار، واستخدم UUID إذا كان اسم الملف الشخصي غامضًا.

nmcli -f vpn.service-type,ipv4.never-default,ipv4.ignore-auto-routes,ipv4.route-table,ipv4.routes connection show office

vpn.service-type يخبرك أي خادم خلفي يملك الاتصال، وهذا مهم لأن بيانات الإضافة خاصة بالخادم الخلفي. المفتاح الذي تقبله إضافة ما ليس تعليمة مدعومة لأخرى، لذا فمقتطف منسوخ من وثائق عميل مختلف ليس دليلًا على شيء.

ipv4.ignore-auto-routes و ipv4.never-default يجيبان عن سؤالين مختلفين. الأول يمكن أن يرفض مسارات كان الاتصال سيتخذها تلقائيًا، والثاني يتحكم في ما إذا كان الملف الشخصي قد يصبح المسار الافتراضي. الملف الشخصي الذي يتجاهل المسارات التلقائية ولا يعتمد على شيء آخر سيتصل بنظافة ولن يثبّت شيئًا تقريبًا.

ip -4 rule show
ip -4 route show table all

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

ما لا يستطيع السكربت إصلاحه

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

إن script-security في OpenVPN هو الالتباس المتكرر الآخر. إنه إعداد في OpenVPN يحكم أي السكربتات يجوز للعميل تنفيذها وما يجوز له وضعه في بيئتها؛ المستوى 3 يسمح بتمرير بيانات الاعتماد عبر البيئة، وهو قرار بشأن التعامل مع الأسرار لا إصلاح للمسارات. لصقه في ملف شخصي ليس خادمه الخلفي OpenVPN، أو رفعه حين لا يحتاج أي سكربت إليه، يضيف تعرضًا دون أن يضيف مسارًا.

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

القرار، بالترتيب

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

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

بعد تصحيح معتمد، أعد الاتصال واختبر الوجهة بالعنوان ثم بالاسم، ثم افصل وأعد الاتصال مرة أخرى لتؤكد أن الحالة قابلة للتكرار. مالك واحد، وجدول واحد، ومسار يزول مع النفق هو النتيجة التي تستحق العناء.