لماذا تستمر واجهة VPN لديك في مغادرة منطقة firewalld الخاصة بها
تبقى المنطقة على حالها حتى يعيد النفق الاتصال، ثم تختفي. اكتشف ما إذا كانت NetworkManager أم firewalld تملك تلك الواجهة قبل لصق الأمر.
تضيف tun0 إلى المنطقة الصحيحة، فيبدأ التطبيق بالعمل، ثم يتبخر الإصلاح عند إعادة الاتصال التالية. إعادة تشغيل الأمر نفسه تنجح، وهذا يجعل الأمر يبدو وكأن firewalld نسيت. لم تنسَ؛ ثمة شيء له ادعاء أقوى على تلك الواجهة أعاد تعيينها.
المنطقة تصمد حتى تُعاد الواجهة إنشاؤها
تعيين منطقة firewalld لواجهة ما هو ارتباط، والارتباطات مقيدة بكائن الواجهة كما هو موجود الآن. عميل VPN يهدم الجهاز ويعيد إنشاءه ينتج كائنًا جديدًا، والكائن الجديد يبدأ بما يقوله المكوّن الذي يعيّن. لهذا يتكرر العرَض عند كل إعادة اتصال وليس عند كل حزمة.
المنطق نفسه يفسر سلوك إعادة التشغيل: ارتباطات وقت التشغيل لا تنجو من إعادة التشغيل، والارتباطات الدائمة لا تنطبق إلا على الأجهزة التي يعتقد firewalld أنه يملكها.
قبل تغيير أي شيء، اكتشف أي مكوّن يعيّن المنطقة.
اقرأ ثلاثة أشياء قبل تغيير أي شيء
سجّل المنطقة التي تملكها الواجهة الآن، والمناطق النشطة مع واجهاتها، وقائمة الواجهات الدائمة للمنطقة التي تقصدها. نفّذ تلك الاستعلامات قبل التغيير وبعد إعادة اتصال وبعد إعادة تشغيل. مقارنة النتائج الثلاث تخبرك ما إذا كان الارتباط يُستبدل أو يُتجاهل أو يُطبَّق متأخرًا فقط. إذا كانت القائمة الدائمة تذكر الجهاز بالفعل بينما تخالفها منطقة وقت التشغيل، فثمة شيء يتجاوز تعديلك.
سجّل أيضًا اسم الجهاز الفعلي في كل خطوة، لأن نفقًا يهبط اليوم على tun0 قد يهبط غدًا على tun1.
الارتباط المحفوظ باسم عام ليس فحصًا للهوية، ودقيقتان من التسجيل توفران ساعة من التخمين.
عندما تملك NetworkManager الاتصال
إذا كانت NetworkManager تدير اتصال VPN، فملف تعريفها يحمل المنطقة ويمرّرها إلى firewalld عند تنشيط الاتصال. قد يُتجاهل عندئذ ارتباط واجهة دائم في firewalld للجهاز نفسه، لأن NetworkManager هي المالك. اضبط المنطقة على الاتصال، وتأكد من أنك تحرّر ملف تعريف VPN وليس اتصالًا ماديًا غير ذي صلة أو سجلًا مؤقتًا.
تغيير تلك الخاصية قد يؤثر في اتصال نشط فورًا.
أبقِ مسار إدارة متاحًا واقرأ سياسة المنطقة الهدف قبل تطبيقها. تحرير حقل ZONE في ملف ifcfg صحيح فقط حيث لا يزال ذلك الملف مصدر التكوين.
عندما يملك firewalld الارتباط
بالنسبة لنفق مستقل باسم واجهة مستقر عمدًا، فإن تغييرًا دائمًا للواجهة هو الأداة الصحيحة. طبّقه عبر إعادة التحميل أو دورة الحياة التي يستخدمها نشرك، ثم افحص حالة وقت التشغيل، لأن التعديل الدائم فقط يصف النية لا ما هو نشط. قد يختلف الاثنان طوال الوقت الذي تستغرقه إعادة التحميل.
إذا كان اسم الواجهة ديناميكيًا، فحافظ على التعيين عبر دورة حياة الاتصال بدلًا من التسابق مع أي نفق يطالب بالاسم أولًا.
لا تُلقِ الواجهة في trusted فقط لجعل التطبيق يعمل.
اختبر إعادة التحميل وإعادة الاتصال وإعادة التشغيل
لا يكتمل التغيير إلا عندما ينجو من الثلاثة جميعًا.
أعد التحميل أولًا، لأن التعديلات الخاصة بوقت التشغيل تختفي هناك. ثم أعد توصيل النفق، وهناك تفقد الواجهة المستبدلة ارتباطها. ثم أعد التشغيل، وهناك يظهر أخيرًا عدم تطابق المالك. سجّل المنطقة في كل مرحلة وقارنها بالنية التي كتبتها، ولاحظ أي خطوة أنتجت الفرق.
إذا كانت المنطقة صحيحة وما زال التطبيق يفشل، فالمشكلة في قواعد المنطقة أو في تصنيف قائم على المصدر لا في العضوية. تُعد وثائق firewalld حول الاتصالات والواجهات المرجعَ لكيفية عمل الملكية كما هو مقصود.
اكتب المالك والقيمة والنتيجة المتوقعة في دليل التشغيل، وسيكون التعيين التالي قابلًا للتفسير.